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

[teor]

> On 28 Feb 2017, at 09:55, Mike Perry <mikeperry at 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#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.
> 
> 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
------------------------------------------------------------------------



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20170228/916496eb/attachment.sig>