[tor-dev] Tor Launcher settings UI feedback request

[Mike Perry]

Thus spake Andrew Lewman (andrew at torproject.is):

> On Fri, 3 May 2013 16:05:15 -0400
> "Runa A. Sandvik" <runa.sandvik at gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130504/e1c24ab6/attachment.pgp>