Mark,
On 2017-02-27 11:06, Mark Smith wrote:
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.
Good point. Design changes are something I can mostly handle on my own/within my own team (aside from the fact that someone on the tbb team might need to tweak the code/accept our changes).
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).
I don't know how much this automation scheme is hashed out, how much resources we are willing to put into this, etc. I'm willing to put in the effort to either make design changes that have a manual or automated configuration scheme.
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.
Good point.
Let me know what we choose to do! I'd be happy to discuss, if that helps the decision process.