[tor-bugs] #28259 [Applications/Tor Browser]: Is not saving history hurting Tor Browser retention rates?

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Oct 31 23:25:04 UTC 2018


#28259: Is not saving history hurting Tor Browser retention rates?
-------------------------------------------------+-------------------------
 Reporter:  arthuredelstein                      |          Owner:  tbb-
                                                 |  team
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  gallagher2018, ux-team, tbb-         |  Actual Points:
  usability                                      |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by pospeselr):

 = Nay Saying

 So I'm coming at this with the viewpoint that any feature that can harm
 users where adversaries have physical access is a non-starter.

 While it may attract and retain users, I think adding history
 functionality (however the data may be protected) poses too much of a risk
 for our most vulnerable users. Our adversary model in the
 [https://www.torproject.org/projects/torbrowser/design/#adversary Tor
 Browser design doc] calls out history disclosure as an explicit adversary
 goal and physical access to the user's machine a scenario we care about.

 I think a general problem with Tor Browser is that users which need the
 most security also need to be the most technically literate to be safe(for
 instance, to know about and understand the security slider). Optional
 usability features adds to this complexity.

 I think that once/if Firefox's Tor implementation becomes available, we
 should point to Firefox for those users who only care about 'network
 privacy' (anonymity, tracking prevention, etc) and for whom security is
 less of a concern.  Allocating developer resources toward the Mozilla
 effort could be a better use of effort than rolling our own securely
 encrypted history store (which would still be vulnerable to
 [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis rubber-hose
 cryptoanalysis]).

 = Actual Design Ideas

 == 'Normal' Browsing Window

 Allow history, passwords, auto-fills, bookmarks, etc to be saved to disk,
 encrypted via a master password.

 === Pros

 - Good usability for majority of users with less extreme threat models
 - More users is more good

 === Cons / Open Questions

 - Now we are responsible for correctly encrypting long-lived user data
 - Is 'normal' browsing the new default? If it's not the default, how do
 users discover it?
 - In Mexico City we shot down the idea of default enabling the built-in
 dark theme since passersby (in a library for instance) would be able to
 easily tell the user was using Tor Browser rather than vanilla Firefox.
 How do we differentiate a 'Normal' session from a 'Private' session so
 that the user can easily tell the difference but passersby can not?
 - How often to require master password? Does the browser just block out
 the user after a certain amount of time like a password manager?
 - Vulnerable to aforementioned rubber-hose cryptoanalysis
 - Would we want to store dates of page visits? Suppose a user is compelled
 to give up their Tor Browser password, and it is known from traffic
 analysis that the user may have used Tor on a given date. Timestamped Tor
 Browser entries could corroborate this.

 == 'Normal' Browsing Window + Hidden Volumes

 So for users that are compelled to give up their Tor Browser 'normal
 browsing' password, we could implement a hidden volumes feature like
 [https://www.veracrypt.fr/en/Hidden%20Volume.html VeraCrypt].

 === Pros

 - Provides some cover in the rubber-hose scenario

 === Cons / Open Questions

 - Same problems as just 'Normal' Browsing Window
 - If we store timestamps with page visit history, then the hidden volume
 feature would not work as intended in scenarios where the adversary knows
 the user connected to Tor on a certain date. Also problematic if the
 adversary knows how much traffic the user transferred through Tor and the
 provided history isn't plausible (eg the adversary sees hundreds of
 megabytes going through the user's Guard but the provided history only
 includes an entry to https://example.com).
 - Now we are responsible for correctly implementing hidden volumes

 == Separate 'Hardened' and 'Usable' Tor Browser versions

 We could maintain two Tor Browser flavors, one version with usability in
 mind where physical access is not in the threat model, and one with a
 focus on security where the stateful usability features are disabled and
 physical access is in the threat model.

 Assuming the usability features are purely client-side (so things like
 history, bookmarks, passwords, etc) and the two versions look the same on
 the network, we could increase the user base with the 'usable' browser
 users which contributes to the security of the 'hardened' browser users.

 === Pros

 - Normal users get their usability improvements
 - Increases Tor network usage because of newly attracted and retained
 users
 - We could potentially kill the security slider by partitioning our users
 - Assuming a vulnerable user correctly installs the 'Hardened' Tor
 Browser, they are now less likely to hurt themselves

 === Cons / Open Questions

 - User confusion about two different versions; how do we steer most users
 to the 'Usable' Tor Browser while ensuring vulnerable users get the
 'hardened' Tor Browser?
 - Presence on disk of the 'Hardened' Tor Browser itself could be
 incriminating
 - Now we maintain two browsers :(

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28259#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list