Feedback on design decision for Tor Launcher
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. 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?'. 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#Designco... 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? 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/
On 2017-02-21 06:30, isabela@riseup.net wrote:
Yay!
:)
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.
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).
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
Linda Naeun Lee:
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#Designco... 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 :/. -- Mike Perry
On 2/21/17 5:02 PM, Mike Perry wrote:
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 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/
Mark, On 2017-02-27 11:06, Mark Smith wrote:
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 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.
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
Mark Smith:
This specific problem sounds like it will have UX consequences if we have automation or not. Without automation, users have to manually try a bridge, wait for it to fail, and then enter a new one. With automation, we can at least say "This may take a while. Go have some coffee" rather than hold the user hostage. Also, I think that exposing a hidden Tor pref to lower the initial bootstrap timeouts just for this automation test should be a simple change. However, I grant that there may be other technical issues with automation that could surprise us. It is risky to promise that it will work well. Do you know of any other bootstrap issues or control port weirdness that may cause problems with automating? Do you expect there to be lots of surprises? As for implementing the probing and automation entirely in core-tor, it will be a somewhat radical change from how all the Tor logic currently handles bridges. For every bridge in the torrc, Tor makes a connection to that bridge to download its descriptor from it, at a regular interval. It is only after this that it begins the process of selecting a bridge to use. However, Tor continues to attempt to contact failed bridges periodically to see when they are available, and on restart. The newer guard logic may make this simpler to fix, though. However, I think the real winning scenario here is full bridgedb automation: talking to bridgedb via a domain-fronted REST API to get more bridges to try. I think such an API and mechanism would be more quickly done in the browser than in core-tor. But it does mean we have to reimplement this automation for each client application that uses Tor... My preference is to implement it where it is easiest first, and if that works well, we can migrate it to core-tor later, since I suspect the core-tor work will be much more involved. However, I could see probing still being done best from core-tor, and bridge fetching being done best from the browser. That does seem possible. Can you go into the additional problems you would expect to have with doing automation from the control port?
In terms of getting more censored users to use Tor, I think the bridge selection, configuration, and connecting flow is the biggest barrier. I believe that this is inherent in the manual configuration problem. No matter what the UI does, without automation, these steps will remain, and users will give up part way through, especially if some bridges are failing.
So for the simple case of just automating testing only the bridges that we have configured in the browser, do you think this is still hard? The code already tries to connect to the bridge you select, and if bootstrap fails, it takes you back to the beginning of the wizard. Timeout durations aside, simply trying the next one in the pref list shouldn't be that hard, or am I missing something? As for the BridgeDB interaction, you're right that will require decisions around what bridge types to fetch, etc. It will need more thought and a proper specification. -- Mike Perry
On 2017-02-27 16:55, Mike Perry wrote:
I agree with you, Mike. But I think that there are three potential designs: 1) the current one, where we have the users choose bridges--we can improve the interface and still get some benefits. 2) a 'naive' automated system, where we choose the bridges for the users--I'm talking literally just trying the hard coded options in an order that makes sense (obfs3, then meek, or whatever the recommended order is). This would eliminate the UX issue AND be safer than 1, since people make mistakes and we would make less. 3) your proposed automated system, where Tor launches a process to talk to the network and get assigned a bridge. This would eliminate both the UX issue and be safer than 2). I think it is feasible to do 1) or 2). 3) would take some time. My vote is for 2), then 1), then 3). I kind of want to do 1) to tell funders to shove off and not demand things, but I'm ignoring that.
I think the 'naive' automation would not have any more complications than the current version, and would just take a lot of user pain out of the equation. I don't know how complicated the bridgeDB proposal would be.
-- Current Key: https://pgp.mit.edu/pks/lookup?search=lindanaeunlee GPG Fingerprint: FA0A C9BE 2881 B347 9F4F C0D7 BE70 F826 5ED2 8FA2
There are already multiple torrc options for this: some modify various timeouts, others modify the rate at which we fetch directory documents after we connect. However, they are untested, and some values are known to cause bootstrap failures.
I worry that on very slow connections, reducing timeouts will cut off users who would have previously had a working configuration. We've had issues in the past with IPv6 support: while the major ones are fixed in 0.3.0 (and always worked via IPv6 bridges), there may still be some remaining bugs. I had been considering automatic client selection of IPv4/IPv6, as OnionBrowser (iOS) currently uses their own automated selection process so they can pass Apple's IPv6-only tests. We should design this in such a way that it's extensible if we want to try multiple bridges and PTs. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
On 2017-02-27 16:18, teor wrote:
Hmm, interesting. There are strategies to get users to wait! We could show them an informational video, give them a tour of the security features, or something like that (all of which are nice-to-have things I would have worked on way later).
-- Current Key: https://pgp.mit.edu/pks/lookup?search=lindanaeunlee GPG Fingerprint: FA0A C9BE 2881 B347 9F4F C0D7 BE70 F826 5ED2 8FA2
This isn't what I meant: If we tell tor to wait for less time for a connection to complete, tor will break for all users who required the higher timeout. This is a separate issue from convincing the *user* to wait. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
On 2017-02-28 12:12, teor wrote:
Oh, I see.
-- Current Key: https://pgp.mit.edu/pks/lookup?search=lindanaeunlee GPG Fingerprint: FA0A C9BE 2881 B347 9F4F C0D7 BE70 F826 5ED2 8FA2
teor:
The main thing a prober wants to do is see if the initial TLS handshake to the bridge succeeds. That's what I meant by "initial timeouts". I didn't see a pref for this. Did I miss it? I'm guessing that this timeout can be pretty low - even on slow connections, a TLS connection should complete in seconds, rather than minutes. After the TLS connection succeeds, the rest of the timeouts can remain as-is/be pretty high. Most/all censors completely block connections from happening in the first place, so once something succeeds, then we can wait as long as we like. -- Mike Perry
participants (5)
-
isabela＠riseup.net -
Linda Naeun Lee -
Mark Smith -
Mike Perry -
teor