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

[Linda Naeun Lee]

On 2017-02-27 16:55, Mike Perry wrote:
> 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.

I agree with you, Mike. But I think that there are three potential 
designs:

1) the current one, where we have the users choose bridges--we can 
improve the interface and still get some benefits.
2) a 'naive' automated system, where we choose the bridges for the 
users--I'm talking literally just trying the hard coded options in an 
order that makes sense (obfs3, then meek, or whatever the recommended 
order is). This would eliminate the UX issue AND be safer than 1, since 
people make mistakes and we would make less.
3) your proposed automated system, where Tor launches a process to talk 
to the network and get assigned a bridge. This would eliminate both the 
UX issue and be safer than 2).

I think it is feasible to do 1) or 2). 3) would take some time.

My vote is for 2), then 1), then 3). I kind of want to do 1) to tell 
funders to shove off and not demand things, but I'm ignoring that.

> 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?

I think the 'naive' automation would not have any more complications 
than the current version, and would just take a lot of user pain out of 
the equation.

I don't know how complicated the bridgeDB proposal would be.

> 
> 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.

-- 
Current Key: https://pgp.mit.edu/pks/lookup?search=lindanaeunlee
GPG Fingerprint: FA0A C9BE 2881 B347 9F4F C0D7 BE70 F826 5ED2 8FA2