Infrastructure/www-2021
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity

spacing stuff

Browse source
This commit is contained in:
Daniel Vinci 2021-04-30 14:35:43 -06:00
parent 643c9e3106
commit c073b071a9
No known key found for this signature in database
GPG key ID: 7A700C29916C26CA
6 changed files with 555 additions and 275 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
src/routes/about-contact.svelte
View file

@ -95,8 +95,8 @@
margin-right: auto;
padding-top: 1em;
padding-bottom: 3em;
max-width: 1500px;
padding-left: 1em;
padding-right: 1em;
max-width: 1024px;
padding-left: 2em;
padding-right: 2em;
}
</style>

802
src/routes/faq.svelte
View file

@ -1,295 +1,575 @@
<script>
import FAQItem from "../components/FAQItem.svelte";
import TalkingPointContainer from "../components/TalkingPointContainer.svelte";
import TalkingPointContent from "../components/TalkingPointContent.svelte";
import TalkingPointName from "../components/TalkingPointName.svelte";
</script>
<svelte:head>
<title>FemtoStar - Global Open Infrastructure</title>
</svelte:head>
<div class="site">
<TalkingPointContainer>
<TalkingPointName text="Products and Services" />
<TalkingPointContent>
import FAQItem from "../components/FAQItem.svelte";
import TalkingPointContainer from "../components/TalkingPointContainer.svelte";
import TalkingPointContent from "../components/TalkingPointContent.svelte";
import TalkingPointName from "../components/TalkingPointName.svelte";
</script>
<FAQItem title="Do you plan to offer bandwidth tiers? Will there be a data cap?">
<p>All FemtoStar services are delivered on a best-effort basis, at the highest speed technically feasible with the user's hardware and with network
traffic at that time. We do not impose artificial restrictions on bandwidth. The flipside of this is that, while we do not limit you to a maximum
speed, we cannot guarantee you will always get one particular speed either - getting the maximum possible at all times means that, unlike a service
where you are constantly limited to a certain bandwidth even when more is possible, FemtoStar performance will vary. Performance at some times
being lower than at some others should be expected.</p>
<p>FemtoStar service is paid for in terms of the amount of beam time a session consumes - that is,
how long the satellite needs to spend using one of its beams to transmit data for that session. This is not the same as the amount of time a user
stays connected to the network - because the beam must also serve other users and any particular user's terminal is unlikely to be consuming the
full throughput of its link at all times, a connected terminal consumes much less beam time than the amount of time it remains connected, especially
when usage is light. What all of this means is that there is no data cap - we don't care about how many bytes you send through the satellite, only
how long the satellite must spend doing it.</p>
<p>This means that users with larger, higher-speed terminals (see the above point) able to transfer the
same amount of data in a shorter period of time will pay less for the same amount of data transferred, as they will consume less beam time in doing
so. Because beam time is the network's most important resource, and is the limiting factor in terms of network performance, we believe that charging
for service in terms of the actual resource - beam time - being consumed is the most fair model for service pricing.</p>
</FAQItem>
<svelte:head>
<title>FemtoStar - Global Open Infrastructure</title>
</svelte:head>
<FAQItem title="Who makes FemtoStar terminals?">
FemtoStar plans to take a hybrid approach to manufacturing and selling terminals. FemtoStar's higher-sales-volume "core" user terminals will be manufactured
and sold primarily by hardware partners, allowing us to leverage existing manufacturing and sales infrastructure. Meanwhile, development and reference
hardware, as well as more specialized terminals will be made in Canada by FemtoStar, at the same facility where we build our satellites. Every FemtoStar
terminal is based on FemtoStar-developed reference designs.
</FAQItem>
<div class="site">
<TalkingPointContainer>
<TalkingPointName text="Products and Services" />
<TalkingPointContent>
<FAQItem
title="Do you plan to offer bandwidth tiers? Will there be a data cap?"
>
<p>
All FemtoStar services are delivered on a best-effort basis, at the
highest speed technically feasible with the user's hardware and with
network traffic at that time. We do not impose artificial restrictions
on bandwidth. The flipside of this is that, while we do not limit you
to a maximum speed, we cannot guarantee you will always get one
particular speed either - getting the maximum possible at all times
means that, unlike a service where you are constantly limited to a
certain bandwidth even when more is possible, FemtoStar performance
will vary. Performance at some times being lower than at some others
should be expected.
</p>
<FAQItem title="What speeds do you anticipate being available?">
<p>FemtoStar is a midband Mobile Satellite Service network, designed for speeds in line with other midband Mobile Satellite Service offerings.
Here, the term "midband" refers to the level of bandwidth between narrowband services, designed to provide a low-speed connection to small,
usually IoT/embedded terminals, and broadband services, designed to provide a high-speed connection to large, expensive, fixed terminals.</p>
<p>
FemtoStar service is paid for in terms of the amount of beam time a
session consumes - that is, how long the satellite needs to spend
using one of its beams to transmit data for that session. This is not
the same as the amount of time a user stays connected to the network -
because the beam must also serve other users and any particular user's
terminal is unlikely to be consuming the full throughput of its link
at all times, a connected terminal consumes much less beam time than
the amount of time it remains connected, especially when usage is
light. What all of this means is that there is no data cap - we don't
care about how many bytes you send through the satellite, only how
long the satellite must spend doing it.
</p>
<p>While this middle category of service may be unfamiliar to those more used to terrestrial services, it's common in the in Mobile Satellite
Service landscape, and is what's offered by services such as Inmarsat BGAN, Iridium Certus, or Thuraya IP. In these services, as in FemtoStar,
designing for this middle category means that users can expect performance much better than a narrowband system, while still having a portable
terminal much smaller than those needed for broadband systems. Like the aforementioned MSS options, a typical FemtoStar terminal should provide
in the mid-hundreds of kbps, using a terminal roughly the size of a tablet or small laptop.</p>
<p>Of course, FemtoStar's design still allows for
flexibility on the size and speed of terminals - users should be able to choose their own balance between speed, cost, and portability. As
such, depending on the size of the terminal, FemtoStar should be able to accomodate larger terminals in the megabits-per-second range, or
smaller terminals with reduced (if still better than typical narrowband offerings) speeds in a pocket-sized form factor.</p>
</FAQItem>
<FAQItem title="Is the FemtoStar Credit Token a cryptocurrency?">
<p>No, at least not by any usual definition of the term. While they are a digital system used to pay for service, and while they do make use of
cryptographic signatures for security, FemtoStar Credit Tokens are not transacted on a blockchain, cannot be mined, and are not intended
for use as anything other than payment for FemtoStar service. While third-party users are free to buy and sell Credit Tokens at any price
they are able to, their value in FemtoStar service is fixed.</p>
</FAQItem>
<p>
This means that users with larger, higher-speed terminals (see the
above point) able to transfer the same amount of data in a shorter
period of time will pay less for the same amount of data transferred,
as they will consume less beam time in doing so. Because beam time is
the network's most important resource, and is the limiting factor in
terms of network performance, we believe that charging for service in
terms of the actual resource - beam time - being consumed is the most
fair model for service pricing.
</p>
</FAQItem>
<FAQItem title="How do I buy FemtoStar tokens? Are they available yet?">
<p>Once our network is operational, you will be able to purchase FemtoStar tokens from FemtoStar via a retail token sales portal, from a
third-party reseller, in bulk from FemtoStar via a wholesale agreement, or from anyone else willing to sell them to you. While the FemtoStar
Project is capable of pre-issuing tokens that will be usable once the network is operational, we do not currently offer pre-issued retail
tokens to the general public, due to the inherent risk to consumers of purchasing a service before it is available. If you are interested in
working with us to purchase wholesale tokens, for resale as a token reseller or for a large deployment of FemtoStar hardware as an enterprise
user, please <a href="./about-contact">contact us</a>.</p>
</FAQItem>
<FAQItem title="Who makes FemtoStar terminals?">
FemtoStar plans to take a hybrid approach to manufacturing and selling
terminals. FemtoStar's higher-sales-volume "core" user terminals will be
manufactured and sold primarily by hardware partners, allowing us to
leverage existing manufacturing and sales infrastructure. Meanwhile,
development and reference hardware, as well as more specialized
terminals will be made in Canada by FemtoStar, at the same facility
where we build our satellites. Every FemtoStar terminal is based on
FemtoStar-developed reference designs.
</FAQItem>
</TalkingPointContent>
</TalkingPointContainer>
<FAQItem title="What speeds do you anticipate being available?">
<p>
FemtoStar is a midband Mobile Satellite Service network, designed for
speeds in line with other midband Mobile Satellite Service offerings.
Here, the term "midband" refers to the level of bandwidth between
narrowband services, designed to provide a low-speed connection to
small, usually IoT/embedded terminals, and broadband services,
designed to provide a high-speed connection to large, expensive, fixed
terminals.
</p>
<TalkingPointContainer>
<TalkingPointName text="Network Architecture and Other Projects" />
<TalkingPointContent>
<p>
While this middle category of service may be unfamiliar to those more
used to terrestrial services, it's common in the in Mobile Satellite
Service landscape, and is what's offered by services such as Inmarsat
BGAN, Iridium Certus, or Thuraya IP. In these services, as in
FemtoStar, designing for this middle category means that users can
expect performance much better than a narrowband system, while still
having a portable terminal much smaller than those needed for
broadband systems. Like the aforementioned MSS options, a typical
FemtoStar terminal should provide in the mid-hundreds of kbps, using a
terminal roughly the size of a tablet or small laptop.
</p>
<FAQItem title="What about Starlink?">
<p><a href="https://starlink.com">Starlink</a> is a low-earth-orbit communications constellation developed by SpaceX. While we have a tremendous amount of
respect for the engineering accomplishments of the Starlink network, its goals and those of FemtoStar are almost entirely separate. While
both intend to provide satellite communications service using low-earth orbit constellations, Starlink is designed to provide consumer
broadband services to large, fixed terminals (in the satellite industry, this is known as Fixed Satellite Service). FemtoStar, on the
other hand, is designed for midband services to small and medium, portable or in-motion terminals (also known as Mobile Satellite Service).</p>
<p>
Of course, FemtoStar's design still allows for flexibility on the size
and speed of terminals - users should be able to choose their own
balance between speed, cost, and portability. As such, depending on
the size of the terminal, FemtoStar should be able to accomodate
larger terminals in the megabits-per-second range, or smaller
terminals with reduced (if still better than typical narrowband
offerings) speeds in a pocket-sized form factor.
</p>
</FAQItem>
<p>
While the Starlink network is large, its architecture is traditional - it is designed to connect users to official ground stations providing
official services. While there has been talk of limited use of Starlink for point-to-point connectivity, such as for high-speed securities
trading, SpaceX holds complete control over use of this feature, and it is not a part of their consumer-facing services, nor is it known to
be possible with their consumer hardware. FemtoStar's open-infrastructure architecture ensures an inherently net-neutral network, wherein
all hardware is usable as a ground station, and even our own services are simply one of many a satellite is able to connect users to.</p>
<p>Starlink
terminals are uniquely identified on the network, and can be easily geolocated by the network (whether they report their GPS location is currently
unknown, but the network is certainly able to geolocate them accurately, as they are disallowed from accessing the network outside of the
small region, or "cell", where their user's address is registered). Starlink users are required to provide a substantial amount of personal
information in order to purchase service. Payments are handled on ground infrastructure, based on user accounts. FemtoStar does not require
any user account whatsoever, is not restricted to use in a small cell, and handles payments on the satellite itself using FemtoStar Credit Tokens.</p>
</FAQItem>
<FAQItem title="Is the FemtoStar Credit Token a cryptocurrency?">
<p>
No, at least not by any usual definition of the term. While they are a
digital system used to pay for service, and while they do make use of
cryptographic signatures for security, FemtoStar Credit Tokens are not
transacted on a blockchain, cannot be mined, and are not intended for
use as anything other than payment for FemtoStar service. While
third-party users are free to buy and sell Credit Tokens at any price
they are able to, their value in FemtoStar service is fixed.
</p>
</FAQItem>
<FAQItem title="What about Blockstream or Othernet?">
<p><a href="https://blockstream.com">Blockstream</a> is a cryptocurrency company which offers a service named <a href="https://blockstream.com/satellite">Blockstream Satellite</a>.
<a href="https://othernet.is">Othernet</a> is a company which broadcasts data, primarily news and other text content, via satellite.</p>
<FAQItem title="How do I buy FemtoStar tokens? Are they available yet?">
<p>
Once our network is operational, you will be able to purchase
FemtoStar tokens from FemtoStar via a retail token sales portal, from
a third-party reseller, in bulk from FemtoStar via a wholesale
agreement, or from anyone else willing to sell them to you. While the
FemtoStar Project is capable of pre-issuing tokens that will be usable
once the network is operational, we do not currently offer pre-issued
retail tokens to the general public, due to the inherent risk to
consumers of purchasing a service before it is available. If you are
interested in working with us to purchase wholesale tokens, for resale
as a token reseller or for a large deployment of FemtoStar hardware as
an enterprise user, please <a href="./about-contact">contact us</a>.
</p>
</FAQItem>
</TalkingPointContent>
</TalkingPointContainer>
<p>Blockstream Satellite broadcasts the Bitcoin blockchain, one-way, over six geostationary broadcasting satellites, and offers an API to transmit
your own short pieces of data over the network, with payment in Bitcoin. While Blockstream does allow for remote access to the Bitcoin blockchain,
it is a one-way system - it cannot be used for two-way communications, or to make online cryptocurrency transactions, unless you already have an internet
connection and can connect to its API.</p>
<p>Othernet provides one-way, broadcast data service via two geostationary satellites. This data typically consists of news, Wikipedia articles, and
other low-data-rate content which can be delivered one-way.</p>
<p>Both of these companies purchase time on existing geostationary broadcasting satellites, of the type typically used for consumer satellite television.
These services do not support, nor is the hardware provided for them capable of, any form of uplink from the user terminal. While both services are
useful as tools for broadcast data distribution, they are one-way, Broadcasting Satellite Service systems, distinct from two-way communications systems
in the Fixed Satellite Service (such as Starlink) and Mobile Satellite Service (such as FemtoStar).</p>
</FAQItem>
<TalkingPointContainer>
<TalkingPointName text="Network Architecture and Other Projects" />
<TalkingPointContent>
<FAQItem title="What about Starlink?">
<p>
<a href="https://starlink.com">Starlink</a> is a low-earth-orbit communications
constellation developed by SpaceX. While we have a tremendous amount of
respect for the engineering accomplishments of the Starlink network, its
goals and those of FemtoStar are almost entirely separate. While both intend
to provide satellite communications service using low-earth orbit constellations,
Starlink is designed to provide consumer broadband services to large, fixed
terminals (in the satellite industry, this is known as Fixed Satellite
Service). FemtoStar, on the other hand, is designed for midband services
to small and medium, portable or in-motion terminals (also known as Mobile
Satellite Service).
</p>
<FAQItem title="Are you sure satellites are the right way to do this? Surely a terrestrial network would be easier?">
<p>We're big fans of a number of the terrestrial privacy-respecting communications projects currently in development - in fact, FemtoStar <a href="./about-contact">began as a terrestrial
network</a>, named Private Mobile Data Protocol (PMDP).</p>
<p>
While the Starlink network is large, its architecture is traditional -
it is designed to connect users to official ground stations providing
official services. While there has been talk of limited use of
Starlink for point-to-point connectivity, such as for high-speed
securities trading, SpaceX holds complete control over use of this
feature, and it is not a part of their consumer-facing services, nor
is it known to be possible with their consumer hardware. FemtoStar's
open-infrastructure architecture ensures an inherently net-neutral
network, wherein all hardware is usable as a ground station, and even
our own services are simply one of many a satellite is able to connect
users to.
</p>
<p>The fundamental issue of terrestrial networks is the amount of hardware necessary to provide adequate coverage. It has taken decades of development,
thousands of licenses to thousands of companies in hundreds of countries, hundreds of billions of dollars at least, and <a href="https://www.mobileworldlive.com/blog/blog-global-base-station-count-7m-or-4-times-higher">more than 7 million cell
towers</a> to build mainstream cellular networks out to their current coverage, and even with this it's likely you still sometimes have problems
getting cellular service. We began with the assumption that a terrestrial network would be the only practical solution, and extensively tested
PMDP hardware in real-world urban and suburban environments. Eventually, even we - the developers of the technology - were forced to admit that
it was impractical without an impractically dense network, even for a small, urban implementation - letalone regional or global coverage.</p>
<p>As a thought experiment in community-run terrestrial networks, next time you leave home, ask yourself if you are ever more than 1 kilometer (3200 feet)
away from somewhere a mesh node or base station in a community-run terrestrial network could be installed without being removed, stolen, or
tampered with, and if anyone nearby would be willing to pay for, install, and maintain such a device. We tried this, with real hardware, in a real
city, in 2019, and came to the conclusion that that, in contrast to being an easier solution, it was likely outright impossible in most circumstances.</p>
<p>Where such networks can exist, they genuinely do have some advantages over satellite-based networks - however, in most places, it is simply not realistic to
build them. We found this out the hard way. It's also worth noting that FemtoStar can coexist with these networks symbiotically - where these networks can
be built, given that this is likely to occur in clusters of nodes or base stations (such as in a city center) separated by a substantial distance, we
believe FemtoStar could be extremely useful to link these sections together into larger, more resillient networks.</p>
</FAQItem>
<p>
Starlink terminals are uniquely identified on the network, and can be
easily geolocated by the network (whether they report their GPS
location is currently unknown, but the network is certainly able to
geolocate them accurately, as they are disallowed from accessing the
network outside of the small region, or "cell", where their user's
address is registered). Starlink users are required to provide a
substantial amount of personal information in order to purchase
service. Payments are handled on ground infrastructure, based on user
accounts. FemtoStar does not require any user account whatsoever, is
not restricted to use in a small cell, and handles payments on the
satellite itself using FemtoStar Credit Tokens.
</p>
</FAQItem>
<FAQItem title="What about mesh networks?">
<p>See the above point. While mesh networks are able to partially solve the problem of base station range by allowing every user device to extend coverage,
this still does not allow for coverage where there are no nodes. The same thought experiment applies - are you always within a kilometer of someone else
who might have a node in the mesh? If you have your own node in the mesh, is there ever another node nearby for it to mesh with? If not, a mesh network
may not be practical in your situation. Even where mesh networks are practical, FemtoStar could still be used to interconnect regions where the mesh is
available, even when they are separated by large regions with no nodes.</p>
</FAQItem>
<FAQItem title="What about Blockstream or Othernet?">
<p>
<a href="https://blockstream.com">Blockstream</a> is a cryptocurrency
company which offers a service named
<a href="https://blockstream.com/satellite">Blockstream Satellite</a>.
<a href="https://othernet.is">Othernet</a> is a company which broadcasts
data, primarily news and other text content, via satellite.
</p>
<FAQItem title="I've used satellite internet, and the latency is pretty bad - is this true of FemtoStar too?">
<p>Not to nearly the same degree. While the distance to the satellite does add some amount of latency due to the time taken for the signal to reach the satellite,
the round-trip propagation time to a low-earth orbit satellite is a handful of milliseconds, not the hundreds of milliseconds familiar to users of geostationary
satellite networks. Ping time on FemtoStar should be less than a tenth of that which a geostationary satellite user would experience, if even that.</p>
</FAQItem>
<p>
Blockstream Satellite broadcasts the Bitcoin blockchain, one-way, over
six geostationary broadcasting satellites, and offers an API to
transmit your own short pieces of data over the network, with payment
in Bitcoin. While Blockstream does allow for remote access to the
Bitcoin blockchain, it is a one-way system - it cannot be used for
two-way communications, or to make online cryptocurrency transactions,
unless you already have an internet connection and can connect to its
API.
</p>
<FAQItem title="How do you plan to mitigate orbital debris?">
<p>In contrast to the vast majority of small satellites, FemtoStar plans to include electric propulsion onboard our satellites, allowing them to be repositioned
as needed and cleanly deorbited at end-of-life. The FemtoStar Project is working closely with Applied Ion Systems, a leading developer of open-hardware
mallsat propulsion hardware, to develop a specialized implementation of their technology for use onboard the FemtoStar space vehicle. Even in the event of a thruster failure,
the solar panel can be positioned to drastically increase atmospheric drag on the satellite, rapidly increasing orbital decay and deorbiting the satellite.</p>
</FAQItem>
<p>
Othernet provides one-way, broadcast data service via two
geostationary satellites. This data typically consists of news,
Wikipedia articles, and other low-data-rate content which can be
delivered one-way.
</p>
<FAQItem title="Is this a megaconstellation? How many satellites do you need?">
<p>The network can theoretically work with as little as a single satellite, however of course this configuration does not allow for continuous coverage.
Practical constellation layouts begin at around 48 satellites (and include the layout shown on our <a href="./">homepage</a>. We have also considered
the possibility of starting with a larger constellation of up to 96 satellites, however we believe the most reasonable approach would be to begin with
the minimum practical number of satellites (likely 48) and then scale up the constellation with new satellites as needed.</p>
</FAQItem>
<p>
Both of these companies purchase time on existing geostationary
broadcasting satellites, of the type typically used for consumer
satellite television. These services do not support, nor is the
hardware provided for them capable of, any form of uplink from the
user terminal. While both services are useful as tools for broadcast
data distribution, they are one-way, Broadcasting Satellite Service
systems, distinct from two-way communications systems in the Fixed
Satellite Service (such as Starlink) and Mobile Satellite Service
(such as FemtoStar).
</p>
</FAQItem>
<FAQItem title="What if a satellite fails? Will the network become unreliable?">
<p>The FemtoStar network provides multiple levels of protection against failure of spacecraft, and against failure of the network due to failure of a spacecraft,
resulting in a resilient network able to mitigate and work around hardware failures onboard satellites. Each satellite incorporates a degree of redundancy
previously seen only on far larger satellites, and is designed with longevity in mind. The network as a whole also protects against network-wide failure as
a result of the failure of a single satellite - most regions, especially those with a latitude near the inclination of the satellites such as North America
Europe, and Oceania, and much of Asia and South America - are covered redundantly, and even elsewhere, the "gap" caused when the only satellite visible to
a user has failed is short - lasting only minutes or less before working satellites come into view.</p>
<p>For most users, a satellite failure would likely be noticeable only as a decrease in the network's coverage angle, while for those in the aforementioned
near-inclination regions, it might not be noticeable at all. Finally, FemtoStar would be able to rapidly and inexpensively replenish its network with new satellites,
either newly-launched or simply moved into place if already available in a storage orbit.</p>
</FAQItem>
<FAQItem
title="Are you sure satellites are the right way to do this? Surely a terrestrial network would be easier?"
>
<p>
We're big fans of a number of the terrestrial privacy-respecting
communications projects currently in development - in fact, FemtoStar <a
href="./about-contact">began as a terrestrial network</a
>, named Private Mobile Data Protocol (PMDP).
</p>
</TalkingPointContent>
</TalkingPointContainer>
<p>
The fundamental issue of terrestrial networks is the amount of
hardware necessary to provide adequate coverage. It has taken decades
of development, thousands of licenses to thousands of companies in
hundreds of countries, hundreds of billions of dollars at least, and <a
href="https://www.mobileworldlive.com/blog/blog-global-base-station-count-7m-or-4-times-higher"
>more than 7 million cell towers</a
> to build mainstream cellular networks out to their current coverage,
and even with this it's likely you still sometimes have problems getting
cellular service. We began with the assumption that a terrestrial network
would be the only practical solution, and extensively tested PMDP hardware
in real-world urban and suburban environments. Eventually, even we - the
developers of the technology - were forced to admit that it was impractical
without an impractically dense network, even for a small, urban implementation
- letalone regional or global coverage.
</p>
<TalkingPointContainer>
<TalkingPointName text="Privacy and Security" />
<TalkingPointContent>
<FAQItem title="How is using FemtoStar private when using it indicates that you are looking for privacy?">
<p>FemtoStar is not purely a "privacy" system - we believe it to be competitive with other mobile satellite options, and in all likelihood there will be plenty
of FemtoStar users who aren't even aware of, much less interested in, its privacy features. We also believe there will be a number of FemtoStar terminals
installed as a part of machine-to-machine data installations, as backup connections for enterprise networks, or as backhaul to community-run terrestrial
networks. A user using it for privacy reasons is indistinguishable from any of these users.</p>
<p>Additionally, by this rationale, any privacy-respecting product, service, or system is bad for your privacy, as its use demonstrates that you are looking
for privacy. Even if your threat model truly does require that you obscure even the fact that someone is using a system that could be used for
privacy-respecting communications, FemtoStar still does substantially better than just about any other privacy-respecting communications network. For one thing, it uses
a substantially more directional antenna than any terrestrial mobile, which means its transmitted signal is very weak in any direction but that of the
satellite.</p>
<p>Its connection to the satellite is also is encrypted, and even to the satellite, it does not contain a location, terminal identifier, user account, or any
other identifying details. The terminal never transmits when it has no session open with the satellite, and, unlike mesh network nodes, it cannot be made
to transmit by the traffic of another user unless the terminal's owner has chosen to operate their own service over the network.</p>
</FAQItem>
<p>
As a thought experiment in community-run terrestrial networks, next
time you leave home, ask yourself if you are ever more than 1
kilometer (3200 feet) away from somewhere a mesh node or base station
in a community-run terrestrial network could be installed without
being removed, stolen, or tampered with, and if anyone nearby would be
willing to pay for, install, and maintain such a device. We tried
this, with real hardware, in a real city, in 2019, and came to the
conclusion that that, in contrast to being an easier solution, it was
likely outright impossible in most circumstances.
</p>
<FAQItem title="Don't FemtoStar's satellites have to know where I am, based on which beam I use?">
<p>In theory, to some extent, but in practice, not meaningfully. In contrast to traditional communications satellites, a FemtoStar satellite, at least for
transmit, does not have a consistent beam pattern. Instead, electronic beamforming is used to point each of only a handful of beams, rapidly switching
beam patterns as the satellite jumps between active sessions. The footprints within which these beams are usable are hundreds of kilometers across,
even at their narrowest, and more than 2000 kilometers long. In addition, knowing where "you" are, as opposed to just knowing the rough area in which
one of the network's users is located, requires knowing who you are. As such, the satellite could determine that an anonymous session is within, for
example, northern Europe, western North America, or eastern Asia, but not that it is in a particular country or city, and certainly not who that
session belongs to.
</p>
</FAQItem>
<p>
Where such networks can exist, they genuinely do have some advantages
over satellite-based networks - however, in most places, it is simply
not realistic to build them. We found this out the hard way. It's also
worth noting that FemtoStar can coexist with these networks
symbiotically - where these networks can be built, given that this is
likely to occur in clusters of nodes or base stations (such as in a
city center) separated by a substantial distance, we believe FemtoStar
could be extremely useful to link these sections together into larger,
more resillient networks.
</p>
</FAQItem>
<FAQItem title="You say geolocation-resistant - is it geolocation-proof?">
<p>We do not feel that we can promise that there is any two-way wireless communications system where it is truly impossible for an adversary to locate a
transmitter given enough time to search for it on the ground. In particular, it is extremely difficult to prevent just about any transmitter from
being detectable by a high-gain antenna at short range, no matter how directional or low-power the transmitter may be. However, we also believe
that such a search would need to begin relatively close to any terminal it wanted to have a chance of finding, and that it would likely be
complicated by the presence of more than one FemtoStar terminal in an area.</p>
<FAQItem title="What about mesh networks?">
<p>
See the above point. While mesh networks are able to partially solve
the problem of base station range by allowing every user device to
extend coverage, this still does not allow for coverage where there
are no nodes. The same thought experiment applies - are you always
within a kilometer of someone else who might have a node in the mesh?
If you have your own node in the mesh, is there ever another node
nearby for it to mesh with? If not, a mesh network may not be
practical in your situation. Even where mesh networks are practical,
FemtoStar could still be used to interconnect regions where the mesh
is available, even when they are separated by large regions with no
nodes.
</p>
</FAQItem>
<p>Additionally, there's the question of why finding terminals would be worthwhile to an attacker to begin with. Given that such an attack would almost
certainly involve the rather labor-intensive task of traveling around an area of interest with a vehicle full of equipment looking for terminals that
you cannot identify and cannot monitor the activity of, while also being unable to tell the difference between two intermittently-used terminals and
one terminal which has moved, we do feel we can say that this attack is unlikely to fit into many threat models.</p>
<FAQItem
title="I've used satellite internet, and the latency is pretty bad - is this true of FemtoStar too?"
>
<p>
Not to nearly the same degree. While the distance to the satellite
does add some amount of latency due to the time taken for the signal
to reach the satellite, the round-trip propagation time to a low-earth
orbit satellite is a handful of milliseconds, not the hundreds of
milliseconds familiar to users of geostationary satellite networks.
Ping time on FemtoStar should be less than a tenth of that which a
geostationary satellite user would experience, if even that.
</p>
</FAQItem>
<p>A FemtoStar terminal can even be used as a receive-only device if this is acceptable for the user's use case - in this configuration, it would likely be
nearly impossible to geolocate, even with this sort of attack.</p>
<FAQItem title="How do you plan to mitigate orbital debris?">
<p>
In contrast to the vast majority of small satellites, FemtoStar plans
to include electric propulsion onboard our satellites, allowing them
to be repositioned as needed and cleanly deorbited at end-of-life. The
FemtoStar Project is working closely with Applied Ion Systems, a
leading developer of open-hardware mallsat propulsion hardware, to
develop a specialized implementation of their technology for use
onboard the FemtoStar space vehicle. Even in the event of a thruster
failure, the solar panel can be positioned to drastically increase
atmospheric drag on the satellite, rapidly increasing orbital decay
and deorbiting the satellite.
</p>
</FAQItem>
<p>In short, we don't believe any transmitting device is truly geolocation-proof, but we do believe that geolocation of users can be made impractical for to
perform at a large scale, and that its value to an attacker can be substantially diminished. On top of this, we do feel we can safely say that FemtoStar
is substantially more geolocation-resistant than any currently-available two-way wireless communications system, and that it is likely that its
geolocation-resistance could only be matched or exceeded by another satellite-based system including most or all of the same geolocation-resistance features.</p>
</FAQItem>
<FAQItem
title="Is this a megaconstellation? How many satellites do you need?"
>
<p>
The network can theoretically work with as little as a single
satellite, however of course this configuration does not allow for
continuous coverage. Practical constellation layouts begin at around
48 satellites (and include the layout shown on our <a href="./"
>homepage</a
>. We have also considered the possibility of starting with a larger
constellation of up to 96 satellites, however we believe the most
reasonable approach would be to begin with the minimum practical
number of satellites (likely 48) and then scale up the constellation
with new satellites as needed.
</p>
</FAQItem>
<FAQItem title="What if the FemtoStar project is taken over by someone I don't trust?">
<p>The FemtoStar architecture does not require that you trust the FemtoStar Project, even to begin with. Because the user is not required to trust the FemtoStar
network, in order for the FemtoStar Project, or or an entity who had taken it over, to meaningfully compromise the security of FemtoStar users, many core
design elements of the network would need to be changed, necessitating, at minimum, a firmware update to user terminals to accomodate substantial protocol changes. A new update published without
<a href="./free-open-source">source code</a> would be immediately suspicious, as would a new update where the newly-released source code disabled privacy features.
</p>
</FAQItem>
<FAQItem
title="What if a satellite fails? Will the network become unreliable?"
>
<p>
The FemtoStar network provides multiple levels of protection against
failure of spacecraft, and against failure of the network due to
failure of a spacecraft, resulting in a resilient network able to
mitigate and work around hardware failures onboard satellites. Each
satellite incorporates a degree of redundancy previously seen only on
far larger satellites, and is designed with longevity in mind. The
network as a whole also protects against network-wide failure as a
result of the failure of a single satellite - most regions, especially
those with a latitude near the inclination of the satellites such as
North America Europe, and Oceania, and much of Asia and South America
- are covered redundantly, and even elsewhere, the "gap" caused when
the only satellite visible to a user has failed is short - lasting
only minutes or less before working satellites come into view.
</p>
<FAQItem title="FemtoStar Inc. is Canadian - what if I don't trust Canada?">
<p>See the above point. Even if a malicious governmen were to take over the FemtoStar Project and attempt to surveil its users, they would be
incapable of doing so without making changes that would be immediately obvious to users, and to our own developers in other countries. Additionally
FemtoStar Inc. in Canada is only one part of the overarching FemtoStar Project - we have developers all over the world.
</p>
</FAQItem>
<p>
For most users, a satellite failure would likely be noticeable only as
a decrease in the network's coverage angle, while for those in the
aforementioned near-inclination regions, it might not be noticeable at
all. Finally, FemtoStar would be able to rapidly and inexpensively
replenish its network with new satellites, either newly-launched or
simply moved into place if already available in a storage orbit.
</p>
</FAQItem>
</TalkingPointContent>
</TalkingPointContainer>
<FAQItem title="What if the satellites themselves are attacked?">
<p>While we would never claim that it is impossible that a FemtoStar satellite could be compromised, either remotely or through physical attack, we believe
the likelihood of this to be low for a number of reasons.</p>
<TalkingPointContainer>
<TalkingPointName text="Privacy and Security" />
<TalkingPointContent>
<FAQItem
title="How is using FemtoStar private when using it indicates that you are looking for privacy?"
>
<p>
FemtoStar is not purely a "privacy" system - we believe it to be
competitive with other mobile satellite options, and in all likelihood
there will be plenty of FemtoStar users who aren't even aware of, much
less interested in, its privacy features. We also believe there will
be a number of FemtoStar terminals installed as a part of
machine-to-machine data installations, as backup connections for
enterprise networks, or as backhaul to community-run terrestrial
networks. A user using it for privacy reasons is indistinguishable
from any of these users.
</p>
<p>The most important point here is that FemtoStar satellites are not especially useful targets to an attacker. Due to not being a trusted part of the network,
even if they themselves are fully compromised, they cannot be used to compromise FemtoStar users, nor would they be much use as part of a botnet, nor would
they provide an attacker with any additional utility in their intended purpose (communications) than is available officially.</p>
<p>
Additionally, by this rationale, any privacy-respecting product,
service, or system is bad for your privacy, as its use demonstrates
that you are looking for privacy. Even if your threat model truly does
require that you obscure even the fact that someone is using a system
that could be used for privacy-respecting communications, FemtoStar
still does substantially better than just about any other
privacy-respecting communications network. For one thing, it uses a
substantially more directional antenna than any terrestrial mobile,
which means its transmitted signal is very weak in any direction but
that of the satellite.
</p>
<p>With regards to compromising the satellites from the ground, the satellite's onboard software is subject to intense scrutiny, including through formal
proofs, makes extensive use of sandboxing, and, given the relative simplicity of the FemtoStar protocol, presents a small attack surface.</p>
<p>
Its connection to the satellite is also is encrypted, and even to the
satellite, it does not contain a location, terminal identifier, user
account, or any other identifying details. The terminal never
transmits when it has no session open with the satellite, and, unlike
mesh network nodes, it cannot be made to transmit by the traffic of
another user unless the terminal's owner has chosen to operate their
own service over the network.
</p>
</FAQItem>
<p>In terms of physical security, while FemtoStar's placement of its infrastructure in orbit certainly grants it a degree of inaccessibility compared to terrestrial
infrastructure, there are of course spacecraft which could conceivably reach a FemtoStar satellite, and could hypothetically either tamper with or replace it.
However, tampering would require physical capture and substantial disassembly of the satellite, which is detectable and would result in the deletion of onboard
keys, resulting in a tampered-with satellite being easily detectable from the ground (even if new software attempted to obscure this tampering), while a
replacement satellite would lack the cryptographic keys of the satellite it replaced entirely.</p>
<FAQItem
title="Don't FemtoStar's satellites have to know where I am, based on which beam I use?"
>
<p>
In theory, to some extent, but in practice, not meaningfully. In
contrast to traditional communications satellites, a FemtoStar
satellite, at least for transmit, does not have a consistent beam
pattern. Instead, electronic beamforming is used to point each of only
a handful of beams, rapidly switching beam patterns as the satellite
jumps between active sessions. The footprints within which these beams
are usable are hundreds of kilometers across, even at their narrowest,
and more than 2000 kilometers long. In addition, knowing where "you"
are, as opposed to just knowing the rough area in which one of the
network's users is located, requires knowing who you are. As such, the
satellite could determine that an anonymous session is within, for
example, northern Europe, western North America, or eastern Asia, but
not that it is in a particular country or city, and certainly not who
that session belongs to.
</p>
</FAQItem>
<p>An attacker could opt to attempt to disable, capture, or destroy a satellite altogether - after all, if you want to assume that truly no adversary is off the table,
you could choose to consider even the use of anti-satellite weapons. However, an attacker trying to make the network truly unusable would need to destroy or disable
not just one satellite, but the entire constellation, and any replacement satellites, and to do so in a way which obscured their involvement, a daunting task
even for the largest possible adversaries. This type of attack is also immediately obvious (especially if the satellite is physically destroyed, resulting in
the generation of orbital debris), and even this still does not result in an actual compromise (geolocation, identification, etc.) of FemtoStar users.</p>
</FAQItem>
<FAQItem title="You say geolocation-resistant - is it geolocation-proof?">
<p>
We do not feel that we can promise that there is any two-way wireless
communications system where it is truly impossible for an adversary to
locate a transmitter given enough time to search for it on the ground.
In particular, it is extremely difficult to prevent just about any
transmitter from being detectable by a high-gain antenna at short
range, no matter how directional or low-power the transmitter may be.
However, we also believe that such a search would need to begin
relatively close to any terminal it wanted to have a chance of
finding, and that it would likely be complicated by the presence of
more than one FemtoStar terminal in an area.
</p>
</TalkingPointContent>
</TalkingPointContainer>
</div>
<style>
.site {
padding-top: 1em;
padding-bottom: 3em;
max-width: 1500px;
margin-left: auto;
margin-right: auto;
padding-left: 1em;
padding-right: 1em;
}
</style>
<p>
Additionally, there's the question of why finding terminals would be
worthwhile to an attacker to begin with. Given that such an attack
would almost certainly involve the rather labor-intensive task of
traveling around an area of interest with a vehicle full of equipment
looking for terminals that you cannot identify and cannot monitor the
activity of, while also being unable to tell the difference between
two intermittently-used terminals and one terminal which has moved, we
do feel we can say that this attack is unlikely to fit into many
threat models.
</p>
<p>
A FemtoStar terminal can even be used as a receive-only device if this
is acceptable for the user's use case - in this configuration, it
would likely be nearly impossible to geolocate, even with this sort of
attack.
</p>
<p>
In short, we don't believe any transmitting device is truly
geolocation-proof, but we do believe that geolocation of users can be
made impractical for to perform at a large scale, and that its value
to an attacker can be substantially diminished. On top of this, we do
feel we can safely say that FemtoStar is substantially more
geolocation-resistant than any currently-available two-way wireless
communications system, and that it is likely that its
geolocation-resistance could only be matched or exceeded by another
satellite-based system including most or all of the same
geolocation-resistance features.
</p>
</FAQItem>
<FAQItem
title="What if the FemtoStar project is taken over by someone I don't trust?"
>
<p>
The FemtoStar architecture does not require that you trust the
FemtoStar Project, even to begin with. Because the user is not
required to trust the FemtoStar network, in order for the FemtoStar
Project, or or an entity who had taken it over, to meaningfully
compromise the security of FemtoStar users, many core design elements
of the network would need to be changed, necessitating, at minimum, a
firmware update to user terminals to accomodate substantial protocol
changes. A new update published without
<a href="./free-open-source">source code</a> would be immediately suspicious,
as would a new update where the newly-released source code disabled privacy
features.
</p>
</FAQItem>
<FAQItem
title="FemtoStar Inc. is Canadian - what if I don't trust Canada?"
>
<p>
See the above point. Even if a malicious governmen were to take over
the FemtoStar Project and attempt to surveil its users, they would be
incapable of doing so without making changes that would be immediately
obvious to users, and to our own developers in other countries.
Additionally FemtoStar Inc. in Canada is only one part of the
overarching FemtoStar Project - we have developers all over the world.
</p>
</FAQItem>
<FAQItem title="What if the satellites themselves are attacked?">
<p>
While we would never claim that it is impossible that a FemtoStar
satellite could be compromised, either remotely or through physical
attack, we believe the likelihood of this to be low for a number of
reasons.
</p>
<p>
The most important point here is that FemtoStar satellites are not
especially useful targets to an attacker. Due to not being a trusted
part of the network, even if they themselves are fully compromised,
they cannot be used to compromise FemtoStar users, nor would they be
much use as part of a botnet, nor would they provide an attacker with
any additional utility in their intended purpose (communications) than
is available officially.
</p>
<p>
With regards to compromising the satellites from the ground, the
satellite's onboard software is subject to intense scrutiny, including
through formal proofs, makes extensive use of sandboxing, and, given
the relative simplicity of the FemtoStar protocol, presents a small
attack surface.
</p>
<p>
In terms of physical security, while FemtoStar's placement of its
infrastructure in orbit certainly grants it a degree of
inaccessibility compared to terrestrial infrastructure, there are of
course spacecraft which could conceivably reach a FemtoStar satellite,
and could hypothetically either tamper with or replace it. However,
tampering would require physical capture and substantial disassembly
of the satellite, which is detectable and would result in the deletion
of onboard keys, resulting in a tampered-with satellite being easily
detectable from the ground (even if new software attempted to obscure
this tampering), while a replacement satellite would lack the
cryptographic keys of the satellite it replaced entirely.
</p>
<p>
An attacker could opt to attempt to disable, capture, or destroy a
satellite altogether - after all, if you want to assume that truly no
adversary is off the table, you could choose to consider even the use
of anti-satellite weapons. However, an attacker trying to make the
network truly unusable would need to destroy or disable not just one
satellite, but the entire constellation, and any replacement
satellites, and to do so in a way which obscured their involvement, a
daunting task even for the largest possible adversaries. This type of
attack is also immediately obvious (especially if the satellite is
physically destroyed, resulting in the generation of orbital debris),
and even this still does not result in an actual compromise
(geolocation, identification, etc.) of FemtoStar users.
</p>
</FAQItem>
</TalkingPointContent>
</TalkingPointContainer>
</div>
<style>
.site {
padding-top: 1em;
padding-bottom: 3em;
max-width: 1024px;
margin-left: auto;
margin-right: auto;
padding-left: 2em;
padding-right: 2em;
}
</style>

6
src/routes/free-open-source.svelte
View file

@ -60,8 +60,8 @@
margin-right: auto;
padding-top: 1em;
padding-bottom: 3em;
max-width: 1500px;
padding-left: 1em;
padding-right: 1em;
max-width: 1024px;
padding-left: 2em;
padding-right: 2em;
}
</style>

6
src/routes/global-open-infrastructure.svelte
View file

@ -52,10 +52,10 @@
.site {
padding-top: 1em;
padding-bottom: 3em;
max-width: 1500px;
max-width: 1024px;
margin-left: auto;
margin-right: auto;
padding-left: 1em;
padding-right: 1em;
padding-left: 2em;
padding-right: 2em;
}
</style>

4
src/routes/index.svelte
View file

@ -80,8 +80,8 @@
margin-left: auto;
margin-right: auto;
max-width: 1024px;
padding-left: 1em;
padding-right: 1em;
padding-left: 2em;
padding-right: 2em;
}
.hero {

6
src/routes/privacy-by-design.svelte
View file

@ -74,8 +74,8 @@
margin-right: auto;
padding-top: 1em;
padding-bottom: 3em;
max-width: 1500px;
padding-left: 1em;
padding-right: 1em;
max-width: 1024px;
padding-left: 2em;
padding-right: 2em;
}
</style>