On 28 Feb 2017, at 09:55, Mike Perry mikeperry@torproject.org 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.
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.
There are already multiple torrc options for this: some modify various timeouts, others modify the rate at which we fetch directory documents after we connect.
However, they are untested, and some values are known to cause bootstrap failures.
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 worry that on very slow connections, reducing timeouts will cut off users who would have previously had a working configuration.
We've had issues in the past with IPv6 support: while the major ones are fixed in 0.3.0 (and always worked via IPv6 bridges), there may still be some remaining bugs.
I had been considering automatic client selection of IPv4/IPv6, as OnionBrowser (iOS) currently uses their own automated selection process so they can pass Apple's IPv6-only tests. We should design this in such a way that it's extensible if we want to try multiple bridges and PTs.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------