[tbb-dev] Feedback on design decision for Tor Launcher

[Mike Perry]

Mark Smith:
> On 2/21/17 5:02 PM, Mike Perry wrote:
> > Now that we do have an updater, I actually think that an optional "Try
> > Everything!" button that tests all PTs (and fetches new PT bridges from
> > a BridgeDB API via domain fronting) will definitely be safer than what
> > we have now, and I think it is also likely that some form of optional
> > automation (after a proper user warning) is likely to beat out anything
> > that requires more decision points or interactions.
> > 
> > One hard part will be figuring out how to best provide the choice of
> > using automated PT testing to the user, and describe the risks.
> > 
> > Another hard part will be deciding which things to include in the
> > automated testing: the public tor network, provided bridges, bridges
> > from BridgeDB, or some subset/combination. Which of these things we
> > include in the test will change the user's risk profile with respect to
> > the categories you mentioned at
> > https://trac.torproject.org/projects/tor/wiki/doc/TorLauncherUX2016#Designconsiderations
> 
> Another consideration is "How much help can we realistically expect to
> get from the network team?" Kathy and I are skeptical that automated
> trial/error/timeout PT configuration will work well without some changes
> to tor. I think a strong argument can be made that in the long run that
> kind of probing should be built into tor. For example, without adaptive
> timeouts for fast vs. slow networks it will be difficult to have Tor
> Launcher complete an automated probing process efficiently. If things
> are too slow, users will give up.

This specific problem sounds like it will have UX consequences if we
have automation or not. Without automation, users have to manually try a
bridge, wait for it to fail, and then enter a new one. With automation,
we can at least say "This may take a while. Go have some coffee" rather
than hold the user hostage.

Also, I think that exposing a hidden Tor pref to lower the initial
bootstrap timeouts just for this automation test should be a simple
change.

However, I grant that there may be other technical issues with
automation that could surprise us. It is risky to promise that it will
work well. Do you know of any other bootstrap issues or control port
weirdness that may cause problems with automating? Do you expect there
to be lots of surprises?


As for implementing the probing and automation entirely in core-tor, it
will be a somewhat radical change from how all the Tor logic currently
handles bridges. For every bridge in the torrc, Tor makes a connection
to that bridge to download its descriptor from it, at a regular
interval. It is only after this that it begins the process of selecting
a bridge to use. However, Tor continues to attempt to contact failed
bridges periodically to see when they are available, and on restart.
The newer guard logic may make this simpler to fix, though.

However, I think the real winning scenario here is full bridgedb
automation: talking to bridgedb via a domain-fronted REST API to get
more bridges to try. I think such an API and mechanism would be more
quickly done in the browser than in core-tor. But it does mean we have
to reimplement this automation for each client application that uses
Tor...

My preference is to implement it where it is easiest first, and if that
works well, we can migrate it to core-tor later, since I suspect the
core-tor work will be much more involved. However, I could see probing
still being done best from core-tor, and bridge fetching being done best
from the browser. That does seem possible.

Can you go into the additional problems you would expect to have with
doing automation from the control port?

> > I do think these problems are solvable, but the reality of the situation
> > might be that the user has to do a couple of interactions before the
> > automation starts. (Like being asked where they are or what they want to
> > test, being warned about the risks of each test, etc). It will be some
> > work to design UX experiments to figure out which UX actually
> > communicates this information to users without confusing them or scaring
> > them off, but I know you're quite capable of that :).
> > 
> > If we get painted into a corner where we don't get to do any of our own
> > UX experiments for this, I think we should be prepared to resign
> > ourselves to only automating the safest possible thing, and only after a
> > scary warning box :/.
> 
> I agree with almost everything you and Linda said. I think Linda exposes
> what might be the biggest risk: if we spend time on automation and it
> does not work out for some reason, we will have spent less time
> improving the UI layout, flow, and messaging (and we know based on
> Linda's research that we can make significant gains without automation).

In terms of getting more censored users to use Tor, I think the bridge
selection, configuration, and connecting flow is the biggest barrier. I
believe that this is inherent in the manual configuration problem. No
matter what the UI does, without automation, these steps will remain,
and users will give up part way through, especially if some bridges are
failing.

> Automation also requires "backend" implementation expertise that crosses
> over between the tor daemon and the browser. I have confidence that you
> (Mike) could design something that would work but I have a lot less
> confidence that Kathy and I would take into account everything that is
> required for a successful and safe implementation. That means that
> automation will require more design work and careful review by several
> smart people.

So for the simple case of just automating testing only the bridges that
we have configured in the browser, do you think this is still hard? The
code already tries to connect to the bridge you select, and if bootstrap
fails, it takes you back to the beginning of the wizard. Timeout
durations aside, simply trying the next one in the pref list shouldn't be
that hard, or am I missing something?

As for the BridgeDB interaction, you're right that will require
decisions around what bridge types to fetch, etc. It will need more
thought and a proper specification.

-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20170227/4261252e/attachment-0001.sig>