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

[Linda Naeun Lee]

Mark,

On 2017-02-27 11:06, Mark Smith wrote:
> 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.

Good point. Design changes are something I can mostly handle on my 
own/within my own team (aside from the fact that someone on the tbb team 
might need to tweak the code/accept our changes).

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

I don't know how much this automation scheme is hashed out, how much 
resources we are willing to put into this, etc. I'm willing to put in 
the effort to either make design changes that have a manual or automated 
configuration scheme.

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

Good point.

Let me know what we choose to do! I'd be happy to discuss, if that helps 
the decision process.

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