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