On 2011-05-12 07:59, Andrew Lewman wrote:
A short while ago, I did a training for some activists from a country that is hostile to the Internet. These people were some of the more technical people from their community. There was a mix of Windows and OS X laptops in the session. English was their third language, for added fun.
I walked them through finding tor browser bundle, downloading it, verifying it, unzipping it, and starting it. Here was the first problem. They couldn't find tbb on the download page. Their comments were that all these files and releases on the page were confusing. They wanted just one thing to look at, pick their operating system, and go. And they wanted the one thing to automatically detect their language preferences for tbb.
Easily solved. A download page should be workflow based. You can lay it out as columns or successive pages. Example:
What is your OS? (pre-selected based on the browser string)-> drop down list -> download link. For the main recommended product only, alternative versions should not be suggested, but be available on a drill-down page. See next comment.
(You will also want an index page containing all downloadable versions, but that page should be linked from the bottom of the download page. "For alternative versions of our product, click here")
I ended up pointing them at tpo/torbrowser, which they also thought was confusing. The aforementioned desires weren't satisfied on this page, but at least they could find their preferred language. They all commented that back home, a 24MB file was too big, and can't they get it via bittorrent or some other piecemeal way? A 24mb file would take hours to download.
This is one of those rare situations where two entirely unrelated issues combine to confuse even some of the more experienced product managers.
The first issue is the UE problem, meaning page design bug, of giving the user choices inside the default work flow of having to select a particular product, such as tpo/torbrowser. There should only be one default choice per OS.
The other issue has too sub-issues. The first sub-issue is that users can be whiny, as they are here. How are those users with their shiny MacOS laptops getting OS updates? How large are those OS updates? How big was that last iTunes update? Oh, those updates are larger than 24 MB?
Granted, how users obtain other software is a follow-up question the PM must ask in this situation to either learn how to best adjust user expectation or learn which distribution mechanism to emulate.
The second sub-issue (only useful to know after having figured out the first) is which download options to offer as part of the regular work flow. http/our download manager/BT are common, but that doesn't necessary make them the correct choices for Tor.
None of them had pgp installed, and therefore no way to verify the .asc and zip file.
That is to be expected. (And I am confident was expected by Andrew).
Most of them figured out to click inside the resulting folder and start the 'start tor browser' program. For all of the macs, the tbb didn't start. The people had to restart the system and then clicking on 'start tor browser' worked as expected.
Bug of some sort. (Possibly in the installer not prompting the user for the required reboot).
As tbb was starting up, nearly all of them clicked on 'start tor browser' one to three times more, because they didn't see anything starting up. In fact, it was starting, it just wasn't instantaneous. I worry about forcing a splash screen that announces "I'm using Tor!" on the screen, but at the same time, it would let users know that tbb is starting.
You are striving for user notification of actions in 3/10th of a second. Anything more than that and the user will perceive lag. Note that 3/10 of a second is plenty of time to load a stub that reads "Please wait, Tor is loading". Take much longer after that notice is presented to the user for the final app to load and you'll want some visual indicator of progress, such as a spinning ball.
Once vidalia started, no one waited for tbb firefox to start, but rather started their own browser and tried to use it. Once tbb firefox started up, in some cases, minutes later, they were confused. Why didn't tbb firefox start right away instead of this useless vidalia control panel?
Again, multiple issues here. Clearly the browser is loading too slowly, which may be inherent to the browser. If so - and if it is not possible to make the browser load faster by stripping it down - you are using the wrong default browser. Obvious area to explore here is how fast the users' regular browsers are loading. Must be faster than tbb firefox or they wouldn't have been able to start their own browsers in the interim. Figure out why their default browsers are loading faster and go from there.
A few of them felt the need to explore the vidalia control panel since we showed it to them. As if to say, 'there are buttons you are showing me, I just click and explore.'
UE design bug. The user should only be presented with UI elements that the user needs to interact with to complete the task. Anything else should be buried in a "Tools" (think Chrome) menu or Tray icon. If what you are loading is a new browser, there shouldn't even be a Tray icon, but an additional button or sub-menu in the browser.
Once tbb firefox started, they were ok with using firefox over tor just fine. The first thing many of them did was to login to facebook or gmail over tor to see if it was different. None of them verified the ssl cert presented for facebook or gmail logins. For those that did login to gmail, gchat didn't work due to the lack of Flash in tbb firefox.
Expected behavior. No normal user verifies SSL server certs, knows they exist, or knows how to verify a cert even if they knew it existed. If the browser had reported an error with the cert the users would have clicked to ignore the mismatch. If the browser were to block access to the site due to a bad cert, the user would have switched to a browser that doesn't exhibit the blocking behavior. Human factor studies abound.
We then tried to configure their chat clients for tor. Adium on the mac was fairly easy. The variety of clients on windows wasn't so easy. A few wondered about logging in over ssl, but never did because the services didn't offer it (aol, msn, gchat). I showed the windows people pidgin, but they liked their native apps and didn't see why one multi-protocol app was better.
Unachievable scope combined with misguided user expectations.
The Tor Project would do well to not ADHD its activities into fixing all security ills of this world, such as email encryption, full disk encryption, or how to secure data once it leaves the exit node. All are real problems, but the one problem that is the core focus of Tor is difficult enough and you have barely enough resources to address even that.
There more interesting lesson that comes out of your experience is far from novel, but it bears repeating: absent other guidance, users expect security products, including anonymity products, to sprinkle security fairy dust over the user's existing work flow. We do not know how to achieve this goal given the present state of the art in computer science.
Consequently, providing anonymity services to the user requires work flow changes from the user. Users will not engage in work flow changes within their normal user environment. You have to change the environment to make the work flow changes acceptable and employed by the user. You still run the very real risk that the user will not accept the new environment, but at least it is possible to get the user to change behavior in a new environment, while it is not possible to get the user to change behavior in the old environment.
The conclusion from this is pretty straight forward, though perhaps not welcome: it is called a virtual machine.
The experience continued through pidgin with OTR, installing pgp for email and verifying files, and a general talk about openssl certificates, what they mean, and what verification of a cert entails.
Yikes. Talk about ambitious. :-)
The relevant tor experience was what I wanted to communicate and for us to start thinking through ways to address it. Perhaps Mike's desire for a anonymous browser is a correct path for usability and better anonymity for the user. I believe torfox and torora have both come to the same conclusion (at different times) as well.
Hope my comments help, they are based on decades in this industry and are intended to help. Feel free to contact me with any questions.
--Lucky