Re: [tor-dev] Tor meets real users

[Lucky Green <shamrock@xxxxxxxxxxxxxx>]

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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev