[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] The future of GetTor



> 
> Date: Mon, 15 Jun 2015 20:14:54 -0300
> From: ilv <ilv@xxxxxxxxxx>
> 
> 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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev