Is not saving history hurting Tor Browser retention rates?
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.
Activity
(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).
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.
= 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.
=== 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 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 :(
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: https://trac.torproject.org/projects/tor/ticket/17367
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.
Hello! Author of the paper in question, here.
Addressing the comments of gk and pospeselr, I think if saving history and offering a password manager were available in the Tor Browser, it should definitely be dependent on the threat model of the user. I think there are many threat models in which considering a local adversary makes perfect sense, and that the encryption of the information such as history and passwords is not always enough to protect people with a local adversary in certain regimes, such as the UK and others, where mandatory key disclosure is a tool that law enforcement could use to destroy anonymity, or hold people who have encrypted histories in prison indefinitely. However, in other regimes that do not have mandatory key disclosure laws, such as the US, encryption is enough to protect the history and passwords of the person using the Tor Browser.
However, for people who do not have a local adversary, the concept of disk avoidance in the TB design document does not make much sense. It makes TTB less usable than other browsers for no real benefit.
The original context in which I proposed this solution in the paper was to have an "adversary wizard" such that people could choose their adversary/adversaries and have the disk avoidance features turn on and off for them, based on their selections. If that is too burdensome or not realistic, however, it may simply be sufficient to have an option to allow disk avoidance in preferences, with having the safer option (not storing history or passwords) as the default. I want TTB to be more usable, certainly, but security is most definitely the primary priority in my mind.
Either way, I don't think that this should be an option that remains unconfigurable for the average person using Tor. It may be possible to have three settings for this:
- Default, current setting. Disk avoidance remains.
- Disk avoidance is turned off, and all history is encrypted and requires a passphrase at TTB launch.
- Disk avoidance is turned off, no encryption is used and no passphrase is required. (I don't like this one, but I could see some users who really aren't worried about local adversaries requesting it).
However, there are pros and cons to each of these settings. I think they're worth discussing in more detail, for anyone who is interested in weighing in.
Trac:
Username: kevun
