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

Mike Perry mikeperry at torproject.org
Thu Mar 2 21:57:20 UTC 2017


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

-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20170302/340cbc0e/attachment.sig>


More information about the tbb-dev mailing list