tor-commits April 2014

tor-commits@lists.torproject.org

22 participants
2020 discussions

[tor-browser-spec/master] Describe font limiting.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit be2c61fff30c20801707a1fd8597e89de18b043f Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Wed Dec 28 22:21:20 2011 -0600 Describe font limiting. --- docs/design/design.xml | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 0a5df12..df15dbe 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -1233,18 +1233,17 @@ number of bits available to the adversary while avoiding the rendering and language issues of supporting a global font set. </para> - <para><command>Design Goal:</command> - -We intend to <ulink -url="https://trac.torproject.org/projects/tor/ticket/2872">limit the number of -fonts</ulink> a url bar origin can load, gracefully degrading to built-in -and/or remote fonts once the limit is reached. - - </para> <para><command>Implementation Status:</command> -Aside from disabling plugins to prevent enumeration, we have not yet -implemented any defense against CSS or Javascript fonts. +We disable plugins, which prevents font enumeration. Additionally, we limit +both the number of font queries from CSS, as well as the total number of +fonts that can be used in a document by patching Firefox. We create two prefs, +<command>browser.display.max_font_attempts</command> and +<command>browser.display.max_font_count</command> for this purpose. Once these +limits are reached, the browser behaves as if +<command>browser.display.use_document_fonts</command> was reached. We are +still working to determine optimal values for these prefs.  </para> </listitem> @@ -1298,7 +1297,7 @@ hooks</ulink> as well as a window observer to <ulink url="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/t…">resize new windows based on desktop resolution</ulink>. Additionally, we patch Firefox to cause CSS Media Queries to use the client content window size -for all desktop size related media queries.  +for all desktop size related media queries.  </para> <para>

1 0

[tor-browser-spec/master] Begin work on design doc updates for Firefox 17.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit c9da119126462ad40d075712f47cdd60813c8568 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Jan 15 23:42:17 2013 -0800 Begin work on design doc updates for Firefox 17. --- docs/design/Firefox17-TODO | 54 +++++ docs/design/build.sh | 2 +- docs/design/design.xml | 569 ++++++++++++++++++++++++-------------------- 3 files changed, 362 insertions(+), 263 deletions(-) diff --git a/docs/design/Firefox17-TODO b/docs/design/Firefox17-TODO new file mode 100644 index 0000000..5d016e5 --- /dev/null +++ b/docs/design/Firefox17-TODO @@ -0,0 +1,54 @@ +- Cleanups + + We specify browser.cache.memory.enable under disk avoidance. That's + wrong. We don't even set it at all. Torbutton relic? + + Disk leak documentation + - Firefox 17 will mess up all patch links + +- Heavy Writing by section + + Intro: + + We target Firefox ESR + - Adversary Goals + - Describe how each adversary attack violates design goals + - "Correlate activity across multiple site visits" as one of the adversary + goals. This is the primary goal of the ad networks, though. We need to + explicitly mention it in the Adversary Goals section for completeness. + - Misc implementation + - document the environment variables and settings used to provide a non-grey "New Identity" button. + - Link to prefs.js + - Mockup privacy UI + - Identifier Linkability + - 3.5.8 is not clear that what we're trying to limit is non-click + driven/non-interactive linkability rather than linkability in all cases. + Other sections may have this problem, too. + - This is a subtlety that arises from both the impossibility of satisfying + unlinkability due to covert channels in GET/POST, as well as the desire + to avoid breaking thinks like consensual federated login. + - He reminded me about documenting disabling IndexedDB, but that is just one + of the many prefs.js changes we need to document. + - We should only preserve window.name if the url bar domain remains the + same. I could be convinced of this, but it's going to be trickier to + implement and I think it's not really possible to remove linkability for user + clicks in general. + - Fingerprinting + - describe our resolution defenses + - Explain why panopticlick is weirdsauce + - provide an entropy count estimate for fingerprinting defenses + - We should perhaps be more vocal about the fingerprinting issues with + some or all of http://www.w3.org/TR/navigation-timing/. I think I agree. + - Deprecation List/Future Philosophy: + - Linkability Transparency from + https://trac.torproject.org/projects/tor/ticket/5273#comment:12 + - Referer Header + - Window.name + +- List links to design violations/enhancements: + - https://trac.torproject.org/projects/tor/query?keywords=~tbb-linkability + - https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting + +- Tests + - Sync with QA pages + - Many are out of date + - http://www.stayinvisible.com/ + - Evercookie test page, and perhaps also + http://jeremiahgrossman.blogspot.de/2007/04/tracking-users-without-cookies.… + diff --git a/docs/design/build.sh b/docs/design/build.sh index 6531077..68809d5 100755 --- a/docs/design/build.sh +++ b/docs/design/build.sh @@ -1 +1 @@ -xsltproc --output index.html.en --stringparam section.autolabel.max.depth 2 --stringparam section.autolabel 1 /usr/share/sgml/docbook/xsl-stylesheets-1.75.2/xhtml/docbook.xsl design.xml +xsltproc --output index.html.en --stringparam section.autolabel.max.depth 2 --stringparam section.autolabel 1 /usr/share/xml/docbook/stylesheet/docbook-xsl/xhtml-1_1/docbook.xsl design.xml diff --git a/docs/design/design.xml b/docs/design/design.xml index 3677816..d723542 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -23,7 +23,7 @@ <address><email>sjmurdoch#torproject org</email></address> </affiliation> </author> - <pubdate>Dec 28 2011</pubdate> + <pubdate>Dec 30 2012</pubdate> </articleinfo>  </para> <para> @@ -51,268 +51,32 @@ against active network adversaries, in addition to the passive forensic local adversary currently addressed by the major browsers. </para> - <sect2 id="adversary"> - <title>Adversary Model</title> + <sect2 id="components"> + <title>Browser Component Overview</title> <para> -A Tor web browser adversary has a number of goals, capabilities, and attack -types that can be used to guide us towards a set of requirements for the -Tor Browser. Let's start with the goals. +The Tor Browser is based on <ulink +url="https://www.mozilla.org/en-US/firefox/organizations/">Mozilla's Extended +Support Release (ESR) Firefox branch</ulink>. We have a <link +linkend="firefox-patches">series of patches</link> against this browser to +enhance privacy and security. Browser behavior is additionally augmented +through the <ulink +url="https://gitweb.torproject.org/torbutton.git/tree/master">Torbutton +extension</ulink>, though we are in the process of moving this +functionality into direct Firefox patches. We also <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/confi…">change +a number of Firefox preferences</ulink> from their defaults. </para> - <sect3 id="adversarygoals"> - <title>Adversary Goals</title> - <orderedlist> - - <listitem><command>Bypassing proxy settings</command> - <para>The adversary's primary goal is direct compromise and bypass of -Tor, causing the user to directly connect to an IP of the adversary's -choosing.</para> - </listitem> - <listitem><command>Correlation of Tor vs Non-Tor Activity</command> - <para>If direct proxy bypass is not possible, the adversary will likely -happily settle for the ability to correlate something a user did via Tor with -their non-Tor activity. This can be done with cookies, cache identifiers, -javascript events, and even CSS. Sometimes the fact that a user uses Tor may -be enough for some authorities.</para> - </listitem> - <listitem><command>History disclosure</command> - <para> -The adversary may also be interested in history disclosure: the ability to -query a user's history to see if they have issued certain censored search -queries, or visited censored sites. - </para> - </listitem> - <listitem><command>Location information</command> - <para> - -Location information such as timezone and locality can be useful for the -adversary to determine if a user is in fact originating from one of the -regions they are attempting to control, or to zero-in on the geographical -location of a particular dissident or whistleblower. - - </para> - </listitem> - <listitem><command>Miscellaneous anonymity set reduction</command> - <para> - -Anonymity set reduction is also useful in attempting to zero in on a -particular individual. If the dissident or whistleblower is using a rare build -of Firefox for an obscure operating system, this can be very useful -information for tracking them down, or at least <link -linkend="fingerprinting">tracking their activities</link>. - - </para> - </listitem> - <listitem><command>History records and other on-disk -information</command> - <para> -In some cases, the adversary may opt for a heavy-handed approach, such as -seizing the computers of all Tor users in an area (especially after narrowing -the field by the above two pieces of information). History records and cache -data are the primary goals here. - </para> - </listitem> - </orderedlist> - </sect3> - - <sect3 id="adversarypositioning"> - <title>Adversary Capabilities - Positioning</title> - <para> -The adversary can position themselves at a number of different locations in -order to execute their attacks. - </para> - <orderedlist> - <listitem><command>Exit Node or Upstream Router</command> - <para> -The adversary can run exit nodes, or alternatively, they may control routers -upstream of exit nodes. Both of these scenarios have been observed in the -wild. - </para> - </listitem> - <listitem><command>Ad servers and/or Malicious Websites</command> - <para> -The adversary can also run websites, or more likely, they can contract out -ad space from a number of different ad servers and inject content that way. For -some users, the adversary may be the ad servers themselves. It is not -inconceivable that ad servers may try to subvert or reduce a user's anonymity -through Tor for marketing purposes. - </para> - </listitem> - <listitem><command>Local Network/ISP/Upstream Router</command> - <para> -The adversary can also inject malicious content at the user's upstream router -when they have Tor disabled, in an attempt to correlate their Tor and Non-Tor -activity. - </para> - </listitem> - <listitem><command>Physical Access</command> - <para> -Some users face adversaries with intermittent or constant physical access. -Users in Internet cafes, for example, face such a threat. In addition, in -countries where simply using tools like Tor is illegal, users may face -confiscation of their computer equipment for excessive Tor usage or just -general suspicion. - </para> - </listitem> - </orderedlist> - </sect3> - - <sect3 id="attacks"> - <title>Adversary Capabilities - Attacks</title> - <para> - -The adversary can perform the following attacks from a number of different -positions to accomplish various aspects of their goals. It should be noted -that many of these attacks (especially those involving IP address leakage) are -often performed by accident by websites that simply have Javascript, dynamic -CSS elements, and plugins. Others are performed by ad servers seeking to -correlate users' activity across different IP addresses, and still others are -performed by malicious agents on the Tor network and at national firewalls. - - </para> - <orderedlist> - <listitem><command>Read and insert identifiers</command> - <para> - -The browser contains multiple facilities for storing identifiers that the -adversary creates for the purposes of tracking users. These identifiers are -most obviously cookies, but also include HTTP auth, DOM storage, cached -scripts and other elements with embedded identifiers, client certificates, and -even TLS Session IDs. - - </para> - <para> - -An adversary in a position to perform MITM content alteration can inject -document content elements to both read and inject cookies for arbitrary -domains. In fact, even many "SSL secured" websites are vulnerable to this sort of -<ulink url="http://seclists.org/bugtraq/2007/Aug/0070.html">active -sidejacking</ulink>. In addition, the ad networks of course perform tracking -with cookies as well. - - </para> - </listitem> - <listitem id="fingerprinting"><command>Fingerprint users based on browser -attributes</command> -<para> - -There is an absurd amount of information available to websites via attributes -of the browser. This information can be used to reduce anonymity set, or even -uniquely fingerprint individual users. Fingerprinting is an intimidating -problem to attempt to tackle, especially without a metric to determine or at -least intuitively understand and estimate which features will most contribute -to linkability between visits. - -</para> - -<para> - -The <ulink url="https://panopticlick.eff.org/about.php">Panopticlick study -done</ulink> by the EFF uses the actual entropy - the number of identifying -bits of information encoded in browser properties - as this metric. Their -<ulink url="https://wiki.mozilla.org/Fingerprinting#Data">result data</ulink> -is definitely useful, and the metric is probably the appropriate one for -determining how identifying a particular browser property is. However, some -quirks of their study means that they do not extract as much information as -they could from display information: they only use desktop resolution and do -not attempt to infer the size of toolbars. In the other direction, they may be -over-counting in some areas, as they did not compute joint entropy over -multiple attributes that may exhibit a high degree of correlation. Also, new -browser features are added regularly, so the data should not be taken as -final. - - </para> - <para> - -Despite the uncertainty, all fingerprinting attacks leverage the following -attack vectors: - - </para> - <orderedlist> - <listitem><command>Observing Request Behavior</command> - <para> - -Properties of the user's request behavior comprise the bulk of low-hanging -fingerprinting targets. These include: User agent, Accept-* headers, pipeline -usage, and request ordering. Additionally, the use of custom filters such as -AdBlock and other privacy filters can be used to fingerprint request patterns -(as an extreme example). - - </para> - </listitem> - - <listitem><command>Inserting Javascript</command> - <para> - -Javascript can reveal a lot of fingerprinting information. It provides DOM -objects such as window.screen and window.navigator to extract information -about the useragent. - -Also, Javascript can be used to query the user's timezone via the -<function>Date()</function> object, <ulink -url="https://www.khronos.org/registry/webgl/specs/1.0/#5.13">WebGL</ulink> can -reveal information about the video card in use, and high precision timing -information can be used to <ulink -url="http://w2spconf.com/2011/papers/jspriv.pdf">fingerprint the CPU and -interpreter speed</ulink>. In the future, new JavaScript features such as -<ulink url="http://w3c-test.org/webperf/specs/ResourceTiming/">Resource -Timing</ulink> may leak an unknown amount of network timing related -information. - - - - </para> - </listitem> - - <listitem><command>Inserting Plugins</command> - <para> - -The Panopticlick project found that the mere list of installed plugins (in -navigator.plugins) was sufficient to provide a large degree of -fingerprintability. Additionally, plugins are capable of extracting font lists, -interface addresses, and other machine information that is beyond what the -browser would normally provide to content. In addition, plugins can be used to -store unique identifiers that are more difficult to clear than standard -cookies. <ulink url="http://epic.org/privacy/cookies/flash.html">Flash-based -cookies</ulink> fall into this category, but there are likely numerous other -examples. Beyond fingerprinting, plugins are also abysmal at obeying the proxy -settings of the browser. - - - </para> - </listitem> - <listitem><command>Inserting CSS</command> - <para> - -<ulink url="https://developer.mozilla.org/En/CSS/Media_queries">CSS media -queries</ulink> can be inserted to gather information about the desktop size, -widget size, display type, DPI, user agent type, and other information that -was formerly available only to Javascript. - - </para> - </listitem> - </orderedlist> - </listitem> - <listitem><command>Remotely or locally exploit browser and/or -OS</command> - <para> - -Last, but definitely not least, the adversary can exploit either general -browser vulnerabilities, plugin vulnerabilities, or OS vulnerabilities to -install malware and surveillance software. An adversary with physical access -can perform similar actions. Regrettably, this last attack capability is -outside of our ability to defend against, but it is worth mentioning for -completeness. <ulink url="http://tails.boum.org/contribute/design/">The Tails -system</ulink> however can provide some limited defenses against this -adversary. + <para> - </para> - </listitem> - </orderedlist> - </sect3> +To help protect against potential Tor Exit Node eavesdroppers, we include +<ulink url="https://www.eff.org/https-everywhere">HTTPS-Everywhere</ulink>. To +provide users with optional defense-in-depth against Javascript and other +potential exploit vectors, we also include <ulink +url="http://noscript.net/">NoScript</ulink> + </para> </sect2> </sect1> @@ -652,6 +416,269 @@ high-risk features pending analysis, audit, and mitigation. - Location + timezone is part of this - Patches? --> + <sect1 id="adversary"> + <title>Adversary Model</title> + <para> + +A Tor web browser adversary has a number of goals, capabilities, and attack +types that can be used to guide us towards a set of requirements for the +Tor Browser. Let's start with the goals. + + </para> + <sect2 id="adversarygoals"> + <title>Adversary Goals</title> + <orderedlist> + + <listitem><command>Bypassing proxy settings</command> + <para>The adversary's primary goal is direct compromise and bypass of +Tor, causing the user to directly connect to an IP of the adversary's +choosing.</para> + </listitem> + <listitem><command>Correlation of Tor vs Non-Tor Activity</command> + <para>If direct proxy bypass is not possible, the adversary will likely +happily settle for the ability to correlate something a user did via Tor with +their non-Tor activity. This can be done with cookies, cache identifiers, +javascript events, and even CSS. Sometimes the fact that a user uses Tor may +be enough for some authorities.</para> + </listitem> + <listitem><command>History disclosure</command> + <para> +The adversary may also be interested in history disclosure: the ability to +query a user's history to see if they have issued certain censored search +queries, or visited censored sites. + </para> + </listitem> + <listitem><command>Location information</command> + <para> + +Location information such as timezone and locality can be useful for the +adversary to determine if a user is in fact originating from one of the +regions they are attempting to control, or to zero-in on the geographical +location of a particular dissident or whistleblower. + + </para> + </listitem> + <listitem><command>Miscellaneous anonymity set reduction</command> + <para> + +Anonymity set reduction is also useful in attempting to zero in on a +particular individual. If the dissident or whistleblower is using a rare build +of Firefox for an obscure operating system, this can be very useful +information for tracking them down, or at least <link +linkend="fingerprinting">tracking their activities</link>. + + </para> + </listitem> + <listitem><command>History records and other on-disk +information</command> + <para> +In some cases, the adversary may opt for a heavy-handed approach, such as +seizing the computers of all Tor users in an area (especially after narrowing +the field by the above two pieces of information). History records and cache +data are the primary goals here. + </para> + </listitem> + </orderedlist> + </sect2> + + <sect2 id="adversarypositioning"> + <title>Adversary Capabilities - Positioning</title> + <para> +The adversary can position themselves at a number of different locations in +order to execute their attacks. + </para> + <orderedlist> + <listitem><command>Exit Node or Upstream Router</command> + <para> +The adversary can run exit nodes, or alternatively, they may control routers +upstream of exit nodes. Both of these scenarios have been observed in the +wild. + </para> + </listitem> + <listitem><command>Ad servers and/or Malicious Websites</command> + <para> +The adversary can also run websites, or more likely, they can contract out +ad space from a number of different ad servers and inject content that way. For +some users, the adversary may be the ad servers themselves. It is not +inconceivable that ad servers may try to subvert or reduce a user's anonymity +through Tor for marketing purposes. + </para> + </listitem> + <listitem><command>Local Network/ISP/Upstream Router</command> + <para> +The adversary can also inject malicious content at the user's upstream router +when they have Tor disabled, in an attempt to correlate their Tor and Non-Tor +activity. + </para> + </listitem> + <listitem><command>Physical Access</command> + <para> +Some users face adversaries with intermittent or constant physical access. +Users in Internet cafes, for example, face such a threat. In addition, in +countries where simply using tools like Tor is illegal, users may face +confiscation of their computer equipment for excessive Tor usage or just +general suspicion. + </para> + </listitem> + </orderedlist> + </sect2> + + <sect2 id="attacks"> + <title>Adversary Capabilities - Attacks</title> + <para> + +The adversary can perform the following attacks from a number of different +positions to accomplish various aspects of their goals. It should be noted +that many of these attacks (especially those involving IP address leakage) are +often performed by accident by websites that simply have Javascript, dynamic +CSS elements, and plugins. Others are performed by ad servers seeking to +correlate users' activity across different IP addresses, and still others are +performed by malicious agents on the Tor network and at national firewalls. + + </para> + <orderedlist> + <listitem><command>Read and insert identifiers</command> + <para> + +The browser contains multiple facilities for storing identifiers that the +adversary creates for the purposes of tracking users. These identifiers are +most obviously cookies, but also include HTTP auth, DOM storage, cached +scripts and other elements with embedded identifiers, client certificates, and +even TLS Session IDs. + + </para> + <para> + +An adversary in a position to perform MITM content alteration can inject +document content elements to both read and inject cookies for arbitrary +domains. In fact, even many "SSL secured" websites are vulnerable to this sort of +<ulink url="http://seclists.org/bugtraq/2007/Aug/0070.html">active +sidejacking</ulink>. In addition, the ad networks of course perform tracking +with cookies as well. + + </para> + </listitem> + <listitem id="fingerprinting"><command>Fingerprint users based on browser +attributes</command> +<para> + +There is an absurd amount of information available to websites via attributes +of the browser. This information can be used to reduce anonymity set, or even +uniquely fingerprint individual users. Fingerprinting is an intimidating +problem to attempt to tackle, especially without a metric to determine or at +least intuitively understand and estimate which features will most contribute +to linkability between visits. + +</para> + +<para> + +The <ulink url="https://panopticlick.eff.org/about.php">Panopticlick study +done</ulink> by the EFF uses the actual entropy - the number of identifying +bits of information encoded in browser properties - as this metric. Their +<ulink url="https://wiki.mozilla.org/Fingerprinting#Data">result data</ulink> +is definitely useful, and the metric is probably the appropriate one for +determining how identifying a particular browser property is. However, some +quirks of their study means that they do not extract as much information as +they could from display information: they only use desktop resolution and do +not attempt to infer the size of toolbars. In the other direction, they may be +over-counting in some areas, as they did not compute joint entropy over +multiple attributes that may exhibit a high degree of correlation. Also, new +browser features are added regularly, so the data should not be taken as +final. + + </para> + <para> + +Despite the uncertainty, all fingerprinting attacks leverage the following +attack vectors: + + </para> + <orderedlist> + <listitem><command>Observing Request Behavior</command> + <para> + +Properties of the user's request behavior comprise the bulk of low-hanging +fingerprinting targets. These include: User agent, Accept-* headers, pipeline +usage, and request ordering. Additionally, the use of custom filters such as +AdBlock and other privacy filters can be used to fingerprint request patterns +(as an extreme example). + + </para> + </listitem> + + <listitem><command>Inserting Javascript</command> + <para> + +Javascript can reveal a lot of fingerprinting information. It provides DOM +objects such as window.screen and window.navigator to extract information +about the useragent. + +Also, Javascript can be used to query the user's timezone via the +<function>Date()</function> object, <ulink +url="https://www.khronos.org/registry/webgl/specs/1.0/#5.13">WebGL</ulink> can +reveal information about the video card in use, and high precision timing +information can be used to <ulink +url="http://w2spconf.com/2011/papers/jspriv.pdf">fingerprint the CPU and +interpreter speed</ulink>. In the future, new JavaScript features such as +<ulink url="http://w3c-test.org/webperf/specs/ResourceTiming/">Resource +Timing</ulink> may leak an unknown amount of network timing related +information. + + + + </para> + </listitem> + + <listitem><command>Inserting Plugins</command> + <para> + +The Panopticlick project found that the mere list of installed plugins (in +navigator.plugins) was sufficient to provide a large degree of +fingerprintability. Additionally, plugins are capable of extracting font lists, +interface addresses, and other machine information that is beyond what the +browser would normally provide to content. In addition, plugins can be used to +store unique identifiers that are more difficult to clear than standard +cookies. <ulink url="http://epic.org/privacy/cookies/flash.html">Flash-based +cookies</ulink> fall into this category, but there are likely numerous other +examples. Beyond fingerprinting, plugins are also abysmal at obeying the proxy +settings of the browser. + + + </para> + </listitem> + <listitem><command>Inserting CSS</command> + <para> + +<ulink url="https://developer.mozilla.org/En/CSS/Media_queries">CSS media +queries</ulink> can be inserted to gather information about the desktop size, +widget size, display type, DPI, user agent type, and other information that +was formerly available only to Javascript. + + </para> + </listitem> + </orderedlist> + </listitem> + <listitem><command>Remotely or locally exploit browser and/or +OS</command> + <para> + +Last, but definitely not least, the adversary can exploit either general +browser vulnerabilities, plugin vulnerabilities, or OS vulnerabilities to +install malware and surveillance software. An adversary with physical access +can perform similar actions. Regrettably, this last attack capability is +outside of our ability to defend against, but it is worth mentioning for +completeness. <ulink url="http://tails.boum.org/contribute/design/">The Tails +system</ulink> however can provide some limited defenses against this +adversary. + + </para> + </listitem> + </orderedlist> + </sect2> + +</sect1> <sect1 id="Implementation"> <title>Implementation</title> @@ -789,36 +816,54 @@ using several Firefox preferences. The set of prefs is: <command>dom.storage.enabled</command>, -<command>browser.cache.memory.enable</command>, <command>network.http.use-cache</command>, <command>browser.cache.disk.enable</command>, +<command>browser.cache.disk.capacity</command>, <command>browser.cache.offline.enable</command>, <command>general.open_location.last_url</command>, <command>places.history.enabled</command>, <command>browser.formfill.enable</command>, <command>signon.rememberSignons</command>, <command>browser.download.manager.retention</command>, +<command>dom.indexedDB.enabled</command>, and <command>network.cookie.lifetimePolicy</command>. </blockquote> </sect3> <para> + +Torbutton also <ulink +url="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/components/tbSes…">contains +code</ulink> to prevent the Firefox session store from writing to disk. + + </para> + <para> In addition, three Firefox patches are needed to prevent disk writes, even if Private Browsing Mode is enabled. We need to + <ulink url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">prevent the permissions manager from recording HTTPS STS state</ulink>, <ulink url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">prevent -intermediate SSL certificates from being recorded</ulink>, and +intermediate SSL certificates from being recorded</ulink>, <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">prevent +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">prevent +download history from being recorded</ulink>, and +<ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">prevent the content preferences service from recording site zoom</ulink>. + + For more details on these patches, <link linkend="firefox-patches">see the Firefox Patches section</link>. </para> + <para> +For more details on disk leak bugs and enhancements, see the <ulink +url="https://trac.torproject.org/projects/tor/query?status=accepted&status=assig…">tbb-disk-leak tag in our bugtracker</ulink> + </para> </sect2> <sect2 id="app-data-isolation"> <title>Application Data Isolation</title>

1 0

[tor-browser-spec/master] Update TODO.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit b5878bcfa54460f6b8a6bbaeeca29cad58c69616 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Feb 19 13:20:57 2013 -0800 Update TODO. --- docs/design/Firefox17-TODO | 44 +++++++++++++++++++++++--------------------- 1 file changed, 23 insertions(+), 21 deletions(-) diff --git a/docs/design/Firefox17-TODO b/docs/design/Firefox17-TODO index c760f53..633f10a 100644 --- a/docs/design/Firefox17-TODO +++ b/docs/design/Firefox17-TODO @@ -1,20 +1,24 @@ -- Cleanups ++ Cleanups + We specify browser.cache.memory.enable under disk avoidance. That's wrong. We don't even set it at all. Torbutton relic? + Disk leak documentation - - Firefox 17 will mess up all patch links + + Firefox 17 will mess up all patch links - Heavy Writing by section + Intro: + We target Firefox ESR - - Adversary Goals - - Describe how each adversary attack violates design goals - - "Correlate activity across multiple site visits" as one of the adversary + + Component description + + Deprecation List/Future Philosophy: + + Linkability Transparency from + https://trac.torproject.org/projects/tor/ticket/5273#comment:12 + + Adversary Goals + + Describe how each adversary attack violates design goals + + "Correlate activity across multiple site visits" as one of the adversary goals. This is the primary goal of the ad networks, though. We need to explicitly mention it in the Adversary Goals section for completeness. - Misc implementation + + Link to prefs.js and describe omni.ja and extension-overrides hacks - document the environment variables and settings used to provide a non-grey "New Identity" button. - - Link to prefs.js and describe omni.ja and extension-overrides hacks - Mockup privacy UI - Identifier Linkability - Image cache jail @@ -41,32 +45,30 @@ - We should perhaps be more vocal about the fingerprinting issues with some or all of http://www.w3.org/TR/navigation-timing/. I think I agree. - We report our useragent as 17.0 - - Deprecation List/Future Philosophy: - - Linkability Transparency from - https://trac.torproject.org/projects/tor/ticket/5273#comment:12 - - Referer Header - - Window.name + - Testing + - Sync with QA pages + - Many are out of date + - http://www.stayinvisible.com/ + - Evercookie test page, and perhaps also + http://jeremiahgrossman.blogspot.de/2007/04/tracking-users-without-cookies.… - Misc changes: + + Plugin handling + + All-but-flash patch + + Plugin manager manipulation + + We use Firefox's click-to-play - Addons - PDF.js inclusion - Torbutton does not update - Torbutton Security Settings - Update notification/version checking - Socks ports - + Plugin handling - + All-but-flash patch - + Plugin manager manipulation - + We use Firefox's click-to-play + - Create a deprecation list and link to it: + - Referer Header + - Window.name - List links to design violations/enhancements: - https://trac.torproject.org/projects/tor/query?keywords=~tbb-linkability - https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting -- Tests - - Sync with QA pages - - Many are out of date - - http://www.stayinvisible.com/ - - Evercookie test page, and perhaps also - http://jeremiahgrossman.blogspot.de/2007/04/tracking-users-without-cookies.…

1 0

[tor-browser-spec/master] Improve intro + design requirements sections.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit e10aba4118506b52c65380d5af0997dbb76f8418 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Feb 19 12:50:35 2013 -0800 Improve intro + design requirements sections. --- docs/design/design.xml | 45 ++++++++++++++++++++++++++++++++------------- 1 file changed, 32 insertions(+), 13 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 07db627..b7eb0a7 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -23,7 +23,7 @@ <address><email>sjmurdoch#torproject org</email></address> </affiliation> </author> - <pubdate>Dec 30 2012</pubdate> + <pubdate>Feb 19 2013</pubdate> </articleinfo>  +Our long term goal is to reduce all linkability to mechanisms that are +detectable by experts, so they can alert the general public about places +where it occurs. To this end, we maintain a Deprecation List of archaic +web technologies that are currently (ab)used to facilitate federated login +and other legitimate click-driven cross-domain activity but that can +be replaced with more privacy friendly, auditable alternatives. + </para> + </listitem> </orderedlist> </sect2> </sect1>

1 0

[tor-browser-spec/master] Update stale/broken gitweb and trac URLs.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit ec2a7eb797d818b13b45a1e0a17e948d991047c3 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Feb 19 12:18:19 2013 -0800 Update stale/broken gitweb and trac URLs. --- docs/design/design.xml | 79 +++++++++++++++++++++--------------------------- 1 file changed, 35 insertions(+), 44 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index d723542..07db627 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -747,14 +747,19 @@ browser proxy settings. <para> Torbutton disables plugins by using the <command>@mozilla.org/plugin/host;1</command> service to mark the plugin tags -as disabled. Additionally, we set -<command>plugin.disable_full_page_plugin_for_types</command> to the list of -supported mime types for all currently installed plugins. - </para> +as disabled. This block can be undone through both the Torbutton Security UI, +and the Firefox Plugin Preferences. + </para> + <para> +If the user does enable plugins in this way, plugin-handled objects are still +restricted from automatic load through Firefox's click-to-play preference +<command>plugins.click_to_play</command>. + </para> <para> -In addition, to prevent any unproxied activity by plugins at load time, we +In addition, to reduce any unproxied activity by arbitrary plugins at load +time, and to reduce the fingerprintability of the installed plugin list, we also patch the Firefox source code to <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">prevent the load of any plugins except +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">prevent the load of any plugins except for Flash and Gnash</ulink>. </para> @@ -842,16 +847,16 @@ Private Browsing Mode is enabled. We need to  <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">prevent +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">prevent the permissions manager from recording HTTPS STS state</ulink>, <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">prevent +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">prevent intermediate SSL certificates from being recorded</ulink>, <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">prevent +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">prevent download history from being recorded</ulink>, and <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">prevent +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">prevent the content preferences service from recording site zoom</ulink>.  @@ -862,7 +867,7 @@ Firefox Patches section</link>. </para> <para> For more details on disk leak bugs and enhancements, see the <ulink -url="https://trac.torproject.org/projects/tor/query?status=accepted&status=assig…">tbb-disk-leak tag in our bugtracker</ulink> +url="https://trac.torproject.org/projects/tor/query?keywords=~tbb-disk-leak&…">tbb-disk-leak tag in our bugtracker</ulink> </para> </sect2> <sect2 id="app-data-isolation"> @@ -975,7 +980,7 @@ security of the isolation</ulink> and to <ulink url="https://trac.torproject.org/projects/tor/ticket/3754">solve conflicts with OCSP relying the cacheKey property for reuse of POST requests</ulink>, we had to <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">patch +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">patch Firefox to provide a cacheDomain cache attribute</ulink>. We use the fully qualified url bar domain as input to this field. @@ -1011,11 +1016,7 @@ HTTP authentication tokens are removed for third party elements using the url="https://developer.mozilla.org/en/Setting_HTTP_request_headers#Observers">http-on-modify-request observer</ulink> to remove the Authorization headers to prevent <ulink url="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies…">silent -linkability between domains</ulink>. We also needed to <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">patch -Firefox to cause the headers to get added early enough</ulink> to allow the -observer to modify it. - +linkability between domains</ulink>. </para> </listitem> <listitem>DOM Storage @@ -1065,7 +1066,7 @@ We currently clear SSL Session IDs upon <link linkend="new-identity">New Identity</link>, we disable TLS Session Tickets via the Firefox Pref <command>security.enable_tls_session_tickets</command>. We disable SSL Session IDs via a <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">patch +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">patch to Firefox</ulink>. To compensate for the increased round trip latency from disabling these performance optimizations, we also enable <ulink url="https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00">TLS @@ -1307,7 +1308,7 @@ Firefox provides several options for controlling the browser user agent string which we leverage. We also set similar prefs for controlling the Accept-Language and Accept-Charset headers, which we spoof to English by default. Additionally, we <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">remove +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">remove content script access</ulink> to Components.interfaces, which <ulink url="http://pseudo-flaw.net/tor/torbutton/fingerprint-firefox.html">can be used</ulink> to fingerprint OS, platform, and Firefox minor version. </para> @@ -1515,7 +1516,7 @@ audio and video objects. <title>Description of Firefox Patches</title> <para> The set of patches we have against Firefox can be found in the <ulink -url="https://gitweb.torproject.org/torbrowser.git/tree/maint-2.2:/src/current-pa…">current-patches directory of the torbrowser git repository</ulink>. They are: +url="https://gitweb.torproject.org/torbrowser.git/tree/maint-2.4:/src/current-pa…">current-patches directory of the torbrowser git repository</ulink>. They are: </para> <orderedlist> <listitem>Block Components.interfaces and Components.lookupMethod @@ -1563,17 +1564,6 @@ allow this. </para> </listitem> - <listitem>Add HTTP auth headers before on-modify-request fires - <para> - -This patch provides a trivial modification to allow us to properly remove HTTP -auth for third parties. This patch allows us to defend against an adversary -attempting to use <ulink -url="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies…">HTTP -auth to silently track users between domains</ulink>. - - </para> - </listitem> <listitem>Add a string-based cacheKey property for domain isolation <para> @@ -1581,23 +1571,12 @@ To <ulink url="https://trac.torproject.org/projects/tor/ticket/3666">increase the security of cache isolation</ulink> and to <ulink url="https://trac.torproject.org/projects/tor/ticket/3754">solve strange and -unknown conflicts with OCSP</ulink>, we had to <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…">patch -Firefox to provide a cacheDomain cache attribute</ulink>. We use the url bar +unknown conflicts with OCSP</ulink>, we had to patch +Firefox to provide a cacheDomain cache attribute. We use the url bar FQDN as input to this field. </para> </listitem> - <listitem>Randomize HTTP pipeline order and depth - <para> -As an -<ulink -url="https://blog.torproject.org/blog/experimental-defense-website-traffic-finge…">experimental -defense against Website Traffic Fingerprinting</ulink>, we patch the standard -HTTP pipelining code to randomize the number of requests in a -pipeline, as well as their order. - </para> - </listitem> <listitem>Block all plugins except flash <para> We cannot use the <ulink @@ -1648,6 +1627,18 @@ by the <link linkend="new-identity">New Identity</link> button. </para> </listitem> + <listitem>Randomize HTTP pipeline order and depth + <para> +As an +<ulink +url="https://blog.torproject.org/blog/experimental-defense-website-traffic-finge…">experimental +defense against Website Traffic Fingerprinting</ulink>, we patch the standard +HTTP pipelining code to randomize the number of requests in a +pipeline, as well as their order. + </para> + </listitem> + + </orderedlist> </sect2>

1 0

[tor-browser-spec/master] Update Attacks section to link to design requirements.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit 86971c485b3a5547284c8170f19ef7030e0fa78e Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Feb 19 13:20:42 2013 -0800 Update Attacks section to link to design requirements. --- docs/design/design.xml | 61 ++++++++++++++++++++++++++++++++++++------------ 1 file changed, 46 insertions(+), 15 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index b7eb0a7..4d005de 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -478,14 +478,25 @@ location of a particular dissident or whistleblower. </para> </listitem> - <listitem><command>Miscellaneous anonymity set reduction</command> + <listitem><command>Correlate activity across multiple sites</command> <para> -Anonymity set reduction is also useful in attempting to zero in on a -particular individual. If the dissident or whistleblower is using a rare build -of Firefox for an obscure operating system, this can be very useful -information for tracking them down, or at least <link -linkend="fingerprinting">tracking their activities</link>. +The primary goal of the advertising networks is to know that the user who +visited siteX.com is the same user that visited siteY.com to serve them +targeted ads. The advertising networks become our adversary insofar as they +attempt to perform this correlation without the user's explicit consent. + + </para> + </listitem> + <listitem><command>Fingerprinting/anonymity set reduction</command> + <para> + +Fingerprinting (more generally: "anonymity set reduction") is used to attempt +to zero in on a particular individual without the use of tracking identifiers. +If the dissident or whistleblower is using a rare build of Firefox for an +obscure operating system, this can be very useful information for tracking +them down, or at least <link linkend="fingerprinting">tracking their +activities</link>. </para> </listitem> @@ -577,6 +588,13 @@ sidejacking</ulink>. In addition, the ad networks of course perform tracking with cookies as well. </para> + <para> + +These types of attacks are attempts at subverting our <link +linkend="identifier-linkability">Cross-Origin Identifier Unlinkability</ulink> and <link +linkend="new-identity">Long-Term Unlikability</ulink> design requirements. + + </para> </listitem> <listitem id="fingerprinting"><command>Fingerprint users based on browser attributes</command> @@ -584,7 +602,17 @@ attributes</command> There is an absurd amount of information available to websites via attributes of the browser. This information can be used to reduce anonymity set, or even -uniquely fingerprint individual users. Fingerprinting is an intimidating +uniquely fingerprint individual users. Attacks of this nature are typically +aimed at tracking users across sites without their consent, in an attempt to +subvert our <link linkend="fingerprinting-linkability">Cross-Origin +Fingerprinting Unlinkability</ulink> and <link +linkend="new-identity">Long-Term Unlikability</ulink> design requirements. + +</para> + +<para> + +Fingerprinting is an intimidating problem to attempt to tackle, especially without a metric to determine or at least intuitively understand and estimate which features will most contribute to linkability between visits. @@ -594,10 +622,12 @@ to linkability between visits. <para> The <ulink url="https://panopticlick.eff.org/about.php">Panopticlick study -done</ulink> by the EFF uses the actual entropy - the number of identifying -bits of information encoded in browser properties - as this metric. Their -<ulink url="https://wiki.mozilla.org/Fingerprinting#Data">result data</ulink> -is definitely useful, and the metric is probably the appropriate one for +done</ulink> by the EFF uses the <ulink +url="https://en.wikipedia.org/wiki/Entropy_%28information_theory%29">Shannon +entropy</ulink> - the number of identifying bits of information encoded in +browser properties - as this metric. Their <ulink +url="https://wiki.mozilla.org/Fingerprinting#Data">result data</ulink> is +definitely useful, and the metric is probably the appropriate one for determining how identifying a particular browser property is. However, some quirks of their study means that they do not extract as much information as they could from display information: they only use desktop resolution and do @@ -687,10 +717,11 @@ Last, but definitely not least, the adversary can exploit either general browser vulnerabilities, plugin vulnerabilities, or OS vulnerabilities to install malware and surveillance software. An adversary with physical access can perform similar actions. Regrettably, this last attack capability is -outside of our ability to defend against, but it is worth mentioning for -completeness. <ulink url="http://tails.boum.org/contribute/design/">The Tails -system</ulink> however can provide some limited defenses against this -adversary. +outside of the browser's ability to defend against, but it is worth mentioning +for completeness. In fact, <ulink +url="http://tails.boum.org/contribute/design/">The Tails system</ulink> can +provide some defense against this adversary, and it does include the Tor +Browser. </para> </listitem>

1 0

[tor-browser-spec/master] Update FF17 TODO with more notes from the TBB changelog.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit 66dd51296801200ce41fb293f05f23a263fc119b Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Feb 19 12:18:38 2013 -0800 Update FF17 TODO with more notes from the TBB changelog. --- docs/design/Firefox17-TODO | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/docs/design/Firefox17-TODO b/docs/design/Firefox17-TODO index 5d016e5..c760f53 100644 --- a/docs/design/Firefox17-TODO +++ b/docs/design/Firefox17-TODO @@ -14,9 +14,11 @@ explicitly mention it in the Adversary Goals section for completeness. - Misc implementation - document the environment variables and settings used to provide a non-grey "New Identity" button. - - Link to prefs.js + - Link to prefs.js and describe omni.ja and extension-overrides hacks - Mockup privacy UI - - Identifier Linkability + - Identifier Linkability + - Image cache jail + - DOM storage jail - 3.5.8 is not clear that what we're trying to limit is non-click driven/non-interactive linkability rather than linkability in all cases. Other sections may have this problem, too. @@ -30,17 +32,33 @@ implement and I think it's not really possible to remove linkability for user clicks in general. - Fingerprinting + - @font-face exemption and preference + - Canvas prompt + - Click-to-play WebGL - describe our resolution defenses - Explain why panopticlick is weirdsauce - provide an entropy count estimate for fingerprinting defenses - We should perhaps be more vocal about the fingerprinting issues with some or all of http://www.w3.org/TR/navigation-timing/. I think I agree. + - We report our useragent as 17.0 - Deprecation List/Future Philosophy: - Linkability Transparency from https://trac.torproject.org/projects/tor/ticket/5273#comment:12 - Referer Header - Window.name +- Misc changes: + - Addons + - PDF.js inclusion + - Torbutton does not update + - Torbutton Security Settings + - Update notification/version checking + - Socks ports + + Plugin handling + + All-but-flash patch + + Plugin manager manipulation + + We use Firefox's click-to-play + - List links to design violations/enhancements: - https://trac.torproject.org/projects/tor/query?keywords=~tbb-linkability - https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting

1 0

[tor-browser-spec/master] Update Mock-UP Privacy UI graphic.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit e399deda2f9fd4d11c78227b6a7cfdd577d23a8c Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Feb 19 14:08:49 2013 -0800 Update Mock-UP Privacy UI graphic. --- docs/design/NewCookieManager.png | Bin 0 -> 27939 bytes docs/design/design.xml | 17 +++++++---------- 2 files changed, 7 insertions(+), 10 deletions(-) diff --git a/docs/design/NewCookieManager.png b/docs/design/NewCookieManager.png new file mode 100644 index 0000000..97a0b40 Binary files /dev/null and b/docs/design/NewCookieManager.png differ diff --git a/docs/design/design.xml b/docs/design/design.xml index 59ce6ef..6aed854 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -970,22 +970,19 @@ context-menu option to drill down into specific types of state or permissions. An example of this simplification can be seen in Figure 1. </para> -  <figure><title>Improving the Privacy UI</title> <mediaobject> <imageobject> - <imagedata align="center" fileref="CookieManagers.png"/> + <imagedata align="center" fileref="NewCookieManager.png"/> </imageobject> </mediaobject> <caption> <para/> -On the left is the standard Firefox cookie manager. On the right is a mock-up -of how isolating identifiers to the URL bar origin might simplify the privacy -UI for all data - not just cookies. Both windows represent the set of -Cookies accumulated after visiting just five sites, but the window on the -right has the option of also representing history, DOM Storage, HTTP Auth, -search form history, login values, and so on within a context menu for each -site. +This UI is a mock-up of how isolating identifiers to the URL bar origin might +simplify the privacy UI for all data - not just cookies. Once browser +identifiers and site permissions operate on a url bar basis, the same privacy +window can represent browsing history, DOM Storage, HTTP Auth, search form +history, login values, and so on within a context menu for each site. </caption> </figure> @@ -1532,7 +1529,7 @@ All linkable identifiers and browser state MUST be cleared by this feature. First, Torbutton disables Javascript in all open tabs and windows by using both the <ulink -url="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocSh…">browser.docShell.allowJavascript<ulink> +url="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocSh…">browser.docShell.allowJavascript</ulink> attribute as well as <ulink url="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDOMWi…">nsIDOMWindowUtil.suppressEventHandling()</ulink>. We then stop all page activity for each tab using <ulink

1 0

[tor-browser-spec/master] Update fingerprinting section.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit d86f8fa4e0d99545bba5f11fb7dc96add7c89566 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Feb 19 16:30:47 2013 -0800 Update fingerprinting section. --- docs/design/design.xml | 272 +++++++++++++++++++++++++++++++----------------- 1 file changed, 174 insertions(+), 98 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 6aed854..ea5bdad 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -40,7 +40,7 @@ This document describes the <link linkend="adversary">adversary model</link>, <link linkend="Implementation">implementation</link>, <link linkend="Packaging">packaging</link> and <link linkend="Testing">testing procedures</link> of the Tor Browser.  +current as of Tor Browser 2.3.35-1 and Torbutton 1.4.5. --> </para> <para> @@ -1054,6 +1054,14 @@ have an additional "domain=string" property prepended, which will list the FQDN that was used to source the third party element. </para> + <para> + +Additionally, because the image cache is a separate entity from the content +cache, we had to patch Firefox to also <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">isolate +this cache per url bar domain</ulink>. + + </para> </listitem> <listitem>HTTP Auth <para> @@ -1067,16 +1075,13 @@ linkability between domains</ulink>. </para> </listitem> <listitem>DOM Storage - <para><command>Design Goal:</command> + <para> DOM storage for third party domains MUST be isolated to the url bar origin, -to prevent linkability between sites. - - </para> - <para><command>Implementation Status:</command> - -Because it is isolated to third party domain as opposed to top level url bar -origin, we entirely disable DOM storage as a stopgap to ensure unlinkability. +to prevent linkability between sites. This functionality is provided through a +<ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">patch +to Firefox</ulink>. </para> </listitem> @@ -1099,7 +1104,7 @@ file on Windows, so Flash remains difficult to enable. </para> </listitem> - <listitem>SSL+TLS session resumption and HTTP Keep-Alive + <listitem>SSL+TLS session resumption, HTTP Keep-Alive and SPDY <para><command>Design Goal:</command> TLS session resumption tickets and SSL Session IDs MUST be limited to the url @@ -1130,6 +1135,11 @@ from the last packet read on the connection) using the Firefox preference <command>network.http.keep-alive.timeout</command>. </para> + <para> +However, because SPDY can store identifiers and has extremely long keepalive +duration, it is disabled through the Firefox preference +<command>network.http.spdy.enabled</command>. + </para> </listitem> <listitem>Automated cross-origin redirects MUST NOT store identifiers <para><command>Design Goal:</command> @@ -1171,11 +1181,12 @@ storage</ulink>. </para> <para> -In order to eliminate linkability but still allow for sites that utilize this -property to function, we reset the window.name property of tabs in Torbutton every -time we encounter a blank referer. This behavior allows window.name to persist -for the duration of a link-driven navigation session, but as soon as the user -enters a new URL or navigates between https/http schemes, the property is cleared. +In order to eliminate non-consensual linkability but still allow for sites +that utilize this property to function, we reset the window.name property of +tabs in Torbutton every time we encounter a blank referer. This behavior +allows window.name to persist for the duration of a click-driven navigation +session, but as soon as the user enters a new URL or navigates between +https/http schemes, the property is cleared. </para> </listitem> @@ -1246,32 +1257,41 @@ In order to properly address the fingerprinting adversary on a technical level, we need a metric to measure linkability of the various browser properties beyond any stored origin-related state. <ulink url="https://panopticlick.eff.org/about.php">The Panopticlick Project</ulink> -by the EFF provides us with exactly this metric. The researchers conducted a -survey of volunteers who were asked to visit an experiment page that harvested -many of the above components. They then computed the Shannon Entropy of the -resulting distribution of each of several key attributes to determine how many -bits of identifying information each attribute provided. +by the EFF provides us with a prototype of such a metric. The researchers +conducted a survey of volunteers who were asked to visit an experiment page +that harvested many of the above components. They then computed the Shannon +Entropy of the resulting distribution of each of several key attributes to +determine how many bits of identifying information each attribute provided. </para> <para> -The study is not exhaustive, though. In particular, the test does not take in -all aspects of resolution information. It did not calculate the size of -widgets, window decoration, or toolbar size, which we believe may add high -amounts of entropy. It also did not measure clock offset and other time-based -fingerprints. Furthermore, as new browser features are added, this experiment -should be repeated to include them. +Many browser features have been added since the EFF first ran their experiment +and collected their data. To avoid an infinite sinkhole, we reduce the efforts +for fingerprinting resistance by only concerning ourselves with reducing the +fingerprintable differences <emphasis>among</emphasis> Tor Browser users. We +do not believe it is possible to solve cross-browser fingerprinting issues. </para> <para> -On the other hand, to avoid an infinite sinkhole, we reduce the efforts for -fingerprinting resistance by only concerning ourselves with reducing the -fingerprintable differences <emphasis>among</emphasis> Tor Browser users. We -do not believe it is productive to concern ourselves with cross-browser -fingerprinting issues, at least not at this stage. +Unfortunately, the unsolvable nature of the cross-browser fingerprinting +problem means that the Panopticlick test website itself is not useful for +evaluating the actual effectiveness of our defenses, or the fingerprinting +defenses of any other web browser. Because the Panopticlick dataset is based +on browser data spanning a number of widely deployed browsers over a number of +years, any fingerprinting defenses attempted by browsers today are very likely +to cause Panopticlick to report an <emphasis>increase</emphasis> in +fingerprintability and entropy, because those defenses will stand out in sharp +contrast to historical data. We have been <ulink +url="https://trac.torproject.org/projects/tor/ticket/6119">working to convince +the EFF</ulink> that it is worthwhile to release the source code to +Panopticlick to allow us to run our own version for this reason. </para> + <sect3 id="fingerprinting-defenses"> + <title>Fingerprinting defenses in the Tor Browser</title> + <orderedlist> <listitem>Plugins <para> @@ -1286,19 +1306,75 @@ All plugins that have not been specifically audited or sandboxed MUST be disabled. To reduce linkability potential, even sandboxed plugins should not be allowed to load objects until the user has clicked through a click-to-play barrier. Additionally, version information should be reduced or obfuscated -until the plugin object is loaded. +until the plugin object is loaded. For flash, we wish to <ulink +url="https://trac.torproject.org/projects/tor/ticket/3974">provide a +settings.sol file</ulink> to disable Flash cookies, and to restrict P2P +features that are likely to bypass proxy settings. </para> <para><command>Implementation Status:</command> Currently, we entirely disable all plugins in Tor Browser. However, as a -compromise due to the popularity of Flash, we intend to <ulink -url="https://trac.torproject.org/projects/tor/ticket/3974">work -towards</ulink> a -click-to-play barrier using NoScript that is available only after the user has -specifically enabled plugins. Flash will be the only plugin available, and we -will ship a settings.sol file to disable Flash cookies, and to restrict P2P -features that likely bypass proxy settings. +compromise due to the popularity of Flash, we allow users to re-enable Flash, +and flash objects are blocked behind a click-to-play barrier that is available +only after the user has specifically enabled plugins. Flash is the only plugin +available, the rest are <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">entirely +blocked from loading by a Firefox patch</ulink>. We also set the Firefox +preference <command>plugin.expose_full_path</command> to false, to avoid +leaking plugin installation information. + + </para> + </listitem> + <listitem>HTML5 Canvas Image Extraction + <para> + +The <ulink url="https://developer.mozilla.org/en-US/docs/HTML/Canvas">HTML5 +Canvas</ulink> is a feature that has been added to major browsers after the +EFF developed their Panopticlick study. After plugins and plugin-provided +information, we believe that the HTML5 Canvas is the single largest +fingerprinting threat browsers face today. <ulink +url="http://www.w2spconf.com/2012/papers/w2sp12-final4.pdf">Initial +studies</ulink> show that the Canvas can provide an easy-access fingerprinting +target: The adversary simply renders WebGL, font, and named color data to a +Canvas element, extracts the image buffer, and computes a hash of that image +data. Subtle differences in the video card, font packs, and even the font +library versions allow the adversary to produce a stable, simple, easy to use, +high-entropy fingerprint of a computer. In fact, the hash of the rendered +image can be used almost identically to a tracking cookie by the web server. + + </para> + <para> + +To reduce the threat from this vector, we have patched Firefox to <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">prompt +before returning valid image data</ulink> to the Canvas APIs. If the user +hasn't previously allowed the site in the URL bar to access Canvas image data, +pure white image data is returned to the Javascript APIs. + + </para> + </listitem> + <listitem>WebGL + <para> + +WebGL is fingerprintable both through information that is exposed about the +underlying driver and optimizations, as well as through performance +fingerprinting. + + </para> + <para> + +Because of the large amount of potential fingerprinting vectors and the <ulink +url="http://www.contextis.com/resources/blog/webgl/">previously unexposed +vulnerability surface</ulink>, we deploy a similar strategy against WebGL as +for plugins. First, WebGL Canvases have click-to-play placeholders (provided +by NoScript), and do not run until authorized by the user. Second, we +obfuscate driver information by setting the Firefox preferences +<command>webgl.disable-extensions</command> and +<command>webgl.min_capability_mode</command>, which reduce the information +provided by the following WebGL API calls: <command>getParameter()</command>, +<command>getSupportedExtensions()</command>, and +<command>getExtension()</command>. </para> </listitem> @@ -1330,44 +1406,31 @@ language issues of supporting a global font set. We disable plugins, which prevents font enumeration. Additionally, we limit both the number of font queries from CSS, as well as the total number of -fonts that can be used in a document by patching Firefox. We create two prefs, +fonts that can be used in a document <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">with +a Firefox patch</ulink>. We create two prefs, <command>browser.display.max_font_attempts</command> and <command>browser.display.max_font_count</command> for this purpose. Once these limits are reached, the browser behaves as if <command>browser.display.use_document_fonts</command> was reached. We are -still working to determine optimal values for these prefs.  +still working to determine optimal values for these prefs. </para> - </listitem> - <listitem>User Agent and HTTP Headers - <para><command>Design Goal:</command> + <para> -All Tor Browser users MUST provide websites with an identical user agent and -HTTP header set for a given request type. We omit the Firefox minor revision, -and report a popular Windows platform. If the software is kept up to date, -these headers should remain identical across the population even when updated. +To improve rendering, we exempt remote @font-face fonts from these counts, and +if a font-family CSS rule lists a remote font (in any order), we use that font +instead of any of the named local fonts. </para> - <para><command>Implementation Status:</command> - -Firefox provides several options for controlling the browser user agent string -which we leverage. We also set similar prefs for controlling the -Accept-Language and Accept-Charset headers, which we spoof to English by default. Additionally, we -<ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">remove -content script access</ulink> to Components.interfaces, which <ulink -url="http://pseudo-flaw.net/tor/torbutton/fingerprint-firefox.html">can be -used</ulink> to fingerprint OS, platform, and Firefox minor version. </para> - </listitem> - <listitem>Desktop resolution and CSS Media Queries + <listitem>Desktop resolution, CSS Media Queries, and System Colors <para> Both CSS and Javascript have a lot of irrelevant information about the screen -resolution, usable desktop size, OS widget size, toolbar size, title bar size, and -other desktop features that are not at all relevant to rendering and serve -only to provide information for fingerprinting. +resolution, usable desktop size, OS widget size, toolbar size, title bar size, +system theme colors, and other desktop features that are not at all relevant +to rendering and serve only to provide information for fingerprinting. </para> <para><command>Design Goal:</command> @@ -1387,10 +1450,13 @@ desktop resolution. We have implemented the above strategy for Javascript using Torbutton's <ulink url="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/j…">JavaScript hooks</ulink> as well as a window observer to <ulink -url="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/t…">resize -new windows based on desktop resolution</ulink>. Additionally, we patch -Firefox to cause CSS Media Queries to use the client content window size -for all desktop size related media queries.  +url="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/t…">resize +new windows based on desktop resolution</ulink>. Additionally, we <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">patch +Firefox</ulink> to cause CSS Media Queries to use the client content window size +for all desktop size related media queries. We also <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">patch Firefox to report a +fixed set of system colors to content window CSS</ulink>. </para> <para> @@ -1401,6 +1467,27 @@ resolution information. </para> </listitem> + <listitem>User Agent and HTTP Headers + <para><command>Design Goal:</command> + +All Tor Browser users MUST provide websites with an identical user agent and +HTTP header set for a given request type. We omit the Firefox minor revision, +and report a popular Windows platform. If the software is kept up to date, +these headers should remain identical across the population even when updated. + + </para> + <para><command>Implementation Status:</command> + +Firefox provides several options for controlling the browser user agent string +which we leverage. We also set similar prefs for controlling the +Accept-Language and Accept-Charset headers, which we spoof to English by default. Additionally, we +<ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">remove +content script access</ulink> to Components.interfaces, which <ulink +url="http://pseudo-flaw.net/tor/torbutton/fingerprint-firefox.html">can be +used</ulink> to fingerprint OS, platform, and Firefox minor version. </para> + + </listitem> <listitem>Timezone and clock offset <para><command>Design Goal:</command> @@ -1451,7 +1538,24 @@ optimum trade-off between quantization+jitter and amortization time. </para> <para><command>Implementation Status:</command> -We have no implementation as of yet. +Currently, the only mitigation against performance fingerprinting is to +disable <ulink url="http://www.w3.org/TR/navigation-timing/">Navigation +Timing</ulink> through the Firefox preference +<command>dom.enable_performance</command>. + + </para> + </listitem> + <listitem>Non-Uniform HTML5 API Implementations + <para> + +At least two HTML5 features have differnt implementation status across the +major OS vendors: the <ulink +url="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.battery">Battery +API</ulink> and the <ulink +url="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.connection">Network +Connection API</ulink>. We disable these APIs +through the Firefox preferences <command>dom.battery.enabled</command> and +<command>dom.network.enabled</command>. </para> </listitem> @@ -1472,36 +1576,8 @@ fingerprinting: timestamp quantization and jitter. We have no implementation as of yet. </para> </listitem> - <listitem>WebGL - <para> - -WebGL is fingerprintable both through information that is exposed about the -underlying driver and optimizations, as well as through performance -fingerprinting. - - </para> - <para><command>Design Goal:</command> - -Because of the large amount of potential fingerprinting vectors, we intend to -deploy a similar strategy against WebGL as for plugins. First, WebGL canvases -will have click-to-play placeholders, and will not run until authorized by the -user. Second, we intend to <ulink -url="https://trac.torproject.org/projects/tor/ticket/3323">obfuscate driver -information</ulink> by hooking -<command>getParameter()</command>, -<command>getSupportedExtensions()</command>, -<command>getExtension()</command>, and -<command>getContextAttributes()</command> to provide standard minimal, -driver-neutral information. - - </para> - <para><command>Implementation Status:</command> - -Currently we simply disable WebGL. - - </para> - </listitem> </orderedlist> + </sect3> </sect2> <sect2 id="new-identity"> <title>Long-Term Unlinkability via "New Identity" button</title>

1 0

[tor-browser-spec/master] Improve "New Identity" documentation.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit 33506d4a7d41846de45dc53f0d61f77ad021a8ff Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Feb 19 13:58:58 2013 -0800 Improve "New Identity" documentation. --- docs/design/design.xml | 60 ++++++++++++++++++++++++++++++++---------------- 1 file changed, 40 insertions(+), 20 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 4d005de..59ce6ef 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -591,8 +591,8 @@ with cookies as well. <para> These types of attacks are attempts at subverting our <link -linkend="identifier-linkability">Cross-Origin Identifier Unlinkability</ulink> and <link -linkend="new-identity">Long-Term Unlikability</ulink> design requirements. +linkend="identifier-linkability">Cross-Origin Identifier Unlinkability</link> and <link +linkend="new-identity">Long-Term Unlikability</link> design requirements. </para> </listitem> @@ -605,8 +605,8 @@ of the browser. This information can be used to reduce anonymity set, or even uniquely fingerprint individual users. Attacks of this nature are typically aimed at tracking users across sites without their consent, in an attempt to subvert our <link linkend="fingerprinting-linkability">Cross-Origin -Fingerprinting Unlinkability</ulink> and <link -linkend="new-identity">Long-Term Unlikability</ulink> design requirements. +Fingerprinting Unlinkability</link> and <link +linkend="new-identity">Long-Term Unlikability</link> design requirements. </para> @@ -1509,8 +1509,11 @@ Currently we simply disable WebGL. <sect2 id="new-identity"> <title>Long-Term Unlinkability via "New Identity" button</title> <para> + In order to avoid long-term linkability, we provide a "New Identity" context -menu option in Torbutton. +menu option in Torbutton. This context menu option is active if Torbutton can +read the environment variables $TOR_CONTROL_PASSWD and $TOR_CONTROL_PORT. + </para> <sect3> @@ -1525,25 +1528,42 @@ All linkable identifiers and browser state MUST be cleared by this feature. <sect3> <title>Implementation Status:</title> <blockquote> + <para> + +First, Torbutton disables Javascript in all open tabs and windows by using +both the <ulink +url="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocSh…">browser.docShell.allowJavascript<ulink> +attribute as well as <ulink +url="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDOMWi…">nsIDOMWindowUtil.suppressEventHandling()</ulink>. +We then stop all page activity for each tab using <ulink +url="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIWebNa…">browser.webNavigation.stop(nsIWebNavigation.STOP_ALL)</ulink>. +We then clear the site-specific Zoom by temporarily disabling the preference +<command>browser.zoom.siteSpecific</command>, and clear the GeoIP wiki token +URL and the last opened URL prefs (if they exist). Each tab is then closed. + + </para> + <para> -First, Torbutton disables all open tabs and windows by tagging them and -blocking them via the nsIContentPolicy, and then closes each tab and -window. The extra step for blocking tabs is done as a precaution to ensure -that any asynchronous Javascript is in fact properly disabled. After closing -all of the windows, we then clear the following state: OCSP (by toggling -security.OCSP.enabled), cache, site-specific zoom and content preferences, -Cookies, DOM storage, safe browsing key, the Google wifi geolocation token (if -exists), HTTP auth, SSL Session IDs, HSTS state, close all remaining HTTP -keep-alive connections, and clear the last opened URL field (via the pref -general.open_location.last_url). After clearing the browser state, we then -send the NEWNYM signal to the Tor control port to cause a new circuit to be -created. +After closing all tabs, we then clear the following state: searchbox and +findbox text, HTTP auth, SSL state, OCSP state, site-specific content +preferences (including HSTS state), content and image cache, Cookies, DOM storage, safe browsing key, the +Google wifi geolocation token (if exists). + </para> + <para> + +After the state is cleared, we then close all remaining HTTP keep-alive +connections and then send the NEWNYM signal to the Tor control port to cause a +new circuit to be created. + </para> + <para> +Finally, a fresh browser window is opened, and the current browser window is +closed. + </para> </blockquote> <blockquote> -Additionally, the user is allowed to "protect" cookies of their choosing from -deletion during New Identity by using the Torbutton Cookie Protections UI to -protect the cookies they would like to keep across New Identity invocations. +If the user chose to "protect" cookie by using the Torbutton Cookie +Protections UI, those cookies are not cleared as part of the above. </blockquote> </sect3> </sect2>

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits April 2014