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

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

> We would like feedback on this soon as we have a deadline (March 3rd) 
> to
> decide on what to do about this feature request.
> 
> Thanks!
> Isabela
> 
> ps: Linda is updating her paper once that is done we will share with
> y'all o/

Re: P.S.: I'm making changes to it for PETS until the end of Feb, and 
the camera ready is due end of March, so the finalized version will be 
available at the end of march. I've put my current version of the paper 
on a private repo because someone on the PC told me I should.

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