www/src/routes/faq/+page.svelte

<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 - FAQ</title>
</svelte:head>

<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>

        <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 handling your traffic.
        </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>

      <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>

      <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>
          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>

      <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>

  <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>

        <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="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>

        <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>

      <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>
          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>

      <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="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>

      <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 smallsat 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>

      <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 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>
    </TalkingPointContent>
  </TalkingPointContainer>

  <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>

      <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>

      <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>

        <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 government 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: 0;
    padding-bottom: 3em;
    max-width: 1024px;
    margin-left: auto;
    margin-right: auto;
    padding-left: 2em;
    padding-right: 2em;
  }
</style>