More options on how to get the bundles
Users should be able to add options to their requests on how they want to get the requested bundle.
options: Mirror link, Google Drive link, Zip file, etc.
Activity
(as discussed elsewhere, but here's yet another ticket on the topic, so:)
For tiny things, we should not complexify the interface by asking the user to specify which one she wants. We should just provide all of them, along with enough explanation to help the user recognize what they are (so she can decide which one to try).
Replying to arma:
For tiny things, we should not complexify the interface by asking the user to specify which one she wants. We should just provide all of them, along with enough explanation to help the user recognize what they are (so she can decide which one to try).
We now have Dropbox support where we upload the files to Dropbox and generate a link. Dropbox supports both HTTP and HTTPS. A sample URL looks like this:
https://dl.dropboxusercontent.com/u/$USERID/$FILENAMESo if we distribute it through HTTP and the censor blocks the URL, we can always get a new user ID and generate a new one. With HTTPS, we should be fine. (The process is automated.)
Also see: https://trac.torproject.org/projects/tor/ticket/9036#comment:3
I have not changed anything on the GetTor and distribution side though because we should discuss on what would you prefer to send and how.
-
For posterity, here's my mail from April 19:
In my opinion (just in case we need even more ;), gettor should either send you the thing you wanted as an attachment, or it should send you a pile of little things to help you get what you wanted. Those little things could include: - One or more URLs, some preferably https, for where you can download the thing. - A sha1 of the thing, plus instructions on how to compare the sha1 with the thing once you've fetched it. - A PGP signature on the thing, for those hardcore people for whom a sha1 isn't enough. - A bittorrent file to help you fetch the thing -- extra points that it's self-authenticating assuming you got the right bittorrent file. - Whatever other tricks we can come up with. The more the merrier, so long as our instructions text doesn't get too complex. I think sending people the sha1, then having them fetch the file from $wherever, is very powerful. It's not as good, in theory, as giving them a gpg signature -- but let's remember that our "verifying the signature" instructions on Windows start with "first, fetch gpg.exe from this http url". I share Andrew's hesitancy over trusting third parties, but to a large extent we were already doing that with the gmail approach. -
Replying to sukhbir:
So if we distribute it through HTTP and the censor blocks the URL, we can always get a new user ID and generate a new one.
Hm. After thinking about it for a bit, I think we want to preemptively rotate the http urls more often. Otherwise the attacker can learn the URL and then watch for other people who fetch it -- including retroactively look through their network surveillance logs.
Rotating once a minute, if it's used during that minute, should be a good enough balance between unpredictability and defense-against-DoS?
I just pushed the Dropbox uploader I talked about earlier. It generates both HTTP and HTTPS links and it's very easy to rotate the URLs if we need. (If we get a new account, we have a new URL.)
Given that we have TBB sizes < 25 MB because of our dropping off Vidalia, I am not sure if there is any interest currently in adding support for more ways to distribute the bundles since GetTor will become functional again when we move to the new bundles completely. However, if anyone still thinks this can be useful for us, then I can work with kaner to start distributing Dropbox links in the GetTor email body. (The script above outputs the links to a file, so GetTor integration should not be much time.)
The Tor Browser package is now smaller than 25 MB. That's great. But gettor still does not work for gmail users. I found that when I tried to email the Windows Tor Browser package to another gmail user from my personal gmail account, I got an alert from gmail saying that it would not send .exe files over email for security reasons. I was able to send the email successfully after I renamed the file torbrowser-install-3.5_en-US.txt and instructed the user to replace the .txt extension with .exe. The user later reported being able to successfully use the package.
For the sake of having public record, as requested by sukhbir and phobos, I'm going to copy/paste my reply from a non-public thread to here.
===============
When I played with GetTor, and tried to make it send via Gmail, I registered [redacted] a.t gmail. I don't think the username really matters, as it does not show up in the URLs, does it?
It should not matter and this should be fine. Are you OK with sharing the details of this account? If yes, please pass them on to me, CCing Nima and anyone else who would like to have access to the account.
we should be super cautious about these accounts. as if someone would be able to get a hold of them or recover any of them, would be able to send malicious software to a huge number of users. And please have it in mind we made this dropbox account just for test. I don't know how we keep credentials at Tor Project. Maybe weasel or phobos can help us here?
You still send out 5 or something links pointing to direct mirrors, do you? At least you should.
No because I have been told that those mirrors no longer work. If this information is incorrect, please point me to the mirrors and I will update the message.
in an ideal situation, we should provide options for users on how they would like to download the bundles. and we should do it in our first (welcome) email.
Options such as cloud links, zip file, mirrors, magnet, torrent, etc.
And yes, you're right that we should send out at least one mirror link with every request. I say one as I believe we should keep it as minimal as we can. we need room to teach them how to check sig and hash.
I would like to see what the recent situation is? Because like Iran was also blocking some websites but now the situation is different. Is China actively blocking Gmail and Dropbox? If yes, then I am open to ideas for newer services because right now our implementation supports only Gmail and Dropbox. Of course this means you have to suggest some services which have an API that we can make use of and that we can "trust" :)
I don't think if we necessarily need to /trust/ any of these could services. what we need to do is to make sure users always check the signatures and sha256sum.
Google, dropbox and bunch of other western services are blocked in china and I'm not sure if you remember, but I had this idea of ...
(bare with me, it may sound horrible but needs more discussion)
using Chinese cloud services (including but not limited to 'baidu'). I even checked their API and there are some cool hacks which we can upload our bundles to their cloud without them knowing where is it coming from.
well they probably can run a filter and check the hash, detect and drop the file, but I have some ideas to get around that too. Anyways I mean, we're brainstorming, right? plus, cloud is cloud. us, uk or chinese services. what's the difference? I believe we should just take the advantage of it. and teach our users how to make sure they got the right piece of software.
PS: for the sake of record: one other thing we should keep it in mind is to find a way to send out a new short-user-manual out with our emails. but I'd leave it to another discussion.
This is now being worked on #12817 (moved)
#28232 (moved) now groups GetTor working areas.
Trac:
Parent: N/A to #28232 (moved)
Continuing work at #28231 (moved).
Trac:
Status: new to closed
Resolution: N/A to duplicatementioned in issue #9071 (moved)
mentioned in issue #9441 (moved)
mentioned in issue #10692 (moved)
mentioned in issue #14744 (moved)
mentioned in issue #16716 (moved)
mentioned in issue #17212 (moved)
mentioned in issue #17214 (moved)
mentioned in issue #20770 (moved)
mentioned in issue #22664 (moved)
mentioned in issue #22665 (moved)
mentioned in issue #25887 (moved)
mentioned in issue #26175 (moved)
mentioned in issue #27972 (moved)
mentioned in issue #28230 (moved)
mentioned in issue #28231 (moved)
mentioned in issue tpo/anti-censorship/gettor-project/trac#9441 (closed)
mentioned in issue tpo/anti-censorship/gettor-project/trac#10692 (closed)