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

Fri Feb 24 01:17:15 UTC 2017

+ linda

On 2/21/17 17:02, Mike Perry wrote:
> Linda Naeun Lee:
>> On 2017-02-21 06:30, isabela at riseup.net wrote:
>>> Hello TBB team! and Linda ;)
>>>
>>> I would like to ask your feedback on some feature decisions we have to
>>> make for Tor Launcher.
>>>
>>> We got fund to work on improving Tor Launcher user experience.
>>
>> Yay!
>>
>>> We are going to use Linda's paper as our reference on how we will go
>>> about that. We might add some new things on the top of the suggestions
>>> she makes on her paper, I know Linda herself has some stuff she wants to
>>> consider that is not there.
>>
>> :)
>>
>>> But! This email is a question on a more specific thing, a question that
>>> comes out whenever one talks about Tor Launcher is 'why not automate it?'.
>>
>> The quick answer is, "we might be able to do just as well without
>> automation, and if we can, we should!" And that they should let us try.
>>
>>> And our sponsors are asking us that exactly question. I am in favor of
>>> making it easier for the user that will prefer not to deal with
>>> settings, but I am also a big fan on making sure our users are safe. As
>>> I believe you all are!
>>>
>>> Our sponsors are asking for the PT selection part of the launcher to be
>>> automated. For us to test the user network and figure out the best
>>> solution to get the user connected to the Tor network - we could leave
>>> an option for those users who would prefer to go through settings and
>>> configure it as they will.
>>>
>>> That said, Linda has specific design considerations that lead her to
>>> decide against that because of user security.
>>>
>>> https://trac.torproject.org/projects/tor/wiki/doc/TorLauncherUX2016#Designconsiderations
>>>
>>> Another thing to consider is that we this will already obtain enormous
>>> gains with the improvements we will be doing at the Tor Launcher step,
>>> even without this automation piece.
>>>
>>> Linda's paper shows that.
>>>
>>> So, I would prefer we don't base this decision on 'gains' for Tor (of
>>> course automation will increase metrics is the easiest growth hack
>>> trick) but to base it on the user and their security.
>>>
>>> What we are looking for here is feedback on those points on 'design
>>> considerations' to make sure we are not missing anything here.
>>>
>>> Does the threats there has enough weight for us to not consider
>>> automation? Does anyone think different or has other points we are not
>>> considering?
>>
>> I'm certainly discouraging moving it from what it is now straight to an
>> automated thing, because I think that's going to take time to implement such
>> a thing and we can help people a LOT just by making design changes. I think
>> this is what you should emphasize.
>>
>> I think we can have WAYYYY better design than what I have in my paper, too.
>> If I could redesign it now, I'd try to: 1) put everything on one screen
>> (like how it is in the browser, if you go to connection settings), 2)
>> simplify even more, 3) give advice that doesn't require inputs (i.e. "try
>> using X if you are in countries a,b,c").
>>
>> Something that also isn't automated is asking something like "you are about
>> to make a connection to Tor. is this okay?" or give options like "connect"
>> and "connect with extra caution (this may be slower)"--and this can be the
>> difference between a direct connection or use an unlisted bridge running
>> some obfuscation protocol.
>>
>> I think that the threats there are not necessarily enough to deter us from
>> automation. My point in the paper is that automation is not as simple as
>> people think, and that this needs to be done carefully. With proper tone,
>> consent, and miscellaneous things (user education, SEO-ing official tor
>> mirrors, etc.), automation can be done.
>>
>> I think we can get it to be ALMOST as easy as automation if we design it
>> right, though. And if we can, then we should do that instead. I have no
>> evidence to support that case, but that's my two cents. We can even test the
>> new design against automation (i.e. just compare it to a 100% success rate
>> and how many seconds it would take to connect with an automated process).
> 
> First off, I agree with everything you said above, Linda. And your
> Design Considerations page captures the current set of concerns well.
> 
> For brief historical context: The Tor Launcher configuration UI is the
> way it is because it was designed before Tor Browser had an updater.
> This meant that any automation would be done *every* time the user got a
> new copy of TBB. This was clearly unsafe and completely unacceptable, so
> we had to make everything an explicit choice.
> 
> 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
> 
> 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 :/.
> 
> 
> 
> 
> _______________________________________________
> tbb-dev mailing list
> tbb-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
>