Opened 3 months ago

Last modified 3 months ago

#28259 new defect

Is not saving history hurting Tor Browser retention rates?

Reported by: arthuredelstein Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: gallagher2018, ux-team, tbb-usability
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


The main unique value that Tor Browser provides is network privacy. But we also enable private browsing mode by default, which means history and passwords are not saved.

That's actually pretty inconvenient for a modern web browser. Every time the user starts Tor Browser, they don't get the convenience of Restore Session, auto-login, recent pages, history-based completion, importing user data from other browsers, and Sync. This issue was raised in Gallagher et al 2018

So, we could consider allowing users to open a "normal browsing" window, that retains history and passwords and even uses "Firefox Sync". They would still get the benefit of network privacy. Saved state could be locked behind a master password, or we could remind users to use whole-disk encryption.

My hypothesis is that this approach could help retain users and enable more users to use Tor Browser as their "main browser". But it would require an analysis of the pros and cons and a careful redesign. We also would need to fix all unpatched network privacy in normal browsing.

So in this ticket I'm proposing we analyze this idea: figure out the best possible design, and determine if the benefits outweigh the costs.

Child Tickets

Change History (4)

comment:1 Changed 3 months ago by arthuredelstein

(I carefully omitted mentioning in the description whether the browser should save cache and cookies, etc. While we already have first-party isolation to prevent using these things for cross-site tracking, it's also nice to prevent long-term observation within a single site. For example, we don't want Google to have a long-term log of all of our searches. So, we could consider not retaining any supercookies. Or, we could retain supercookies only in websites where the user has been observed to log in to the site (as typically detected by the Firefox password manager).

comment:2 in reply to:  description Changed 3 months ago by gk

Replying to arthuredelstein:

The main unique value that Tor Browser provides is network privacy.

I think the main unique value Tor Browser provides is a holistic approach towards privacy (not just picking up parts of it) taking all the privacy risks into account and developing a generic solution to them. That's reflected in our design document.

Last edited 3 months ago by gk (previous) (diff)

comment:3 Changed 3 months ago 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 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 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.


  • 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 VeraCrypt.


  • 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
  • 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.


  • 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 :(

comment:4 Changed 3 months ago by mikeperry

Before migrating Torbutton options into Firefox, we had a checkbox for "Store browser history on disk". I did treat that as a first-class supported option, and I still use it today.

I don't think it is over-complicated to allow the user to opt-in to saving browser history to disk. I do not think we should consider having to encrypt it first, especially given lack of solutions to the swap file:

I think instead we should try to detect if full disk encryption and swap encryption is enabled, and warn the user if it is not. Possibly regardless of history settings, due to swap file and registry leaks.

I do think that users will want an option to store history on disk. We've done similar user surveys about bookmark-based solutions for onion service names, and only a small percentage were concerned about this risk. Those that were concerned did not bookmark (but then ran the risk of not finding/typing the correct onion service address). I bet if we did a survey about disk history, we'd find similar results.

Note: See TracTickets for help on using tickets.