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

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

> I do think these problems are solvable, but the reality of the situation
> might be that the user has to do a couple of interactions before the
> automation starts. (Like being asked where they are or what they want to
> test, being warned about the risks of each test, etc). It will be some
> work to design UX experiments to figure out which UX actually
> communicates this information to users without confusing them or scaring
> them off, but I know you're quite capable of that :).
> 
> If we get painted into a corner where we don't get to do any of our own
> UX experiments for this, I think we should be prepared to resign
> ourselves to only automating the safest possible thing, and only after a
> scary warning box :/.

I agree with almost everything you and Linda said. I think Linda exposes
what might be the biggest risk: if we spend time on automation and it
does not work out for some reason, we will have spent less time
improving the UI layout, flow, and messaging (and we know based on
Linda's research that we can make significant gains without automation).

Automation also requires "backend" implementation expertise that crosses
over between the tor daemon and the browser. I have confidence that you
(Mike) could design something that would work but I have a lot less
confidence that Kathy and I would take into account everything that is
required for a successful and safe implementation. That means that
automation will require more design work and careful review by several
smart people.

-- 
Mark Smith
Pearl Crescent
http://pearlcrescent.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20170227/64f61438/attachment.sig>