canmove, Confirmed users
1,537
edits
Security/Anonymous Browsing: Difference between revisions
→Metadata
| (23 intermediate revisions by 2 users not shown) | |||
| Line 20: | Line 20: | ||
Relevant Links: | Relevant Links: | ||
* [https://www.torproject.org/torbutton/design/ Torbutton Design Document] and [https://www.torproject.org/torbutton/design/#adversary Adversary Model] | * [https://www.torproject.org/torbutton/design/ Torbutton Design Document] and [https://www.torproject.org/torbutton/design/#adversary Adversary Model] | ||
* [http://crypto.stanford.edu/~dabo/pubs/abstracts/privatebrowsing.html An analysis of private browsing modes in modern browsers] | |||
* [[Fingerprinting]] | * [[Fingerprinting]] | ||
* [http://www.w3.org/wiki/Fingerprinting Brad Hill's take on Fingerprinting] | |||
=Use Cases= | =Use Cases= | ||
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. | 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 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. | ||
| Line 95: | Line 97: | ||
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. | 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== | ==User Agent== | ||
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 [https://bugzilla.mozilla.org/show_bug.cgi?id=http-fingerprint 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=429070 Bug 429070] would need to be fixed for these protections to have any real value. | |||
==HTTP Headers/Activity== | |||
User-Agent string, Accept headers, etc. | |||
Referer and querystring identifiers: {{bug|587523|Protect path of HTTP Referer Header when in a possible future anonymous mode}} | |||
==Caches and History== | ==Caches and History== | ||
==Cookies== | ==Cookies and DOM Storage== | ||
==Location Information== | ==Location Information== | ||
| Line 107: | Line 121: | ||
==Fonts and Font Lists== | ==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. | |||
There are ways to [http://flippingtypical.com/ query fonts for existence] in JavaScript and CSS, but this issue is not really worth dealing with until the plugin problem is solved, or it is decided that non-compliant plugins should be disabled. | |||
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. | |||
==Clock Delta+Precision== | ==Clock Delta+Precision== | ||
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== | ==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 [https://developer.mozilla.org/En/CSS/Media_queries 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. | |||
==Plug-Ins== | ==Plug-Ins== | ||
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. | |||
==Extensions/Add-Ons== | ==Extensions/Add-Ons== | ||
| Line 129: | Line 174: | ||
==Form Fill== | ==Form Fill== | ||
==Livemark updates== | |||
=Interface and Options= | =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 [http://crypto.stanford.edu/~dabo/pubs/abstracts/privatebrowsing.html 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. | |||
=Impact= | =Impact= | ||
| Line 144: | Line 201: | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=448743 Bug 448743] | * [https://bugzilla.mozilla.org/show_bug.cgi?id=448743 Bug 448743] | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=435159 Bug 435159] | * [https://bugzilla.mozilla.org/show_bug.cgi?id=435159 Bug 435159] | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=418986 Bug 418986] | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=448743 Bug 448743] | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=575230 Bug 575230] | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=440892 Bug 440892] | |||