Add design doc draft. (433b74d91) - tor-webwml.git

projects/en/torbrowser/design/index.html.en

...	...	@@ -0,0 +1,955 @@
	1	+<?xml version="1.0" encoding="UTF-8"?>
	2	+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
	3	+<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The Design and Implementation of the Tor Browser [DRAFT]</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /></head><body><div class="article" title="The Design and Implementation of the Tor Browser [DRAFT]"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Erinn</span> <span class="surname">Clark</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:erinn_torproject\org">erinn_torproject\org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:sjmurdoch#torproject\org">sjmurdoch#torproject\org</a>></code></p></div></div></div></div><div><p class="pubdate">Sep 29 2011</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id2881557">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary">1.1. Adversary Model</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Security Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">3. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">3.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">3.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">3.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolation">3.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">3.5. Cross-Domain Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">3.6. Cross-Domain Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">3.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#click-to-play">3.8. Click-to-play for plugins and invasive content</a></span></dt><dt><span class="sect2"><a href="#firefox-patches">3.9. Description of Firefox Patches</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Packaging">4. Packaging</a></span></dt><dd><dl><dt><span class="sect2"><a href="#build-security">4.1. Build Process Security</a></span></dt><dt><span class="sect2"><a href="#addons">4.2. External Addons</a></span></dt><dt><span class="sect2"><a href="#prefs">4.3. Pref Changes</a></span></dt><dt><span class="sect2"><a href="#update-mechanism">4.4. Update Security</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Testing">5. Testing</a></span></dt><dd><dl><dt><span class="sect2"><a href="#SingleStateTesting">5.1. Single state testing</a></span></dt></dl></dd></dl></div><div class="sect1" title="1. Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2881557"></a>1. Introduction</h2></div></div></div><p>
	4	+
	5	+This document describes the <a class="link" href="#adversary" title="1.1. Adversary Model">adversary model</a>,
	6	+<a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">design requirements</a>,
	7	+<a class="link" href="#Implementation" title="3. Implementation">implementation</a>, <a class="link" href="#Packaging" title="4. Packaging">packaging</a> and <a class="link" href="#Testing" title="5. Testing">testing
	8	+procedures</a> of the Tor Browser. It is
	9	+current as of Tor Browser 2.2.32-4.
	10	+
	11	+ </p><p>
	12	+
	13	+This document is also meant to serve as a set of design requirements and to
	14	+describe a reference implementation of a Private Browsing Mode that defends
	15	+against both local and network adversaries.
	16	+
	17	+ </p><div class="sect2" title="1.1. Adversary Model"><div class="titlepage"><div><div><h3 class="title"><a id="adversary"></a>1.1. Adversary Model</h3></div></div></div><p>
	18	+
	19	+A Tor web browser adversary has a number of goals, capabilities, and attack
	20	+types that can be used to guide us towards a set of requirements for the
	21	+Tor Browser. Let's start with the goals.
	22	+
	23	+ </p><div class="sect3" title="Adversary Goals"><div class="titlepage"><div><div><h4 class="title"><a id="adversarygoals"></a>Adversary Goals</h4></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Bypassing proxy settings</strong></span><p>The adversary's primary goal is direct compromise and bypass of
	24	+Tor, causing the user to directly connect to an IP of the adversary's
	25	+choosing.</p></li><li class="listitem"><span class="command"><strong>Correlation of Tor vs Non-Tor Activity</strong></span><p>If direct proxy bypass is not possible, the adversary will likely
	26	+happily settle for the ability to correlate something a user did via Tor with
	27	+their non-Tor activity. This can be done with cookies, cache identifiers,
	28	+javascript events, and even CSS. Sometimes the fact that a user uses Tor may
	29	+be enough for some authorities.</p></li><li class="listitem"><span class="command"><strong>History disclosure</strong></span><p>
	30	+The adversary may also be interested in history disclosure: the ability to
	31	+query a user's history to see if they have issued certain censored search
	32	+queries, or visited censored sites.
	33	+ </p></li><li class="listitem"><span class="command"><strong>Location information</strong></span><p>
	34	+
	35	+Location information such as timezone and locality can be useful for the
	36	+adversary to determine if a user is in fact originating from one of the
	37	+regions they are attempting to control, or to zero-in on the geographical
	38	+location of a particular dissident or whistleblower.
	39	+
	40	+ </p></li><li class="listitem"><span class="command"><strong>Miscellaneous anonymity set reduction</strong></span><p>
	41	+
	42	+Anonymity set reduction is also useful in attempting to zero in on a
	43	+particular individual. If the dissident or whistleblower is using a rare build
	44	+of Firefox for an obscure operating system, this can be very useful
	45	+information for tracking them down, or at least <a class="link" href="#fingerprinting">tracking their activities</a>.
	46	+
	47	+ </p></li><li class="listitem"><span class="command"><strong>History records and other on-disk
	48	+information</strong></span><p>
	49	+In some cases, the adversary may opt for a heavy-handed approach, such as
	50	+seizing the computers of all Tor users in an area (especially after narrowing
	51	+the field by the above two pieces of information). History records and cache
	52	+data are the primary goals here.
	53	+ </p></li></ol></div></div><div class="sect3" title="Adversary Capabilities - Positioning"><div class="titlepage"><div><div><h4 class="title"><a id="adversarypositioning"></a>Adversary Capabilities - Positioning</h4></div></div></div><p>
	54	+The adversary can position themselves at a number of different locations in
	55	+order to execute their attacks.
	56	+ </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Exit Node or Upstream Router</strong></span><p>
	57	+The adversary can run exit nodes, or alternatively, they may control routers
	58	+upstream of exit nodes. Both of these scenarios have been observed in the
	59	+wild.
	60	+ </p></li><li class="listitem"><span class="command"><strong>Adservers and/or Malicious Websites</strong></span><p>
	61	+The adversary can also run websites, or more likely, they can contract out
	62	+ad space from a number of different adservers and inject content that way. For
	63	+some users, the adversary may be the adservers themselves. It is not
	64	+inconceivable that adservers may try to subvert or reduce a user's anonymity
	65	+through Tor for marketing purposes.
	66	+ </p></li><li class="listitem"><span class="command"><strong>Local Network/ISP/Upstream Router</strong></span><p>
	67	+The adversary can also inject malicious content at the user's upstream router
	68	+when they have Tor disabled, in an attempt to correlate their Tor and Non-Tor
	69	+activity.
	70	+ </p></li><li class="listitem"><span class="command"><strong>Physical Access</strong></span><p>
	71	+Some users face adversaries with intermittent or constant physical access.
	72	+Users in Internet cafes, for example, face such a threat. In addition, in
	73	+countries where simply using tools like Tor is illegal, users may face
	74	+confiscation of their computer equipment for excessive Tor usage or just
	75	+general suspicion.
	76	+ </p></li></ol></div></div><div class="sect3" title="Adversary Capabilities - Attacks"><div class="titlepage"><div><div><h4 class="title"><a id="attacks"></a>Adversary Capabilities - Attacks</h4></div></div></div><p>
	77	+
	78	+The adversary can perform the following attacks from a number of different
	79	+positions to accomplish various aspects of their goals. It should be noted
	80	+that many of these attacks (especially those involving IP address leakage) are
	81	+often performed by accident by websites that simply have Javascript, dynamic
	82	+CSS elements, and plugins. Others are performed by adservers seeking to
	83	+correlate users' activity across different IP addresses, and still others are
	84	+performed by malicious agents on the Tor network and at national firewalls.
	85	+
	86	+ </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Inserting Javascript</strong></span><p>
	87	+If not properly disabled, Javascript event handlers and timers
	88	+can cause the browser to perform network activity after Tor has been disabled,
	89	+thus allowing the adversary to correlate Tor and Non-Tor activity and reveal
	90	+a user's non-Tor IP address. Javascript
	91	+also allows the adversary to execute <a class="ulink" href="http://whattheinternetknowsaboutyou.com/" target="_top">history disclosure attacks</a>:
	92	+to query the history via the different attributes of 'visited' links to search
	93	+for particular Google queries, sites, or even to <a class="ulink" href="http://www.mikeonads.com/2008/07/13/using-your-browser-url-history-estimate-gender/" target="_top">profile
	94	+users based on gender and other classifications</a>. Finally,
	95	+Javascript can be used to query the user's timezone via the
	96	+<code class="function">Date()</code> object, and to reduce the anonymity set by querying
	97	+the <code class="function">navigator</code> object for operating system, CPU, locale,
	98	+and user agent information.
	99	+ </p></li><li class="listitem"><span class="command"><strong>Inserting Plugins</strong></span><p>
	100	+
	101	+Plugins are abysmal at obeying the proxy settings of the browser. Every plugin
	102	+capable of performing network activity that the author has
	103	+investigated is also capable of performing network activity independent of
	104	+browser proxy settings - and often independent of its own proxy settings.
	105	+Sites that have plugin content don't even have to be malicious to obtain a
	106	+user's
	107	+Non-Tor IP (it usually leaks by itself), though <a class="ulink" href="http://decloak.net" target="_top">plenty of active
	108	+exploits</a> are possible as well. In addition, plugins can be used to store unique identifiers that are more
	109	+difficult to clear than standard cookies.
	110	+<a class="ulink" href="http://epic.org/privacy/cookies/flash.html" target="_top">Flash-based
	111	+cookies</a> fall into this category, but there are likely numerous other
	112	+examples.
	113	+
	114	+ </p></li><li class="listitem"><span class="command"><strong>Inserting CSS</strong></span><p>
	115	+
	116	+CSS can also be used to correlate Tor and Non-Tor activity and reveal a user's
	117	+Non-Tor IP address, via the usage of
	118	+<a class="ulink" href="http://www.tjkdesign.com/articles/css%20pop%20ups/" target="_top">CSS
	119	+popups</a> - essentially CSS-based event handlers that fetch content via
	120	+CSS's onmouseover attribute. If these popups are allowed to perform network
	121	+activity in a different Tor state than they were loaded in, they can easily
	122	+correlate Tor and Non-Tor activity and reveal a user's IP address. In
	123	+addition, CSS can also be used without Javascript to perform <a class="ulink" href="http://ha.ckers.org/weird/CSS-history.cgi" target="_top">CSS-only history disclosure
	124	+attacks</a>.
	125	+ </p></li><li class="listitem"><span class="command"><strong>Read and insert cookies</strong></span><p>
	126	+
	127	+An adversary in a position to perform MITM content alteration can inject
	128	+document content elements to both read and inject cookies for arbitrary
	129	+domains. In fact, many "SSL secured" websites are vulnerable to this sort of
	130	+<a class="ulink" href="http://seclists.org/bugtraq/2007/Aug/0070.html" target="_top">active
	131	+sidejacking</a>. In addition, the ad networks of course perform tracking
	132	+with cookies as well.
	133	+
	134	+ </p></li><li class="listitem"><span class="command"><strong>Create arbitrary cached content</strong></span><p>
	135	+
	136	+Likewise, the browser cache can also be used to <a class="ulink" href="http://crypto.stanford.edu/sameorigin/safecachetest.html" target="_top">store unique
	137	+identifiers</a>. Since by default the cache has no same-origin policy,
	138	+these identifiers can be read by any domain, making them an ideal target for
	139	+ad network-class adversaries.
	140	+
	141	+ </p></li><li class="listitem"><a id="fingerprinting"></a><span class="command"><strong>Fingerprint users based on browser
	142	+attributes</strong></span><p>
	143	+
	144	+There is an absurd amount of information available to websites via attributes
	145	+of the browser. This information can be used to reduce anonymity set, or even
	146	+<a class="ulink" href="http://mandark.fr/0x000000/articles/Total_Recall_On_Firefox..html" target="_top">uniquely
	147	+fingerprint individual users</a>. </p><p>
	148	+
	149	+The <a class="ulink" href="https://wiki.mozilla.org/Fingerprinting#Data" target="_top">Panopticlick study
	150	+done</a> by the EFF attempts to measure the actual entropy - the number of
	151	+identifying bits of information encoded in browser properties. Their result
	152	+data is definitely useful, and the metric is probably the appropriate one for
	153	+determining how identifying a particular browser property is. However, some
	154	+quirks of their study means that they do not extract as much information as
	155	+they could from display information: they only use desktop resolution (which
	156	+Torbutton reports as the window resolution) and do not attempt to infer the
	157	+size of toolbars.
	158	+
	159	+
	160	+
	161	+</p></li><li class="listitem"><span class="command"><strong>Remotely or locally exploit browser and/or
	162	+OS</strong></span><p>
	163	+
	164	+Last, but definitely not least, the adversary can exploit either general
	165	+browser vulnerabilities, plugin vulnerabilities, or OS vulnerabilities to
	166	+install malware and surveillance software. An adversary with physical access
	167	+can perform similar actions. Regrettably, this last attack capability is
	168	+outside of our ability to defend against, but it is worth mentioning for
	169	+completeness. <a class="ulink" href="http://tails.boum.org/contribute/design/" target="_top">The Tails
	170	+system</a> however can provide some limited defenses against this
	171	+adversary.
	172	+
	173	+ </p></li></ol></div></div></div></div><div class="sect1" title="2. Design Requirements and Philosophy"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="DesignRequirements"></a>2. Design Requirements and Philosophy</h2></div></div></div><p>
	174	+
	175	+The Tor Browser Design Requirements are meant to describe the properties of a
	176	+Private Browsing Mode that defends against both network and local adversaries.
	177	+
	178	+ </p><p>
	179	+
	180	+There are two main categories of requirements: <a class="link" href="#security" title="2.1. Security Requirements">Security Requirements</a>, and <a class="link" href="#privacy" title="2.2. Privacy Requirements">Privacy Requirements</a>. Security Requirements are the
	181	+minimum properties in order for a web client platform to be able to support
	182	+Tor. Privacy requirements are the set of properties that cause us to prefer
	183	+one platform over another.
	184	+
	185	+ </p><p>
	186	+
	187	+We will maintain an alternate distribution of the web client in order to
	188	+maintain and/or restore privacy properties to our users.
	189	+
	190	+ </p><div class="sect2" title="2.1. Security Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="security"></a>2.1. Security Requirements</h3></div></div></div><p>
	191	+
	192	+The security requirements are primarily concerned with ensuring the safe use
	193	+of Tor. Violations in these properties typically result in serious risk for
	194	+the user in terms of immediate deanonymization and/or observability.
	195	+
	196	+ </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Proxy Obedience</strong></span><p>The browser
	197	+MUST NOT bypass Tor proxy settings for any content.</p></li><li class="listitem"><span class="command"><strong>State Separation</strong></span><p>The browser MUST NOT provide any stored state to the content window
	198	+from other browsers or other browsing modes, including shared state from
	199	+plugins, machine identifiers, and TLS session state.
	200	+</p></li><li class="listitem"><span class="command"><strong>Disk Avoidance</strong></span><p>The
	201	+browser SHOULD NOT write any browsing history information to disk, or store it
	202	+in memory beyond the duration of one Tor session, unless the user has
	203	+explicitly opted to store their browsing history information to
	204	+disk.</p></li><li class="listitem"><span class="command"><strong>Application Data Isolation</strong></span><p>The browser
	205	+MUST NOT write or cause the operating system to
	206	+write <span class="emphasis"><em>any information</em></span> to disk outside of the application
	207	+directory. All exceptions and shortcomings due to operating system behavior
	208	+MUST BE documented.
	209	+
	210	+</p></li><li class="listitem"><span class="command"><strong>Update Safety</strong></span><p>The browser SHOULD NOT perform unsafe updates or upgrades.</p></li></ol></div></div><div class="sect2" title="2.2. Privacy Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="privacy"></a>2.2. Privacy Requirements</h3></div></div></div><p>
	211	+
	212	+The privacy requirements are primarily concerned with reducing linkability:
	213	+the ability for a user's activity on one site to be linked with their
	214	+activity on another site without their knowledge or explicit consent.
	215	+
	216	+ </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Cross-Domain Identifier Unlinkability</strong></span><p>
	217	+
	218	+User activity on one url bar domain MUST NOT be linkable to their activity in
	219	+any other domain by any third party. This property specifically applies to
	220	+linkability from stored browser identifiers, authentication tokens, and shared
	221	+state. This functionality SHOULD NOT interfere with federated login in a
	222	+substantial way.
	223	+
	224	+ </p></li><li class="listitem"><span class="command"><strong>Cross-Domain Fingerprinting Unlinkability</strong></span><p>
	225	+
	226	+User activity on one url bar domain MUST NOT be linkable to their activity in
	227	+any other domain by any third party. This property specifically applies to
	228	+linkability from fingerprinting browser behavior.
	229	+
	230	+ </p></li><li class="listitem"><span class="command"><strong>Long-Term Unlinkability</strong></span><p>
	231	+
	232	+The browser SHOULD provide an obvious, easy way to remove all of their authentication
	233	+tokens and browser state and obtain a fresh identity. Additionally, this
	234	+should happen by default automatically upon browser restart.
	235	+
	236	+ </p></li></ol></div></div><div class="sect2" title="2.3. Philosophy"><div class="titlepage"><div><div><h3 class="title"><a id="philosophy"></a>2.3. Philosophy</h3></div></div></div><p>
	237	+
	238	+In addition to the above design requirements, the technology decisions about
	239	+Tor Browser are also guided by some philosophical positions about technology.
	240	+
	241	+ </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Preserve existing user model</strong></span><p>
	242	+
	243	+The existing way that the user expects to use a browser must be preserved. If
	244	+the user has to maintain a different mental model of how the sites they are
	245	+using behave depending on tab, browser state, or anything else that would not
	246	+normally be what they experience in their default browser, the user will
	247	+inevitably be confused. They will make mistakes and reduce their privacy as a
	248	+result. Worse, they may just stop using the browser, assuming it is broken.
	249	+
	250	+ </p><p>
	251	+
	252	+User model breakage was one of the <a class="ulink" href="https://blog.torproject.org/blog/toggle-or-not-toggle-end-torbutton" target="_top">failures
	253	+of Torbutton</a>: Even if users managed to install everything properly,
	254	+the toggle model was too hard for the average user to understand, especially
	255	+in the face of accumulating tabs from multiple states crossed with the current
	256	+tor-state of the browser.
	257	+
	258	+ </p></li><li class="listitem"><span class="command"><strong>Favor the implementation mechanism least likely to
	259	+break sites</strong></span><p>
	260	+
	261	+In general, we try to find solutions to privacy issues that will not induce
	262	+site breakage, though this is not always possible.
	263	+
	264	+ </p></li><li class="listitem"><span class="command"><strong>Plugins must be restricted</strong></span><p>
	265	+
	266	+Even if plugins always properly used the browser proxy settings (which none of
	267	+them do) and could not be induced to bypass them (which all of them can), the
	268	+activities of closed-source plugins are very difficult to audit and control.
	269	+They can obtain and transmit all manner of system information to websites,
	270	+often have their own identifier storage for tracking users, and also
	271	+contribute to fingerprinting.
	272	+
	273	+ </p><p>
	274	+
	275	+Therefore, if plugins are to be enabled in private browsing modes, they must
	276	+be restricted from running automatically on every page (via click-to-play
	277	+placeholders), and/or be sandboxed to restrict the types of system calls they
	278	+can execute. If the user decides to craft an exemption to allow a plugin to be
	279	+used, it MUST ONLY apply to the top level urlbar domain, and not to all sites,
	280	+to reduce linkability.
	281	+
	282	+ </p></li><li class="listitem"><span class="command"><strong>Minimize Global Privacy Options</strong></span><p>
	283	+
	284	+<a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3100" target="_top">Another
	285	+failure of Torbutton</a> was (and still is) the options panel. Each option
	286	+that detectably alters browser behavior can be used as a fingerprinting tool.
	287	+Similarly, all extensions <a class="ulink" href="http://blog.chromium.org/2010/06/extensions-in-incognito.html" target="_top">should be
	288	+disabled in the mode</a> except as an opt-in basis. We should not load
	289	+system-wide addons or plugins.
	290	+
	291	+ </p><p>
	292	+Instead of global browser privacy options, privacy decisions should be made
	293	+<a class="ulink" href="https://wiki.mozilla.org/Privacy/Features/Site-based_data_management_UI" target="_top">per
	294	+top-level url-bar domain</a> to eliminate the possibility of linkability
	295	+between domains. For example, when a plugin object (or a Javascript access of
	296	+window.plugins) is present in a page, the user should be given the choice of
	297	+allowing that plugin object for that top-level url-bar domain only. The same
	298	+goes for exemptions to third party cookie policy, geo-location, and any other
	299	+privacy permissions.
	300	+ </p><p>
	301	+If the user has indicated they do not care about local history storage, these
	302	+permissions can be written to disk. Otherwise, they should remain memory-only.
	303	+ </p></li><li class="listitem"><span class="command"><strong>No filters</strong></span><p>
	304	+
	305	+Filter-based addons such as <a class="ulink" href="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/" target="_top">AdBlock
	306	+Plus</a>, <a class="ulink" href="" target="_top">Request Policy</a>, <a class="ulink" href="http://priv3.icsi.berkeley.edu/" target="_top">Priv3</a>, and <a class="ulink" href="http://sharemenot.cs.washington.edu/" target="_top">Sharemenot</a> are to be
	307	+avoided. We believe that these addons do not add any real privacy to a proper
	308	+<a class="link" href="#Implementation" title="3. Implementation">implementation</a> of the above <a class="link" href="#privacy" title="2.2. Privacy Requirements">privacy requirements</a>, as all third parties are
	309	+prevented from tracking users between sites by the implementation.
	310	+Filter-based addons can also introduce strange breakage and cause usability
	311	+nightmares, and will also fail to do their job if an adversary simply
	312	+registers a new domain or creates a new url path. Worse still, the unique
	313	+filter sets that each user is liable to create/install likely provide a wealth
	314	+of fingerprinting targets.
	315	+
	316	+ </p><p>
	317	+
	318	+As a general matter, we are also generally opposed to shipping an always-on Ad
	319	+blocker with Tor Browser. We feel that this would damage our credibility in
	320	+terms of demonstrating that we are providing privacy through a sound design
	321	+alone, as well as damage the acceptance of Tor users by sites who support
	322	+themselves through advertising revenue.
	323	+
	324	+ </p><p>
	325	+Users are free to install these addons if they wish, but doing
	326	+so is not recommended, as it will alter the browser request fingerprint.
	327	+ </p></li><li class="listitem"><span class="command"><strong>Stay Current</strong></span><p>
	328	+We believe that if we do not stay current with the support of new web
	329	+technologies, we cannot hope to substantially influence or be involved in
	330	+their proper deployment or privacy realization. However, we will likely disable
	331	+certain new features (where possible) pending analysis and audit.
	332	+ </p></li></ol></div></div></div><div class="sect1" title="3. Implementation"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Implementation"></a>3. Implementation</h2></div></div></div><p>
	333	+ </p><div class="sect2" title="3.1. Proxy Obedience"><div class="titlepage"><div><div><h3 class="title"><a id="proxy-obedience"></a>3.1. Proxy Obedience</h3></div></div></div><p>
	334	+
	335	+Proxy obedience is assured through the following:
	336	+ </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Firefox Proxy settings
	337	+ <p>
	338	+ The Torbutton xpi sets the Firefox proxy settings to use Tor directly as a
	339	+SOCKS proxy. It sets <span class="command"><strong>network.proxy.socks_remote_dns</strong></span>,
	340	+<span class="command"><strong>network.proxy.socks_version</strong></span>, and
	341	+<span class="command"><strong>network.proxy.socks_port</strong></span>.
	342	+ </p></li><li class="listitem">Disabling plugins
	343	+ <p>
	344	+ Plugins have the ability to make arbitrary OS system calls. This includes
	345	+the ability to make UDP sockets and send arbitrary data independent of the
	346	+browser proxy settings.
	347	+ </p><p>
	348	+Torbutton disables plugins by using the
	349	+<span class="command"><strong>@mozilla.org/plugin/host;1</strong></span> service to mark the plugin tags
	350	+as disabled. Additionally, we set
	351	+<span class="command"><strong>plugin.disable_full_page_plugin_for_types</strong></span> to the list of
	352	+supported mime types for all currently installed plugins.
	353	+ </p><p>
	354	+In addition, to prevent any unproxied activity by plugins at load time, we
	355	+also patch the Firefox source code to <a class="ulink" href="" target="_top">prevent the load of any plugins except
	356	+for Flash and Gnash</a>.
	357	+
	358	+ </p></li><li class="listitem">External App Blocking
	359	+ <p>
	360	+External apps, if launched automatically, can be induced to load files that
	361	+perform network activity. In order to prevent this, Torbutton installs a
	362	+component to
	363	+<a class="ulink" href="" target="_top">
	364	+provide the user with a popup</a> whenever the browser attempts to
	365	+launch a helper app.
	366	+ </p></li></ol></div></div><div class="sect2" title="3.2. State Separation"><div class="titlepage"><div><div><h3 class="title"><a id="state-separation"></a>3.2. State Separation</h3></div></div></div><p>
	367	+Tor Browser State is separated from existing browser state through use of a
	368	+custom Firefox profile. Furthermore, plugins are disabled, which prevents
	369	+Flash cookies from leaking from a pre-existing Flash directory.
	370	+ </p></div><div class="sect2" title="3.3. Disk Avoidance"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>3.3. Disk Avoidance</h3></div></div></div><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2888086"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
	371	+Tor Browser should optionally prevent all disk records of browser activity.
	372	+The user should be able to optionally enable URL history and other history
	373	+features if they so desire. Once we <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3100" target="_top">simplify the
	374	+preferences interface</a>, we will likely just enable Private Browsing
	375	+mode by default to handle this goal.
	376	+ </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2914304"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
	377	+For now, Tor Browser blocks write access to the disk through Torbutton
	378	+using several Firefox preferences.
	379	+
	380	+
	381	+
	382	+The set of prefs is:
	383	+<span class="command"><strong>dom.storage.enabled</strong></span>,
	384	+<span class="command"><strong>browser.cache.memory.enable</strong></span>,
	385	+<span class="command"><strong>network.http.use-cache</strong></span>,
	386	+<span class="command"><strong>browser.cache.disk.enable</strong></span>,
	387	+<span class="command"><strong>browser.cache.offline.enable</strong></span>,
	388	+<span class="command"><strong>general.open_location.last_url</strong></span>,
	389	+<span class="command"><strong>places.history.enabled</strong></span>,
	390	+<span class="command"><strong>browser.formfill.enable</strong></span>,
	391	+<span class="command"><strong>signon.rememberSignons</strong></span>,
	392	+<span class="command"><strong>browser.download.manager.retention</strong></span>,
	393	+and <span class="command"><strong>network.cookie.lifetimePolicy</strong></span>.
	394	+ </blockquote></div></div><p>
	395	+In addition, three Firefox patches are needed to prevent disk writes, even if
	396	+Private Browsing Mode is enabled. We need to
	397	+
	398	+<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/current-patches/0002-Make-Permissions-Manager-memory-only.patch" target="_top">prevent
	399	+the permissions manager from recording HTTPS STS state</a>,
	400	+<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/current-patches/0003-Make-Intermediate-Cert-Store-memory-only.patch" target="_top">prevent
	401	+intermediate SSL certificates from being recorded</a>, and
	402	+<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/current-patches/0008-Make-content-pref-service-memory-only-clearable.patch" target="_top">prevent
	403	+the content preferences service from recording site zoom</a>.
	404	+
	405	+For more details on these patches, <a class="link" href="#firefox-patches" title="3.9. Description of Firefox Patches">see the
	406	+Firefox Patches section</a>.
	407	+
	408	+ </p></div><div class="sect2" title="3.4. Application Data Isolation"><div class="titlepage"><div><div><h3 class="title"><a id="app-data-isolation"></a>3.4. Application Data Isolation</h3></div></div></div><p>
	409	+
	410	+Tor Browser Bundle MUST NOT cause any information to be written outside of the
	411	+bundle directory. This is to ensure that the user is able to completely and
	412	+safely remove the bundle without leaving other traces of Tor usage on their
	413	+computer.
	414	+
	415	+ </p><p>XXX: sjmurdoch, Erinn: explain what magic we do to satisfy this,
	416	+and/or what additional work or auditing needs to be done.
	417	+ </p></div><div class="sect2" title="3.5. Cross-Domain Identifier Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="identifier-linkability"></a>3.5. Cross-Domain Identifier Unlinkability</h3></div></div></div><p>
	418	+
	419	+The Tor Browser MUST prevent a user's activity on one site from being linked
	420	+to their activity on another site. When this goal cannot yet be met with an
	421	+existing web technology, that technology or functionality is disabled. Our
	422	+<a class="link" href="#privacy" title="2.2. Privacy Requirements">design goal</a> is to ultimately eliminate the need to disable arbitrary
	423	+technologies, and instead simply alter them in ways that allows them to
	424	+function in a backwards-compatible way while avoiding linkability. Users
	425	+should be able to use federated login of various kinds to explicitly inform
	426	+sites who they are, but that information should not transparently allow a
	427	+third party to record their activity from site to site without their prior
	428	+consent.
	429	+
	430	+ </p><p>
	431	+
	432	+The benefit of this approach comes not only in the form of reduced
	433	+linkability, but also in terms of simplified privacy UI. If all stored browser
	434	+state and permissions become associated with the top-level url-bar domain, the
	435	+six or seven different pieces of privacy UI governing these identifiers and
	436	+permissions can become just one piece of UI. For instance, a window that lists
	437	+the top-level url bar domains for which browser state exists with the ability
	438	+to clear and/or block them, possibly with a context-menu option to drill down
	439	+into specific types of state. An exmaple of this simplifcation can be seen in
	440	+Figure 1.
	441	+
	442	+ </p><div class="figure"><a id="id2909608"></a><p class="title"><b>Figure 1. Improving the Privacy UI</b></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="CookieManagers.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p>
	443	+
	444	+On the left is the standard Firefox cookie manager. On the right is a mock-up
	445	+of how isolating identifiers to the URL bar domain might simplify the privacy
	446	+UI for all data - not just cookies. Both windows represent the set of
	447	+Cookies accomulated after visiting just five sites, but the window on the
	448	+right has the option of also representing history, DOM Storage, HTTP Auth,
	449	+search form history, login values, and so on within a context menu for each
	450	+site.
	451	+
	452	+</div></div></div><br class="figure-break" /><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Cookies
	453	+ <p><span class="command"><strong>Design Goal:</strong></span>
	454	+
	455	+All cookies should be double-keyed to the top-level domain. There exists a
	456	+<a class="ulink" href="" target="_top">Mozilla
	457	+bug</a> that contains a prototype patch, but it lacks UI, and does not
	458	+apply to modern Firefoxes.
	459	+
	460	+ </p><p><span class="command"><strong>Implementation Status:</strong></span>
	461	+
	462	+As a stopgap to satisfy our design requirement of unlinkability, we currently
	463	+entirely disable 3rd party cookies by setting
	464	+<span class="command"><strong>network.cookie.cookieBehavior</strong></span> to 1. We would prefer that
	465	+third party content continue to function , but we believe the requirement for
	466	+unlinkability trumps that desire.
	467	+
	468	+ </p></li><li class="listitem">Cache
	469	+ <p>
	470	+Cache is isolated to the top-level url bar domain by using a technique
	471	+pioneered by Colin Jackson et al, via their work on <a class="ulink" href="http://www.safecache.com/" target="_top">SafeCache</a>. The technique re-uses the
	472	+<a class="ulink" href="https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsICachingChannel" target="_top">nsICachingChannel.cacheKey</a>
	473	+attribute that Firefox uses internally to prevent improper caching of HTTP POST data.
	474	+ </p><p>
	475	+However, to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3666" target="_top">increase the
	476	+security of the isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754" target="_top">solve strange and
	477	+unknown conflicts with OCSP</a>, we had to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/current-patches/0005-Add-a-string-based-cacheKey.patch" target="_top">patch
	478	+Firefox to provide a cacheDomain cache attribute</a>. We use the full
	479	+url bar domain as input to this field.
	480	+ </p><p>
	481	+
	482	+
	483	+Furthermore, we chose a different isolation scheme than the Stanford
	484	+implementation. First, we decoupled the cache isolation from the third party
	485	+cookie attribute. Second, we use several mechanisms to attempt to determine
	486	+the actual location attribute of the top-level window (the url bar domain)
	487	+used to load the page, as opposed to relying solely on the referer property.
	488	+ </p><p>
	489	+Therefore, <a class="ulink" href="http://crypto.stanford.edu/sameorigin/safecachetest.html" target="_top">the original
	490	+Stanford test
	491	+cases</a> are expected to fail. Functionality can still be verified by
	492	+navigating to <a class="ulink" href="about:cache" target="_top">about:cache</a> and viewing the key
	493	+used for each cache entry. Each third party element should have an additional
	494	+"domain=string" property prepended, which will list the top-level urlbar
	495	+domain that was used to source the third party element.
	496	+ </p></li><li class="listitem">HTTP Auth
	497	+ <p>
	498	+
	499	+HTTP authentication tokens are removed for third party elements using the
	500	+<a class="ulink" href="https://developer.mozilla.org/en/Setting_HTTP_request_headers#Observers" target="_top">http-on-modify-request
	501	+observer</a> to remove the Authorization headers to prevent <a class="ulink" href="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies.html" target="_top">silent
	502	+linkability between domains</a>. We also needed to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/current-patches/0004-Add-HTTP-auth-headers-before-the-modify-request-obse.patch" target="_top">patch
	503	+Firefox to cause the headers to get added early enough</a> to allow the
	504	+observer to modify it.
	505	+
	506	+ </p></li><li class="listitem">DOM Storage
	507	+ <p><span class="command"><strong>Design Goal:</strong></span>
	508	+
	509	+DOM storage for third party domains MUST BE isolated to the url bar domain,
	510	+to prevent linkability between sites.
	511	+
	512	+ </p><p><span class="command"><strong>Implementation Status:</strong></span>
	513	+
	514	+Because it is isolated to third party domain as opposed to top level url bar
	515	+domain, we entirely disable DOM storage as a stopgap to ensure unlinkability.
	516	+
	517	+ </p></li><li class="listitem">TLS session resumption and HTTP Keep-Alive
	518	+ <p>
	519	+TLS session resumption and HTTP Keep-Alive must not allow third party origins
	520	+to track users via either TLS session IDs, or the fact that different requests
	521	+arrive on the same TCP connection.
	522	+ </p><p><span class="command"><strong>Design Goal:</strong></span>
	523	+
	524	+TLS session resumption IDs must be limited to the top-level url bar domain.
	525	+HTTP Keep-Alive connections from a third party in one top-level domain must
	526	+not be reused for that same third party in another top-level domain.
	527	+
	528	+ </p><p><span class="command"><strong>Implementation Status:</strong></span>
	529	+
	530	+We <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/4099" target="_top">plan to
	531	+disable</a> TLS session resumption, and limit HTTP Keep-alive duration.
	532	+
	533	+ </p></li><li class="listitem">window.name
	534	+ <p>
	535	+
	536	+<a class="ulink" href="https://developer.mozilla.org/En/DOM/Window.name" target="_top">window.name</a> is
	537	+a magical DOM property that for some reason is allowed to retain a persistent value
	538	+for the lifespan of a browser tab. It is possible to utilize this property for
	539	+<a class="ulink" href="http://www.thomasfrank.se/sessionvars.html" target="_top">identifier
	540	+storage</a>.
	541	+
	542	+ </p><p>
	543	+
	544	+In order to eliminate linkability but still allow for sites that utilize this
	545	+property to function, we reset the window.name property of tabs in Torbutton every
	546	+time we encounter a blank referer. This behavior allows window.name to persist
	547	+for the duration of a link-driven navigation session, but as soon as the user
	548	+enters a new URL or navigates between https/http schemes, the property is cleared.
	549	+
	550	+ </p></li><li class="listitem">Exit node usage
	551	+ <p><span class="command"><strong>Design Goal:</strong></span>
	552	+
	553	+Every distinct navigation session (as defined by a non-blank referer header)
	554	+MUST exit through a fresh Tor circuit in Tor Browser to prevent exit node
	555	+observers from linking concurrent browsing activity.
	556	+
	557	+ </p><p><span class="command"><strong>Implementation Status:</strong></span>
	558	+
	559	+The Tor feature that supports this ability only exists in the 0.2.3.x-alpha
	560	+series. <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3455" target="_top">Ticket
	561	+#3455</a> is the Torbutton ticket to make use of the new Tor
	562	+functionality.
	563	+
	564	+ </p></li></ol></div></div><div class="sect2" title="3.6. Cross-Domain Fingerprinting Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="fingerprinting-linkability"></a>3.6. Cross-Domain Fingerprinting Unlinkability</h3></div></div></div><p>
	565	+
	566	+In order to properly address the fingerprinting adversary on a technical
	567	+level, we need a metric to measure linkability of the various browser
	568	+properties that extend beyond any stored origin-related state. <a class="ulink" href="https://panopticlick.eff.org/about.php" target="_top">The Panopticlick Project</a>
	569	+by the EFF provides us with exactly this metric. The researchers conducted a
	570	+survey of volunteers who were asked to visit an experiment page that harvested
	571	+many of the above components. They then computed the Shannon Entropy of the
	572	+resulting distribution of each of several key attributes to determine how many
	573	+bits of identifying information each attribute provided.
	574	+
	575	+ </p><p>
	576	+
	577	+The study is not exhaustive, though. In particular, the test does not take in
	578	+all aspects of resolution information. It did not calculate the size of
	579	+widgets, window decoration, or toolbar size, which we believe may add high
	580	+amounts of entropy. It also did not measure clock offset and other time-based
	581	+fingerprints. Furthermore, as new browser features are added, this experiment
	582	+should be repeated to include them.
	583	+
	584	+ </p><p>
	585	+
	586	+On the other hand, to avoid an infinite sinkhole, we reduce the efforts for
	587	+fingerprinting resistance by only concerning ourselves with reducing the
	588	+fingerprintable differences <span class="emphasis"><em>among</em></span> Tor Browser users. We
	589	+do not believe it is productive to concern ourselves with cross-browser
	590	+fingerprinting issues, at least not at this stage.
	591	+
	592	+ </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Plugins
	593	+ <p>
	594	+
	595	+Plugins add to fingerprinting risk via two main vectors: their mere presence in
	596	+window.navigator.plugins, as well as their internal functionality.
	597	+
	598	+ </p><p><span class="command"><strong>Design Goal:</strong></span>
	599	+
	600	+All plugins that have not been specifically audited or sandboxed must be
	601	+disabled. To reduce linkability potential, even sandboxed plugins should not
	602	+be allowed to load objects until the user has clicked through a click-to-play
	603	+barrier. Additionally, version information should be reduced or obfuscated
	604	+until the plugin object is loaded.
	605	+
	606	+ </p><p><span class="command"><strong>Implementation Status:</strong></span>
	607	+
	608	+Currently, we entirely disable all plugins in Tor Browser. However, as a
	609	+compromise due to the popularity of Flash, we intend to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3974" target="_top">work
	610	+towards</a> a
	611	+click-to-play barrier using NoScript that is available only after the user has
	612	+specifically enabled plugins. Flash will be the only plugin available, and we
	613	+will ship a settings.sol file to disable Flash cookies, and to restrict P2P
	614	+features that likely bypass proxy settings.
	615	+
	616	+ </p></li><li class="listitem">Fonts
	617	+ <p>
	618	+
	619	+According to the Panopticlick study, fonts provide the most linkability when
	620	+they are provided as an enumerable list in filesystem order, via either the
	621	+Flash or Java plugins. However, it is still possible to use CSS and/or
	622	+Javascript to query for the existence of specific fonts. With a large enough
	623	+pre-built list to query, a large amount of fingerprintable information may
	624	+still be available.
	625	+
	626	+ </p><p><span class="command"><strong>Design Goal:</strong></span>
	627	+
	628	+To address the Javascript issue, we intend to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/2872" target="_top">limit the number of
	629	+fonts</a> an origin can load, gracefully degrading to built-in and/or
	630	+remote fonts once the limit is reached.
	631	+
	632	+ </p><p><span class="command"><strong>Implementation Status:</strong></span>
	633	+
	634	+Aside from disabling plugins to prevent enumeration, we have not yet
	635	+implemented any defense against CSS or Javascript fonts.
	636	+
	637	+ </p></li><li class="listitem">User Agent and HTTP Headers
	638	+ <p><span class="command"><strong>Design Goal:</strong></span>
	639	+
	640	+All Tor Browser users should provide websites with an identical user agent and
	641	+HTTP header set for a given request type. We omit the Firefox minor revision,
	642	+and report a popular Windows platform. If the software is kept up to date,
	643	+these headers should remain identical across the population even when updated.
	644	+
	645	+ </p><p><span class="command"><strong>Implementation Status:</strong></span>
	646	+
	647	+Firefox provides several options for controlling the browser user agent string
	648	+which we leverage. We also set similar prefs for controlling the
	649	+Accept-Language and Accept-Charset headers, which we spoof to English by default. Additionally, we
	650	+<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/current-patches/0001-Block-Components.interfaces-lookupMethod-from-conten.patch" target="_top">remove
	651	+content script access</a> to Components.interfaces, which <a class="ulink" href="http://pseudo-flaw.net/tor/torbutton/fingerprint-firefox.html" target="_top">can be
	652	+used</a> to fingerprint OS, platform, and Firefox minor version. </p></li><li class="listitem">Desktop resolution and CSS Media Queries
	653	+ <p>
	654	+
	655	+Both CSS and Javascript have a lot of irrelevant information about the screen
	656	+resolution, usable desktop size, OS widget size, toolbar size, title bar size, and
	657	+other desktop features that are not at all relevant to rendering and serve
	658	+only to provide information for fingerprinting.
	659	+
	660	+ </p><p><span class="command"><strong>Design Goal:</strong></span>
	661	+
	662	+Our design goal here is to reduce the resolution information down to the bare
	663	+minimum required for properly rendering inside a content window. We intend to
	664	+report all rendering information correctly with respect to the size and
	665	+properties of the content window, but report an effective size of 0 for all
	666	+border material, and also report that the desktop is only as big as the
	667	+inner content window. Additionally, new browser windows are sized such that
	668	+their content windows are one of ~5 fixed sizes based on the user's
	669	+desktop resolution.
	670	+
	671	+ </p><p><span class="command"><strong>Implementation Status:</strong></span>
	672	+
	673	+We have implemented the above strategy for Javascript using Torbutton's <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/jshooks4.js" target="_top">JavaScript
	674	+hooks</a> as well as a window observer to <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/torbutton.js#l4002" target="_top">resize
	675	+new windows based on desktop resolution</a>. However, CSS Media Queries
	676	+still <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/2875" target="_top">need
	677	+to be dealt with</a>.
	678	+
	679	+ </p></li><li class="listitem">Timezone and clock offset
	680	+ <p><span class="command"><strong>Design Goal:</strong></span>
	681	+
	682	+All Tor Browser users should report the same timezone to websites. Currently,
	683	+we choose UTC for this purpose, although an equally valid argument could be
	684	+made for EDT/EST due to the large English-speaking population density.
	685	+Additionally, the Tor software should detect if the users clock is
	686	+significantly divergent from the clocks of the relays that it connects to, and
	687	+use this to reset the clock values used in Tor Browser to something reasonably
	688	+accurate.
	689	+
	690	+ </p><p><span class="command"><strong>Implementation Status:</strong></span>
	691	+
	692	+We set the timezone using the TZ environment variable, which is supported on
	693	+all platforms. Additionally, we plan to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3652" target="_top">obtain a clock
	694	+offset from Tor</a>, but this won't be available until Tor 0.2.3.x is in
	695	+use.
	696	+
	697	+ </p></li><li class="listitem">Javascript performance fingerprinting
	698	+ <p>
	699	+
	700	+<a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">Javascript performance
	701	+fingerprinting</a> is the act of profiling the performance
	702	+of various Javascript functions for the purpose of fingerprinting the
	703	+Javascript engine and the CPU.
	704	+
	705	+ </p><p><span class="command"><strong>Design Goal:</strong></span>
	706	+
	707	+We have <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3059" target="_top">several potential
	708	+mitigation approaches</a> to reduce the accuracy of performance
	709	+fingerprinting without risking too much damage to functionality. Our current
	710	+favorite is to reduce the resolution of the Event.timeStamp and the Javascript
	711	+Date() object, while also introducing jitter. Our goal is to increase the
	712	+amount of time it takes to mount a successful attack. <a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">Mowery et al</a> found that
	713	+even with the default precision in most browsers, they required up to 120
	714	+seconds of amortization and repeated trials to get stable results from their
	715	+feature set. We intend to work with the research community to establish the
	716	+optimum tradeoff between quantization+jitter and amortization time.
	717	+
	718	+
	719	+ </p><p><span class="command"><strong>Implementation Status:</strong></span>
	720	+
	721	+We have no implementation as of yet.
	722	+
	723	+ </p></li><li class="listitem">Keystroke fingerprinting
	724	+ <p>
	725	+
	726	+Keystroke fingerprinting is the act of measuring key strike time and key
	727	+flight time. It is seeing increasing use as a biometric.
	728	+
	729	+ </p><p><span class="command"><strong>Design Goal:</strong></span>
	730	+
	731	+We intend to rely on the same mechanisms for defeating Javascript performance
	732	+fingerprinting: timestamp quantization and jitter.
	733	+
	734	+ </p><p><span class="command"><strong>Implementation Status:</strong></span>
	735	+We have no implementation as of yet.
	736	+ </p></li><li class="listitem">WebGL
	737	+ <p>
	738	+
	739	+WebGL is fingerprintable both through information that is exposed about the
	740	+underlying driver and optimizations, as well as through performance
	741	+fingerprinting.
	742	+
	743	+ </p><p><span class="command"><strong>Design Goal:</strong></span>
	744	+
	745	+Because of the large amount of potential fingerprinting vectors, we intend to
	746	+deploy a similar strategy against WebGL as for plugins. First, WebGL canvases
	747	+will have click-to-play placeholders, and will not run until authorized by the
	748	+user. Second, we intend to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3323" target="_top">obfuscate driver
	749	+information</a> by hooking
	750	+<span class="command"><strong>getParameter()</strong></span>,
	751	+<span class="command"><strong>getSupportedExtensions()</strong></span>,
	752	+<span class="command"><strong>getExtension()</strong></span>, and
	753	+<span class="command"><strong>getContextAttributes()</strong></span> to provide standard minimal,
	754	+driver-neutral information.
	755	+
	756	+ </p><p><span class="command"><strong>Implementation Status:</strong></span>
	757	+
	758	+Currently we simply disable WebGL.
	759	+
	760	+ </p></li></ol></div></div><div class="sect2" title="3.7. Long-Term Unlinkability via "New Identity" button"><div class="titlepage"><div><div><h3 class="title"><a id="new-identity"></a>3.7. Long-Term Unlinkability via "New Identity" button</h3></div></div></div><p>
	761	+In order to avoid long-term linkability, we provide a "New Identity" context
	762	+menu option in Torbutton.
	763	+ </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2894546"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
	764	+
	765	+All linkable identifiers and browser state should be cleared by this feature.
	766	+
	767	+ </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2904450"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
	768	+ First, Torbutton disables
	769	+all open tabs and windows via nsIContentPolicy blocking, and then closes each
	770	+tab and window. The extra step for blocking tabs is done as a precaution to
	771	+ensure that any asynchronous Javascript is in fact properly disabled. After
	772	+closing all of the windows, we then clear the following state: OCSP (by
	773	+toggling security.OCSP.enabled), cache, site-specific zoom and content
	774	+preferences, Cookies, DOM storage, safe browsing key, the Google wifi
	775	+geolocation token (if exists), HTTP auth, SSL Session IDs, and the last opened URL
	776	+field (via the pref general.open_location.last_url). After clearing the
	777	+browser state, we then send the NEWNYM signal to the Tor control port to cause
	778	+a new circuit to be created.
	779	+ </blockquote></div></div></div><div class="sect2" title="3.8. Click-to-play for plugins and invasive content"><div class="titlepage"><div><div><h3 class="title"><a id="click-to-play"></a>3.8. Click-to-play for plugins and invasive content</h3></div></div></div><p>
	780	+Some content types are too invasive and/or too opaque for us to properly
	781	+eliminate their linkability properties. For these content types, we use
	782	+NoScript to provide click-to-play placeholders that do not activate the
	783	+content until the user clicks on it. This will eliminate the ability for an
	784	+adversary to use such content types to link users in a dragnet fashion across
	785	+arbitrary sites.
	786	+ </p><p>
	787	+Currently, the content types isolated in this way include Flash, WebGL, and
	788	+audio and video objects.
	789	+ </p></div><div class="sect2" title="3.9. Description of Firefox Patches"><div class="titlepage"><div><div><h3 class="title"><a id="firefox-patches"></a>3.9. Description of Firefox Patches</h3></div></div></div><p>
	790	+The set of patches we have against Firefox can be found in the <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/tree/refs/heads/maint-2.2:/src/current-patches" target="_top">current-patches
	791	+directory of the torbrowser git repository</a>. They are:
	792	+ </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Block Components.interfaces and Components.lookupMethod
	793	+ <p>
	794	+
	795	+In order to reduce fingerprinting, we block access to these two interfaces
	796	+from content script. Components.lookupMethod can undo our <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/jshooks4.js" target="_top">Javascript
	797	+hooks</a>,
	798	+and Components.interfaces can be used for fingerprinting the platform, OS, and
	799	+Firebox version, but not much else.
	800	+
	801	+ </p></li><li class="listitem">Make Permissions Manager memory only
	802	+ <p>
	803	+
	804	+This patch exposes a pref 'permissions.memory_only' that properly isolates the
	805	+permissions manager to memory, which is responsible for all user specified
	806	+site permissions, as well as stored HTTPS STS policy from visited sites.
	807	+
	808	+The pref does successfully clear the permissions manager memory if toggled. It
	809	+does not need to be set in prefs.js, and can be handled by Torbutton.
	810	+
	811	+ </p><p><span class="command"><strong>Design Goal:</strong></span>
	812	+
	813	+As an additional design goal, we would like to later alter this patch to allow this
	814	+information to be cleared from memory. The implementation does not currently
	815	+allow this.
	816	+
	817	+ </p></li><li class="listitem">Make Intermediate Cert Store memory-only
	818	+ <p>
	819	+
	820	+The intermediate certificate store holds information about SSL certificates
	821	+that may only be used by a limited number of domains. In some cases
	822	+effectively recording on disk the fact that a website owned by a certain
	823	+organization was viewed.
	824	+
	825	+ </p><p><span class="command"><strong>Design Goal:</strong></span>
	826	+
	827	+As an additional design goal, we would like to later alter this patch to allow this
	828	+information to be cleared from memory. The implementation does not currently
	829	+allow this.
	830	+
	831	+ </p></li><li class="listitem">Add HTTP auth headers before on-modify-request fires
	832	+ <p>
	833	+
	834	+This patch provides a trivial modification to allow us to properly remove HTTP
	835	+auth for third parties. This patch allows us to defend against an adversary
	836	+attempting to use <a class="ulink" href="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies.html" target="_top">HTTP
	837	+auth to silently track users between domains</a>.
	838	+
	839	+ </p></li><li class="listitem">Add a string-based cacheKey property for domain isolation
	840	+ <p>
	841	+
	842	+To <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3666" target="_top">increase the
	843	+security of cache isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754" target="_top">solve strange and
	844	+unknown conflicts with OCSP</a>, we had to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/current-patches/0005-Add-a-string-based-cacheKey.patch" target="_top">patch
	845	+Firefox to provide a cacheDomain cache attribute</a>. We use the full
	846	+url bar domain as input to this field.
	847	+
	848	+ </p></li><li class="listitem">Randomize HTTP pipeline order and depth
	849	+ <p>
	850	+As an
	851	+<a class="ulink" href="https://blog.torproject.org/blog/experimental-defense-website-traffic-fingerprinting" target="_top">experimental
	852	+defense against Website Traffic Fingerprinting</a>, we patch the standard
	853	+HTTP pipelining code to randomize the number of requests in a
	854	+pipeline, as well as their order.
	855	+ </p></li><li class="listitem">Block all plugins except flash
	856	+ <p>
	857	+We cannot use the <a class="ulink" href="http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/components/@mozilla.org/extensions/blocklist%3B1" target="_top">
	858	+@mozilla.org/extensions/blocklist;1</a> service, because we
	859	+actually want to stop plugins from ever entering the browser's process space
	860	+and/or executing code (for example, AV plugins that collect statistics/analyze
	861	+URLs, magical toolbars that phone home or "help" the user, skype buttons that
	862	+ruin our day, and censorship filters). Hence we rolled our own.
	863	+ </p></li><li class="listitem">Make content-prefs service memory only
	864	+ <p>
	865	+This patch prevents random URLs from being inserted into content-prefs.sqllite in
	866	+the profile directory as content prefs change (includes site-zoom and perhaps
	867	+other site prefs?).
	868	+ </p></li></ol></div></div></div><div class="sect1" title="4. Packaging"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Packaging"></a>4. Packaging</h2></div></div></div><p> </p><div class="sect2" title="4.1. Build Process Security"><div class="titlepage"><div><div><h3 class="title"><a id="build-security"></a>4.1. Build Process Security</h3></div></div></div><p> </p></div><div class="sect2" title="4.2. External Addons"><div class="titlepage"><div><div><h3 class="title"><a id="addons"></a>4.2. External Addons</h3></div></div></div><p> </p><div class="sect3" title="Included Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2869647"></a>Included Addons</h4></div></div></div></div><div class="sect3" title="Excluded Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2906387"></a>Excluded Addons</h4></div></div></div></div><div class="sect3" title="Dangerous Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2907827"></a>Dangerous Addons</h4></div></div></div></div></div><div class="sect2" title="4.3. Pref Changes"><div class="titlepage"><div><div><h3 class="title"><a id="prefs"></a>4.3. Pref Changes</h3></div></div></div><p> </p></div><div class="sect2" title="4.4. Update Security"><div class="titlepage"><div><div><h3 class="title"><a id="update-mechanism"></a>4.4. Update Security</h3></div></div></div><p> </p></div></div><div class="sect1" title="5. Testing"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Testing"></a>5. Testing</h2></div></div></div><p>
	869	+
	870	+The purpose of this section is to cover all the known ways that Tor browser
	871	+security can be subverted from a penetration testing perspective. The hope
	872	+is that it will be useful both for creating a "Tor Safety Check"
	873	+page, and for developing novel tests and actively attacking Torbutton with the
	874	+goal of finding vulnerabilities in either it or the Mozilla components,
	875	+interfaces and settings upon which it relies.
	876	+
	877	+ </p><div class="sect2" title="5.1. Single state testing"><div class="titlepage"><div><div><h3 class="title"><a id="SingleStateTesting"></a>5.1. Single state testing</h3></div></div></div><p>
	878	+
	879	+Torbutton is a complicated piece of software. During development, changes to
	880	+one component can affect a whole slough of unrelated features. A number of
	881	+aggregated test suites exist that can be used to test for regressions in
	882	+Torbutton and to help aid in the development of Torbutton-like addons and
	883	+other privacy modifications of other browsers. Some of these test suites exist
	884	+as a single automated page, while others are a series of pages you must visit
	885	+individually. They are provided here for reference and future regression
	886	+testing, and also in the hope that some brave soul will one day decide to
	887	+combine them into a comprehensive automated test suite.
	888	+
	889	+
	890	+ </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://decloak.net/" target="_top">Decloak.net</a><p>
	891	+
	892	+Decloak.net is the canonical source of plugin and external-application based
	893	+proxy-bypass exploits. It is a fully automated test suite maintained by <a class="ulink" href="http://digitaloffense.net/" target="_top">HD Moore</a> as a service for people to
	894	+use to test their anonymity systems.
	895	+
	896	+ </p></li><li class="listitem"><a class="ulink" href="http://deanonymizer.com/" target="_top">Deanonymizer.com</a><p>
	897	+
	898	+Deanonymizer.com is another automated test suite that tests for proxy bypass
	899	+and other information disclosure vulnerabilities. It is maintained by Kyle
	900	+Williams, the author of <a class="ulink" href="http://www.janusvm.com/" target="_top">JanusVM</a>
	901	+and <a class="ulink" href="http://www.januspa.com/" target="_top">JanusPA</a>.
	902	+
	903	+ </p></li><li class="listitem"><a class="ulink" href="https://www.jondos.de/en/anontest" target="_top">JonDos
	904	+AnonTest</a><p>
	905	+
	906	+The <a class="ulink" href="https://www.jondos.de" target="_top">JonDos people</a> also provide an
	907	+anonymity tester. It is more focused on HTTP headers than plugin bypass, and
	908	+points out a couple of headers Torbutton could do a better job with
	909	+obfuscating.
	910	+
	911	+ </p></li><li class="listitem"><a class="ulink" href="http://browserspy.dk" target="_top">Browserspy.dk</a><p>
	912	+
	913	+Browserspy.dk provides a tremendous collection of browser fingerprinting and
	914	+general privacy tests. Unfortunately they are only available one page at a
	915	+time, and there is not really solid feedback on good vs bad behavior in
	916	+the test results.
	917	+
	918	+ </p></li><li class="listitem"><a class="ulink" href="http://analyze.privacy.net/" target="_top">Privacy
	919	+Analyzer</a><p>
	920	+
	921	+The Privacy Analyzer provides a dump of all sorts of browser attributes and
	922	+settings that it detects, including some information on your origin IP
	923	+address. Its page layout and lack of good vs bad test result feedback makes it
	924	+not as useful as a user-facing testing tool, but it does provide some
	925	+interesting checks in a single page.
	926	+
	927	+ </p></li><li class="listitem"><a class="ulink" href="http://ha.ckers.org/mr-t/" target="_top">Mr. T</a><p>
	928	+
	929	+Mr. T is a collection of browser fingerprinting and deanonymization exploits
	930	+discovered by the <a class="ulink" href="http://ha.ckers.org" target="_top">ha.ckers.org</a> crew
	931	+and others. It is also not as user friendly as some of the above tests, but it
	932	+is a useful collection.
	933	+
	934	+ </p></li><li class="listitem">Gregory Fleischer's <a class="ulink" href="http://pseudo-flaw.net/content/tor/torbutton/" target="_top">Torbutton</a> and
	935	+<a class="ulink" href="http://pseudo-flaw.net/content/defcon/dc-17-demos/d.html" target="_top">Defcon
	936	+17</a> Test Cases
	937	+ <p>
	938	+
	939	+Gregory Fleischer has been hacking and testing Firefox and Torbutton privacy
	940	+issues for the past 2 years. He has an excellent collection of all his test
	941	+cases that can be used for regression testing. In his Defcon work, he
	942	+demonstrates ways to infer Firefox version based on arcane browser properties.
	943	+We are still trying to determine the best way to address some of those test
	944	+cases.
	945	+
	946	+ </p></li><li class="listitem"><a class="ulink" href="https://torcheck.xenobite.eu/index.php" target="_top">Xenobite's
	947	+TorCheck Page</a><p>
	948	+
	949	+This page checks to ensure you are using a valid Tor exit node and checks for
	950	+some basic browser properties related to privacy. It is not very fine-grained
	951	+or complete, but it is automated and could be turned into something useful
	952	+with a bit of work.
	953	+
	954	+ </p></li></ol></div><p>
	955	+ </p></div></div></div></body></html>
0	956