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

[Linda Naeun Lee]

Mike,

Thanks for the reply!

On 2017-02-23 19:16, isabela wrote:
> + 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.

I didn't know this. Thanks for the information. I'm glad we have an 
updater now.

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

I totally agree with this. Most (80%+) of the people who couldn't 
connect directly to Tor and couldn't connect with the recommended obfs3 
bridge failed to connect. And they usually try the previous two options 
before getting the right configuration anyway. Overall, even users who 
don't need such fancy configurations make mistakes along the way, just 
because it's a foreign concept to them. I think that eliminating user 
error will be much safer, and I am a total advocate of this. My research 
can be used to see how many people this can help (i.e. "64% of attempts 
to connect on the first try (across different censorship environments) 
failed.").

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

Yep! This is something I can design/handle.

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

Deciding what to include in the automated testing is something other 
people should handle.

>> 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 hope that eventually, we would get funding to do work that helps us. 
And I don't like the idea of funders being able to demand features from 
us without properly understanding the problem. We can talk about what we 
can do, if we are in that corner. Hopefully we won't be! (My impression 
is that it's still to be decided.)

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