Thus spake Andrew Lewman (andrew@xxxxxxxxxxxxx): > On Fri, 3 May 2013 16:05:15 -0400 > "Runa A. Sandvik" <runa.sandvik@xxxxxxxxx> wrote: > > > I disagree. The Tor help desk sees a ton of requests from users saying > > that Tor is unable to connect, and the simple fix is to give them a > > bridge or two. Not all users know what they need to connect, and not > > all users will know the difference between bridge, obfs2, and obfs3. > > One answer is the user shouldn't care. Tor Browser should automatically > loop through the various kinds of connectivity and just connect. > non-obfs bridges really should get wholly replaced with obfs bridges en > masse. Yes that's true, ideally the user shouldn't have to care, or enter random data into text fields, except as last resort. However, we can't just probe everything because we don't want to probe for the public Tor network if you're censored. Best case: client IPs that are observed to probe various known Tor transports get targeted for more agressive censorship (the censor could just fail any unrecognizable traffic for N minutes after someone touches a public Tor IP, for example). Worst case: Targeted exploits are deployed that aim to subvert their computer in general, via Tor or otherwise. It's tempting to say this means we should have either just two bundles or perhaps just an "I'm censored" checkbox at startup. But then, even if we probe our list of pluggable transport types, if one of them is blockable, we still advertise that we're a Tor user by touching it. Such client IPs can then again be treated differently in terms of more agressive policies, or exploits. It seems like this means we need users to at minimum understand the nature of their censorship and what mechanism they expect to actually *work* in their location (based on word of mouth, forum posts, etc). Does this mean we should provide a different bundle for each mechanism? Or does this mean we should aim for one bundle that just allows the user to pick their best guess at the mechanism? This wizard/first run UI dialog is a version of the "You pick the mechanism that works". Unfortunately, at this state, this means the user actually has to enter data. I agree this isn't optimal. One could imagine a future version where they just check "Flashproxies work for me!" or "Obfsproxy works for me!", and then their browser makes the appropriate bridge discovery connections using that transport to bootstrap from a number of directory servers, possibly encoded in their Tor Launcher addon (if it can update successfully), or entered by support software (BridgeFinder or some other stegenographic non-Tor browser addon). > Another thought is with flashproxy in the pluggable transports bundle, > what percent of flashproxies work by default with no user config needed? Not sure. :/ Another question that I also don't know the answer to (but maybe you do): Do any of these existing mechanisms in the Wizard (HTTP proxies, using only 80/443, or vanilla Tor Bridges) still work in a significant sense? I imagine Tor bridges still work a lot of places, but do we care enough at this point? Should we focus our development *only* on pluggable transports? If the answer really is "Bridges and HTTP proxies don't work well enough for us to care about them anymore," then that would eliminate this entire discussion, and we could table figuring out the first-run UI until we have mechanisms that actually work, and ask the users to choose among those. I think though that quite a few people still use vanilla Tor Bridges successfully, right? > I wonder if we could extrapolate that percentage to a larger "what if > we did relay by default?" for all bundles... https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/175-automatic-node-promotion.txt We could do this same thing to promote uncensored Tor clients to various types of pluggable transports. -- Mike Perry
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev