wiki:org/roadmaps/GetTor/future

Future of GetTor

Software evolves, and we think it might be the time of GetTor to go beyond its current design. Moreover, we have received valid concerns that emails could be tampered and users could get malicious versions of Tor Browser (although we have no evidence that this is happening). Right now, when you get the Tor Browser via this method is up to you to verify its integrity.

With this in mind, we have been discussing about the idea of having a signed and verified distributor app (desktop), available on official channels (OSX app store, Google Chrome store, etc), which could ease the process of downloading and verifying the integrity of Tor Browser. In other words, a user should be able to download and make sure it has the right file with just a few clicks.

There has been some discussion related to this in tor-dev mailing list and IRC channel. Below is a list of ideas that have come up (please add your own idea if you have one :)):

  1. Have a backend API. The "distributor" should get the download links from there.
    • Advantages
      • No need to update the "distributor" every time a new version of Tor Browser is realeased.
      • In the future, other apps could make use of it i.e. people could write more downloaders/distributors.
    • Disadvantages:
      • If the API is under a torproject.org domain, is quite possible that the access to it is blocked too. Having various mirrors could be a solution.
      • More complicated (supposedly).

Note from naif: That's always integrated in Tor2web GeTor support

  1. The "distributor" should figure out where to download Tor Browser from, possibly with hard-coded values.
    • Advantages:
      • The "distributor" is more autonomous.
    • Disadvantages:
      • If the hard-coded links are blocked, the "distributor" won't work and/or should need to be updated.

  1. The "distributor" fetches a list of API mirrors from specific domains, and then asks for links to one of those mirrors.
    • Advantages:
      • Same of 1).
    • Disadvantages:
      • Same of 2)
      • It's like 2) but with more steps.

Note from naif: Given the need for Tor2web to update a list of Tor2web servers/mirror, that's also a common need that can be fixed on the two software at once.

  1. The "distributor" could use a simplified version of tor to connect to the Tor network and download the Tor Browser (see https://lists.torproject.org/pipermail/tor-dev/2015-June/008963.html).
    • Advantages:
      • If torproject.org is blocked but Tor network is not, this could be very effective.
    • Disadvantages:
      • It might be complicated to have this (not sure).
      • If we can upload a sort of tor to the app store, why not upload Tor Browser itself?
  1. Current GetTor stores links in files (e.g. dropbox.linkls). Instead of an API, one could just store these files in various cloud/hosting services.
    • Advantages
      • Easier.
    • Disadvantages
      • One might ask, why don't just store the Tor Browser right away? In that case it would be like option 2).
  1. The "distributor" could get the links from other less conventional means, like:
    • IRC: the distributor makes a secure connection to an IRC server, joins a specific channel and ask for the links. A bot should be up and waiting for queries in that channel.
    • Twitter: the distributor makes a secure connection to Twitter and gets the links from the timeline of an specific account (e.g. get_tor)

Here is a list of related resources:

  1. Satori (see https://lists.torproject.org/pipermail/tor-dev/2015-June/008952.html): Tor downloader (among other apps). It verifies sha hashes and distributes tutorials and bridges. It's under heavy development and the Chrome version has been out for more than a year now. https://github.com/glamrock/satori
  2. Satori desktop flow: http://imgur.com/a/EIR80
  3. Firefox extension (see https://lists.torproject.org/pipermail/tor-dev/2015-June/008962.html). It's purpose is to automate some verification of the (Tails) ISO image after it has been downloaded. It only provides authentication, no censorship circumvention. https://tails.boum.org/blueprint/bootstrapping/extension/
  4. Psiphon https://bitbucket.org/psiphon/psiphon-circumvention-system/
  5. GeTor implemented on Tor2web https://github.com/globaleaks/Tor2web/wiki/GetTor

naif: As a general consideration i'd love to improve a bit the GeTor functionality in Tor2web, so that Tor2web software can be effectively used as a "distributor" to easily setup a TorBrowser mirror.

Last modified 2 years ago Last modified on Jun 24, 2015, 6:45:53 PM