teor:
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.
I worry that on very slow connections, reducing timeouts will cut off users who would have previously had a working configuration.
The main thing a prober wants to do is see if the initial TLS handshake to the bridge succeeds. That's what I meant by "initial timeouts". I didn't see a pref for this. Did I miss it?
I'm guessing that this timeout can be pretty low - even on slow connections, a TLS connection should complete in seconds, rather than minutes. After the TLS connection succeeds, the rest of the timeouts can remain as-is/be pretty high. Most/all censors completely block connections from happening in the first place, so once something succeeds, then we can wait as long as we like.