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

[Linda Naeun Lee]

On 2017-02-27 16:18, teor wrote:
>> 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.

Hmm, interesting.

There are strategies to get users to wait! We could show them an 
informational video, give them a tour of the security features, or 
something like that (all of which are nice-to-have things I would have 
worked on way later).

> 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
> ------------------------------------------------------------------------

-- 
Current Key: https://pgp.mit.edu/pks/lookup?search=lindanaeunlee
GPG Fingerprint: FA0A C9BE 2881 B347 9F4F C0D7 BE70 F826 5ED2 8FA2