[tor-dev] The future of GetTor
teor
teor2345 at gmail.com
Tue Jun 16 16:48:23 UTC 2015
>
> Date: Mon, 15 Jun 2015 20:14:54 -0300
> From: ilv <ilv at riseup.net>
>
> Hi people,
>
> …
>
> 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. However, we have different thoughts
> on how this should work:
>
> * Option 1: GetTor should work as a backend and have an API. The
> distributor (and even other apps) would send queries to this API asking
> for links. The problem with this is that if Tor Project's website is
> blocked, is quite possible that the API would be blocked too (e.g.
> gettor.torproject.org).
>
> * Option 2: The distributor is in charge of presenting various
> alternatives to the user and getting the files directly from the
> cloud/hosting services.
>
> So, the purpose of this email is to get feedback from the community, and
> my specific questions to you people are the following:
>
> 1) What do you think of the distributor idea? It is something you or
> others would want?
The distributor sounds like a great idea, but, with Option 2, the user should always be able to fall back to actual links to the cloud services (wherever possible). This allows users who have trouble with the automated download to retry later, perhaps at a different location, or with a different browser.
> 2) In case we develop the distributor, should the email autoresponder
> remain?
I'm a big fan of diversity in distribution methods, but there are only a limited number of software maintainers…
>
> 3) If you agree on developing the distributor, what option you think
> would fit better? (please suggest better options)
If the distributor is a backend (Option 1), it would help to have mirror(s). But I wonder if we are just re-creating a single point of failure, and would be better using a CDN. It would be a terrible experience to succeed in downloading an app, only to find that the distributor was blocked.
Is it possible to submit an app to the app stores (I am thinking Apple's restrictions, here) that would bootstrap a Tor Browser download over the Tor network?
For example:
1. Download app
2. The app has various CDN links (or a way of getting them) and a some predefined bridges
3. The app tries the CDN links and bridges in order of reliability / expense
4. If the links or bridges fail, the user gets advice on how to find new, uncensored links or bridges and input them.
5. App downloads and verifies Tor Browser using the CDN or the Tor network
In most cases, the user experience would be one-click:
1. Open the app
2. See a recommended option highlighted out of a list of working options
3. click download
4. see a progress bar
5. Get a verified Tor Browser
teor
teor2345 at gmail dot com
pgp 0xABFED1AC
https://gist.github.com/teor2345/d033b8ce0a99adbc89c5
teor at blah dot im
OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150617/2cd444bd/attachment.sig>
More information about the tor-dev
mailing list