This page will serve as a design requirements and discussion for an Anonymous Browsing Mode. Whether or not it is implemented, the requirements and goals for such a mode will be documented here.
- 1 Anonymous Browsing Mode
- 2 Use Cases
- 3 Adversary Model
- 4 Behavior
- 4.1 User Agent
- 4.2 HTTP Headers/Activity
- 4.3 Caches and History
- 4.4 Cookies and DOM Storage
- 4.5 Location Information
- 4.6 External Protocol Handlers
- 4.7 Fonts and Font Lists
- 4.8 Clock Delta+Precision
- 4.9 Screen Resolution and Properties
- 4.10 Plug-Ins
- 4.11 Extensions/Add-Ons
- 4.12 SSL
- 4.13 Form Fill
- 4.14 Livemark updates
- 5 Interface and Options
- 6 Impact
- 7 Relevant Bugzilla Entries
Anonymous Browsing Mode
Unlike Private Browsing, which mainly attempts to protect a user from a local attacker, Anonymous Browsing will serve to minimize the amount of identifying data that is available to a remote (web or network) attacker (for example, consider the EFF panopticlick project). The main motivations behind such a mode are to prevent user tracking and fingerprinting, but there are many use cases.
Scope of this Document
This working document will serve as an explanation of why users will want Anonymous Browsing, how such a mode would behave and what will need to be different in this mode from regular browsing sessions for such a mode to be useful.
- Torbutton Design Document and Adversary Model
- An analysis of private browsing modes in modern browsers
- Brad Hill's take on Fingerprinting
Public awareness of the privacy issues surrounding using the web is rising, as evidenced by the need for advertising networks to resort to flash cookies and fingerprinting due to the frequency with which normal users clear their cookies. The popularity of privacy-enhancing addons and the private browsing modes of the major browsers also suggest that a mode that helps to mitigate ubiquitous web tracking may be a key differentiator against competing browsers.
Users of anonymous browsing mode would be concerned about tracking from Internet sites under various circumstances, and may or may not be concerned about local records on their computer's disk.
The target users of this mode may have a number of different browsing behaviours and needs. It is best to represent these behaviours as "stories", to better understand the needs of different types of users, and to properly design feature and option choices to accommodate them.
The Medical Patient/Abuse Victim
The medical patient has some kind of condition that they would prefer that ad networks not be aware of: possibly one that puts them at risk for raised medical, life, or auto insurance premiums, or carries other social stigma. Such a user may decide to use the mode after receiving mysterious targeted ads for their condition while visiting unrelated sites.
They are possibly a member of a number of online support groups that they log in to and post to under a pseudonym (such as alcoholics anonymous, narcanon, etc) using the mode.
They are likely an occasional user, and would remain logged in to social media services, their email account, and other websites continuously during normal browsing, but would prefer a clean slate for web usage relating to their condition.
They may or may not be concerned about records of anonymous web activity on their own computer. They likely use the mode from home, but may opt to use a proxy.
The Pseudonymous Blogger
The pseudonymous blogger maintains a politically or technically controversial blog that may expose them to subpoena risk to uncover their identity. There have been several cases of Apple in particular demanding the identity of bloggers posting about unreleased or otherwise secret product releases or features. Bloggers in China and other countries also face risk of attempts to identify them.
This user likely uses public wifi, a prepaid data device, a VPN, or a proxy to access the Internet, as opposed to their normal Internet connection.
If operating in the United States, this user is likely not concerned about logs on their local disk.
This user may wish to preserve their "Anonymous mode" cookies beyond a single session, but does not want them mixing with their normal cookies. They may have a seperate Facebook, twitter, and other social media accounts for their blogging persona, in addition to their regular persona.
The Anonymous Commenter
The anonymous commenter is a user who is posting relevant information to a blog post or news article. Those that truly require anonymity need it because they have inside or privileged information relevant to a story.
Most likely, they spend the majority of their Internet usage logged into a number of services online that record various things about them, and may log them into arbitrary services automatically due to federated login systems such as OpenID, and have been exposed to a number of ad networks intent on tracking them.
They use Anonymous Mode to ensure that the blog or news site (which may have numerous advertising partnerships) would have a very hard time correlating their comment to their normal browsing.
They likely do not care about their activity being recorded to their computer's disk. They most likely use the mode from home, but may use public wifi or a proxy.
The Whistleblower/Anonymous Tipster
Similar to the Anonymous Commenter, the whistleblower uses the web normally for the majority of the time. However, at some point they discover wrongdoing at their workplace or otherwise need to anonymously contact the press.
The whistleblower will only use the mode once or rarely, though they may create an email account to establish communication with the press.
They will likely use public wifi, a prepaid data device, and/or a proxy.
Just because you're paranoid doesn't mean they aren't out to get you.
They likely use the mode continuously from home.
The Privacy Power User
The power user would prefer to maintain multiple independent identities logged in to various social media services. They would prefer to be able to configure their browser to quickly switch between these identities, which may represent different personae, or may simply represent individual services or websites that they do not want to be logged in to concurrently.
They likely author independent blogs, have multiple email accounts, post on multiple mailinglists/web forums, contribute to a number of open source projects, and/or operate multiple twitter feeds, all under different pseudonyms.
They likely use a prepaid data device or proxy of some sort. They are not concerned about their activity being stored on their computer: in fact they would prefer it, to ease their ability to remain logged in to services and retain history and bookmarks without suffering the privacy consequences.
They would likely also prefer the ability to configure their browser to only retain cookies for certain sites, and to periodically clear all other browser state. They would be satisfied if these features were available only through addons, as opposed to core browser features. However, it looks as if the proposed Weave Identity project called Account Manager could be extended to support this use case.
The adversary is interested in tracking the user by any means necessary. However, mechanisms that are already being addressed by other projects will not be discussed in this document. Private Browsing Mode, in particular, is primarily concerned with preventing the storage of browsing data.
This document will focus on network-based tracking mechanisms. In particular, the adversary is interested in correlation of regular mode browsing to anonymous mode browsing using unique identifiers, in obtaining location information, and in fingerprinting the user's browser characteristics.
The adversary may have many motivations for doing this, but to keep scope simple, it may be best to assume that their primary motivation is to correlate user web activity for purposes of tracking users against their will for purposes of serving ads. A large class of adversaries (the ad networks) are interested in deploying semi-intrusive mechanisms to do so, in light of increasing number of users choosing to clear their cookies regularly, and in light of potential future Third Party Cookie protection mechanisms implemented by the major browsers.
This section describes the major browser behaviours the mode will need to alter in order to address the adversary model. Many of these come from the Fingerprinting page, but some are just general privacy mechanisms.
Ideally, these requirements would be satisfied in such a way as to make it difficult or impossible to determine if Anonymous Browsing is enabled, but this may come at a cost of some resistance to fingerprinting.
User agent can be handled two different ways. One way would be to simply reduce the amount of entropy provided by the standard user agent headers. There is a bug for this, but some high-entropy items may end up being too useful to drop, such as the operating system and Accept-Language. Further, dropping items from the UA string while only in Anonymous Browsing Mode would reveal the fact that the user is using the mode.
The other way to handle this would be to simply pick a user agent string that is determined to be one of the more common Firefox user agent strings currently in use. This is the approach taken by Torbutton.
It should be noted that the Firefox minor revision and other properties can still be determined by inspecting Components.interfaces, so Bug 429070 would need to be fixed for these protections to have any real value.
User-Agent string, Accept headers, etc.
Referer and querystring identifiers: Protect path of HTTP Referer Header when in a possible future anonymous mode
Caches and History
Cookies and DOM Storage
External Protocol Handlers
Fonts and Font Lists
Installed font presence provides a large amount of identifying information. Currently, the major culprit of leaking this information is plugins, as they provide an unsorted complete enumeration of all system fonts.
Because of the issues with localization and finding a common set of default fonts, the best option here is probably to limit the number of local fonts a tab can load. Precedence can be given to remote font files so they do not count against this limit. Research should be performed to find the typical number of fonts loaded by the top 1000 sites and set the limit high enough not to break any of them.
The Date object currently provides millisecond accuracy. This accuracy can be used as an identifier based on clock skew, or can be used to accurately measure user behaviours for use in fingerprinting.
At least two companies claim to use this accuracy to fingerprint users when other methods fail: http://arstechnica.com/tech-policy/news/2010/02/firm-uses-typing-cadence-to-finger-unauthorized-users.ars
One possibility might be to quantize Date values to the second, and then add random, monotonically increasing amounts of milliseconds to subsequent calls during anonymous browsing mode, along with a random per-page or per-origin offset. Another possibility would be to simply bin the milliseconds to low resolution (250ms or so). Studies would need to be done to determine how effective either approach is.
Additionally, interval timers and event timestamps would need reduced resolution, due to computational fingerprinting: http://w2spconf.com/2011/papers/jspriv.pdf
Screen Resolution and Properties
Desktop resolution provides about 5 bits of identifying information, and window and decoration sizes provide yet more. This information is available both through window.screen and CSS media queries.
There are a couple of options for anonymous browsing mode to handle this data. One would be to lie, and to present websites with a common desktop resolution, and round the reported browser resolution to some multiple of pixels.
A another option would be to tell websites that the desktop resolution is the render window, and resize the render window to either a popular common resolution, or to a multiple of 50px. The downside of this approach is that it has shortcomings when the window is maximized, because window decoration and scrollbar sizes will prevent rounding to an actual multiple of 50px.
Some combination of these could help to make it hard to determine if the user is actually in Anonymous browsing mode. For example, providing a valid, but resized render window, lying about the size of the actual window to some standard platform size, and lying about the desktop size to return the most popular resolution just larger than the current window size.
Plugins are abysmal for privacy in several respects. First, because of the wide variety of browser plugins, the presence or absence of plugins from navigator.plugins actually provides a large amount of information.
Second, plugins themselves will happily provide websites with a large amount of identifying information about a user, including their list of installed fonts, their CPU model and speed, their local interface IP addresses, username, hostname, and so on. In addition, plugins can also have their own data and cookie stores, that they allow websites to manipulate.
The best course of action may be to develop an independent policy for what plugins are allowed to do in anonymous and private browsing modes with respect to the above information. Any plugins that do not advertise their adherence to this policy should be disabled during the mode. This is obviously a long-term strategy.
Similarly, another option might be to leverage the out of process execution of plugins to restrict their ability to access the local system while the mode is enabled.
Shorter-term, it may be best to leverage the permissions manager to disable all plugins by default. If an object tag or an access to window.plugins is detected, the chrome could ask the user if they would like to enable that plugin for that top-level domain only. Keeping plugin permissions isolated to the top-level urlbar domain would at least cut down on linkability between domains.
The SSL Layer currently exposes a few different pieces of identifying information that would need to be altered while the user is in anonymous browsing mode. Stored client certificates must be disabled during the mode. All current SSL session identifiers must be cleared upon entering the mode.
Stored server and CA certificates may also need to be optionally disabled, though this should be left to user preference.
Finally, the SSL handshake also contains a timestamp from the client. A small random, per-domain offset could be added to it, but since it is already truncated to the second, this may not be terribly important.
Interface and Options
One way to provide this mode would be to expose it as an option for private browsing mode. If the actual web usability impact can be kept low, there should be no reason why this couldn't be enabled by default for Private Browsing Mode sessions.
However, if the impact is potentially higher, the browser could provide two independent modes, one for an "Off the record" mode, where nothing is recorded on disk, and another for a "Tracking Resistance" mode, that enables the features here.
According to An analysis of private browsing modes in modern browsers, Private Browsing Mode may be suffering from "Mode Error", where users enable the mode, but forget to ever disable it because of poor UI indication. A better UI might provide clear graphical indication that private browsing mode is enabled for a particular window.
As far as options, in general it is best to minimize options that have an effect on browser behavior. Such options become fingerprintable attributes.
However, visual and local preferences are still desirable. Some users may prefer that there be *no* UI indication that private browsing mode is enabled. Others may prefer that their non-private tabs and windows not be closed, so that they can use the two modes concurrently. Some users may not want Private Browsing Mode to write any data to disk, while others may only care about web tracking.
How much will this impact web experience for the users? Sure we can break things in the name of anonymity if users opt for such a mode, but how much is tolerable?