April 2014 - tor-commits - lists.torproject.org

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

28 Apr '14

commit ea5f34a032323821f408413447a45fe7679f5976 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Wed Feb 20 18:26:51 2013 -0800 Misc cleanups. --- docs/design/design.xml | 45 +++++++++++++++++++++++---------------------- 1 file changed, 23 insertions(+), 22 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 223ca0c..254726f 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -2294,9 +2294,9 @@ javascript into the chrome (and thus gain complete control of the browser). <title>Towards Linkability Transparency</title> <para> -The <link linkend="privacy">privacy properties</link> in Tor Browser are -designed around a model that assumes that link click navigation indicates user -consent for tracking between the linking site and the destination site. This +The <link linkend="privacy">privacy properties</link> of Tor Browser are +based upon the assumption that link click navigation indicates user +consent to tracking between the linking site and the destination site. This definition of consent is primarily pragmatic: It is simply not possible to entirely prevent the ability of a destination site to collaberate with a source site during link-click nagivation (due to GET parameters, POST parameters, and @@ -2305,13 +2305,14 @@ several other vectors, both explicit and implicit). </para> <para> -However, with a few changes to web standards, it is at least possible to make -it evident to experts and attentive users when such collaboration is occurring +However, with a few changes to web standards, it is possible to make it +evident to experts and attentive users when such collaboration is occurring before they actually click on a link. In an ideal world, if a user clicks on a -link that leads to another url bar origin, the vector of tracking possible -during that link click would be limited to the contents of the URL parameters -itself. This section serves to enumerate web technologies that create other -link-click side channels that hinder user awareness of link-click tracking. +link that leads to another url bar origin, the mechanisms of tracking during +that link click would be limited to the contents of URL parameters that are +fully visible to the user <emphasis>before</emphasis> they click. This section +serves to enumerate web technologies that create other link-click side +channels that hinder user awareness of navigation tracking. </para> @@ -2324,7 +2325,7 @@ unlinkability. </para> -<sect1 id="deprecate"> +<sect2 id="deprecate"> <title>Deprecation Wishlist</title> <orderedlist> <listitem>The Referer Header @@ -2352,8 +2353,8 @@ source URL parameters. We believe the Referer header should be either eliminated or made explicit. If a site wishes to transmit its URL to third parties or during link-click, it -should specify this as a property of its HTML. With an explicit property, it -would be possible for the user agent to inform the user if they are about to +should have to specify this as a property of its HTML. With an explicit property, it +would then be possible for the user agent to inform the user if they are about to click on a link that will either transmit referer information or specified a <ulink url="https://developer.mozilla.org/en-US/docs/HTML/Element/a#Attributes">"ping"</ulink> @@ -2374,7 +2375,7 @@ XSRF protection and federated login. <para> It's our opinion that the contents of window.name should not be preserved for -cross-origin navigation, but doing so may break federated login. +cross-origin navigation, but doing so may break federated login for some sites. </para> </listitem> @@ -2385,21 +2386,21 @@ In general, it should not be possible for onclick handlers to alter the navigation destination of 'a' tags, transform them into POST requests, or otherwise create situations where a user believes they are clicking on a link leading to one URL and end up on another. This functionality is deceptive and -is frequently a vector for malware. +is frequently a vector for malware and phishing attacks. </para> <para> -Automated cross-origin redirects are one form of behavior that it is possible -for us to address ourselves. We are still working on finding the best way to handle -<ulink url="https://trac.torproject.org/projects/tor/ticket/3600">that -issue</ulink>. +Automated cross-origin redirects are one form of this behavior that is +possible for us to address ourselves. We are still working on finding the best +way to handle <ulink +url="https://trac.torproject.org/projects/tor/ticket/3600">that issue</ulink>. </para> </listitem> </orderedlist> -</sect1> -<sect1> +</sect2> +<sect2> <title>Promising Standards</title> <orderedlist> <listitem><ulink url="http://web-send.org">Web-Send Introducer</ulink> @@ -2413,7 +2414,7 @@ features</ulink>, as well. </para> </listitem> - <listitem><ulink url="https://developer.mozilla.org/en-US/docs/Persona">Mozilla Persona</ulink> (formerly BrowserID) + <listitem><ulink url="https://developer.mozilla.org/en-US/docs/Persona">Mozilla Persona</ulink> <para> Mozilla's Persona is designed to provide decentralized, cryptographically @@ -2425,6 +2426,6 @@ better solution to the federated login problem. </para> </listitem> </orderedlist> -</sect1> +</sect2> </appendix> </article>

1 0

[tor-browser-spec/master] Move the navigation tracking transparency material to appendix.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit 9c1a4faf2e5b95b1c0dafbd90f0a21af25766163 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Fri Feb 22 19:37:02 2013 -0800 Move the navigation tracking transparency material to appendix. --- docs/design/design.xml | 33 ++++++++++++++++++++------------- 1 file changed, 20 insertions(+), 13 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index c775bec..c3c0cd8 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -401,6 +401,7 @@ their proper deployment or privacy realization. However, we will likely disable high-risk features pending analysis, audit, and mitigation. </para> </listitem> + </orderedlist> </sect2> </sect1> @@ -2297,25 +2299,30 @@ javascript into the chrome (and thus gain complete control of the browser). <title>Towards Transparency in Navigation Tracking</title> <para> -The <link linkend="privacy">privacy properties</link> of Tor Browser are -based upon the assumption that link-click navigation indicates user -consent to tracking between the linking site and the destination site. This -definition of consent is primarily pragmatic: It is simply not possible to -entirely prevent the ability of a destination site to collaberate with a source -site during link-click nagivation (due to GET parameters, POST parameters, and -several other vectors, both explicit and implicit). +The <link linkend="privacy">privacy properties</link> of Tor Browser are based +upon the assumption that link-click navigation indicates user consent to +tracking between the linking site and the destination site. While this +definition is sufficient to allow us to eliminate cross-site third party +tracking with only minimal site breakage, it is our long-term goal to further +reduce cross-origin click navigation tracking to mechanisms that are +detectable by attentive users, so they can alert the general public if +cross-origin click navigation tracking is happening where it should not be. </para> <para> -However, in an ideal world, the mechanisms of tracking that can be employed by -a link would be limited to the contents of URL parameters and other properties -that are fully visible to the user before they click. This section serves to -enumerate web technologies that create other link-click side channels that -serve to hinder user awareness of such navigation tracking. +In an ideal world, the mechanisms of tracking that can be employed during a +link click would be limited to the contents of URL parameters and other +properties that are fully visible to the user before they click. However, the +entrenched nature of certain archaic web features make it impossible for us to +achieve this transparency goal by ourselves without substantial site breakage. +So, instead we maintain a <link linkend="deprecate">Deprecation +Wishlist</link> of archaic web technologies that are currently being (ab)used +to facilitate federated login and other legitimate click-driven cross-domain +activity but that can one day be replaced with more privacy friendly, +auditable alternatives. </para> - <para> Because the total elimination of side channels during cross-origin navigation

1 0

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

28 Apr '14

commit 88ef6838588102f002edcb0486f6f995b2e83c85 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Wed Feb 20 19:32:23 2013 -0800 Misc cleanups. --- docs/design/design.xml | 146 +++++++++++++++++++++++++----------------------- 1 file changed, 77 insertions(+), 69 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 254726f..ff2580e 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -36,11 +36,11 @@ <para> This document describes the <link linkend="adversary">adversary model</link>, -<link linkend="DesignRequirements">design requirements</link>, -<link linkend="Implementation">implementation</link>,  and <link linkend="Testing">testing -procedures</link> of the Tor Browser.  +procedures</link> of the Tor Browser. It is current as of Tor Browser 2.3.25-4 +and Torbutton 1.5.0. </para> <para> @@ -325,7 +325,7 @@ be restricted from running automatically on every page (via click-to-play placeholders), and/or be sandboxed to restrict the types of system calls they can execute. If the user decides to craft an exemption to allow a plugin to be used, it MUST only apply to the top level url bar domain, and not to all sites, -to reduce linkability. +to reduce cross-origin fingerprinting linkability. </para> </listitem> @@ -401,16 +401,25 @@ their proper deployment or privacy realization. However, we will likely disable high-risk features pending analysis, audit, and mitigation. </para> </listitem> - <listitem><command>Strive for Linkability Transparency</command> + <listitem><command>Transparency in Navigation Tracking</command> <para> -Our long term goal is to reduce all linkability to mechanisms that are -detectable by experts and attentive users, so they can alert the general -public about places where it occurs. To this end, we maintain a <link -linkend="deprecate">Deprecation Wishlist</link> 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. +While we believe it is possible to restrict third party tracking with only +minimal site breakage, it is our long-term goal to further reduce cross-origin +click navigation tracking to mechanisms that are detectable by experts and +attentive users, so they can alert the general public if cross-origin +click navigation tracking is happening where it should not be. + + </para> + <para> + +However, the entrenched nature of certain archaic web features make it +impossible for us to achieve this wider goal by ourselves without substantial +site breakage. So, instead we maintain a <link linkend="deprecate">Deprecation +Wishlist</link> of archaic web technologies that are currently being (ab)used +to facilitate federated login and other legitimate click-driven cross-domain +activity but that can one day be replaced with more privacy friendly, +auditable alternatives. </para> </listitem> @@ -999,11 +1008,11 @@ An example of this simplification can be seen in Figure 1. </mediaobject> <caption> <para/> -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. +This example UI is a mock-up of how isolating identifiers to the URL bar +origin can 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> @@ -1452,7 +1461,7 @@ instead of any of the named local fonts. <listitem>Desktop resolution, CSS Media Queries, and System Colors <para> -Both CSS and Javascript have a lot of irrelevant information about the screen +Both CSS and Javascript have access to a lot of information about the screen 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. @@ -1466,7 +1475,7 @@ report all rendering information correctly with respect to the size and properties of the content window, but report an effective size of 0 for all border material, and also report that the desktop is only as big as the inner content window. Additionally, new browser windows are sized such that -their content windows are one of ~5 fixed sizes based on the user's +their content windows are one of a few fixed sizes based on the user's desktop resolution. </para> @@ -1487,13 +1496,6 @@ url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa a fixed set of system colors to content window CSS</ulink>. </para> - <para> - -As far as we know, this fully satisfies our design goals for desktop -resolution information. - - </para> - </listitem> <listitem>User Agent and HTTP Headers <para><command>Design Goal:</command> @@ -2291,11 +2293,11 @@ javascript into the chrome (and thus gain complete control of the browser). --> </sect1> <appendix id="Transparency"> -<title>Towards Linkability Transparency</title> +<title>Towards Transparency in Navigation Tracking</title> <para> The <link linkend="privacy">privacy properties</link> of Tor Browser are -based upon the assumption that link click navigation indicates user +based upon the assumption that link-click navigation indicates user consent to tracking between the linking site and the destination site. This definition of consent is primarily pragmatic: It is simply not possible to entirely prevent the ability of a destination site to collaberate with a source @@ -2305,23 +2307,21 @@ several other vectors, both explicit and implicit). </para> <para> -However, with a few changes to web standards, it is possible to make it -evident to experts and attentive users when such collaboration is occurring -before they actually click on a link. In an ideal world, if a user clicks on a -link that leads to another url bar origin, the mechanisms of tracking during -that link click would be limited to the contents of URL parameters that are -fully visible to the user <emphasis>before</emphasis> they click. This section -serves to enumerate web technologies that create other link-click side -channels that hinder user awareness of navigation tracking. +However, in an ideal world, the mechanisms of tracking that can be employed by +a link would be limited to the contents of URL parameters and other properties +that are fully visible to the user before they click. This section serves to +enumerate web technologies that create other link-click side channels that +serve to hinder user awareness of such navigation tracking. </para> <para> Because the total elimination of side channels during cross-origin navigation -will undoubtably break federated login, we also list promising web draft -standards that would restore this functionality while still preserving -unlinkability. +will undoubtably break federated login as well as destroy ad revenue, we +also describe auditable alternatives and promising web draft standards that would +preserve this functionality while still providing transparency when tracking is +occurring. </para> @@ -2334,29 +2334,32 @@ unlinkability. We haven't disabled or restricted the referer ourselves because of the non-trivial number of sites that rely on the referer header to "authenticate" image requests and deep-link navigation on their sites. Furthermore, there -seems to be no real privacy benefit to taking this action in a vaccuum, -because many sites have begun encoding referer URL information into GET -parameters when they need it to cross http to https scheme transitions. -Google+'s +1 buttons are the best example of this activity. +seems to be no real privacy benefit to taking this action by itself in a +vaccuum, because many sites have begun encoding referer URL information into +GET parameters when they need it to cross http to https scheme transitions. +Google's +1 buttons are the best example of this activity. </para> <para> -Because of the availability of other explicit vectors, the main risk of the -referer header is through inadvertant and/or covert data leakage. In fact, -<ulink url="http://www2.research.att.com/~bala/papers/wosn09.pdf">a great deal -of personal data</ulink> is inadvertantly leaked to third parties through the +Because of the availability of these other explicit vectors, we believe the +main risk of the referer header is through inadvertant and/or covert data +leakage. In fact, <ulink +url="http://www2.research.att.com/~bala/papers/wosn09.pdf">a great deal of +personal data</ulink> is inadvertantly leaked to third parties through the source URL parameters. </para> <para> -We believe the Referer header should be either eliminated or made explicit. If -a site wishes to transmit its URL to third parties or during link-click, it -should have to specify this as a property of its HTML. With an explicit property, it -would then be possible for the user agent to inform the user if they are about to -click on a link that will either transmit referer information or specified a -<ulink +We believe the Referer header should be made explicit. If a site wishes to +transmit its URL to third party content elements during load or during +link-click, it should have to specify this as a property of the associated +HTML tag. With an explicit property, it would then be possible for the user +agent to inform the user if they are about to click on a link that will +transmit referer information (perhaps through something as subtle as a +different color for the destination URL). This same UI notification can also +be used for links with the <ulink url="https://developer.mozilla.org/en-US/docs/HTML/Element/a#Attributes">"ping"</ulink> attribute. @@ -2369,7 +2372,7 @@ url="https://developer.mozilla.org/En/DOM/Window.name">window.name</ulink> is a DOM property that for some reason is allowed to retain a persistent value for the lifespan of a browser tab. It is possible to utilize this property for <ulink url="http://www.thomasfrank.se/sessionvars.html">identifier -storage</ulink> during click navigation. It is sometimes used for additional +storage</ulink> during click navigation. This is sometimes used for additional XSRF protection and federated login. </para> <para> @@ -2383,18 +2386,22 @@ cross-origin navigation, but doing so may break federated login for some sites. <para> In general, it should not be possible for onclick handlers to alter the -navigation destination of 'a' tags, transform them into POST requests, or -otherwise create situations where a user believes they are clicking on a link -leading to one URL and end up on another. This functionality is deceptive and -is frequently a vector for malware and phishing attacks. +navigation destination of 'a' tags, silently transform them into POST +requests, or otherwise create situations where a user believes they are +clicking on a link leading to one URL that ends up on another. This +functionality is deceptive and is frequently a vector for malware and phishing +attacks. Unfortunately, many legitimate sites also employ such transparent +link rewriting, and blanket disabling this functionality ourselves will simply +cause Tor Browser to fail to navigate properly on these sites. </para> <para> Automated cross-origin redirects are one form of this behavior that is -possible for us to address ourselves. We are still working on finding the best -way to handle <ulink -url="https://trac.torproject.org/projects/tor/ticket/3600">that issue</ulink>. +possible for us to <ulink +url="https://trac.torproject.org/projects/tor/ticket/3600">address +ourselves</ulink>, as they are comparatively rare and can be handled with site +permissions. </para> </listitem> @@ -2406,11 +2413,11 @@ url="https://trac.torproject.org/projects/tor/ticket/3600">that issue</ulink>. <listitem><ulink url="http://web-send.org">Web-Send Introducer</ulink> <para> -Web-Send is a browser-based link sharing (aka Like button) and federated login -widget that is designed to operate without relying on third-party linkability -or abusing other cross-origin link-click side channels. It has a compelling -list of <ulink url="http://web-send.org/features.html">privacy and security -features</ulink>, as well. +Web-Send is a browser-based link sharing and federated login widget that is +designed to operate without relying on third-party tracking or abusing other +cross-origin link-click side channels. It has a compelling list of <ulink +url="http://web-send.org/features.html">privacy and security features</ulink>, +especially if used as a "Like button" replacement. </para> </listitem> @@ -2419,9 +2426,10 @@ features</ulink>, as well. Mozilla's Persona is designed to provide decentralized, cryptographically authenticated federated login in a way that does not expose the user to third -party linkability or require browser redirects or side channels. While it does +party tracking or require browser redirects or side channels. While it does not directly provide the link sharing capabilities that Web-Send does, it is a -better solution to the federated login problem. +better solution to the privacy issues associated with federated login than +Web-Send is. </para> </listitem>

1 0

[tor-browser-spec/master] Actually link to Firefox patches.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit ba337f0e1c8368ef48197ebceed202d436b5aa2c Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Wed Feb 20 15:02:00 2013 -0800 Actually link to Firefox patches. --- docs/design/design.xml | 97 ++++++++++++++++++++++++++++++++---------------- 1 file changed, 66 insertions(+), 31 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 4b0e53c..2b71a97 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -1689,11 +1689,15 @@ audio and video objects. <sect2 id="firefox-patches"> <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.4:/src/current-pa…">current-patches directory of the torbrowser git repository</ulink>. They are: + </para> <orderedlist> - <listitem>Block Components.interfaces + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Block +Components.interfaces</ulink> <para> In order to reduce fingerprinting, we block access to this interface from @@ -1702,7 +1706,9 @@ platform, OS, and Firebox version, but not much else. </para> </listitem> - <listitem>Make Permissions Manager memory only + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Make +Permissions Manager memory only</ulink> <para> This patch exposes a pref 'permissions.memory_only' that properly isolates the @@ -1716,7 +1722,9 @@ does not need to be set in prefs.js, and can be handled by Torbutton. </para> </listitem> - <listitem>Make Intermediate Cert Store memory-only + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Make +Intermediate Cert Store memory-only</ulink> <para> The intermediate certificate store records the intermediate SSL certificates @@ -1735,7 +1743,9 @@ allow this. </para> </listitem> - <listitem>Add a string-based cacheKey property for domain isolation + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Add +a string-based cacheKey property for domain isolation</ulink> <para> To <ulink @@ -1748,7 +1758,9 @@ FQDN as input to this field. </para> </listitem> - <listitem>Block all plugins except flash + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Block +all plugins except flash</ulink> <para> We cannot use the <ulink url="http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/c…"> @@ -1759,14 +1771,16 @@ URLs, magical toolbars that phone home or "help" the user, skype buttons that ruin our day, and censorship filters). Hence we rolled our own. </para> </listitem> - <listitem>Make content-prefs service memory only + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Make content-prefs service memory only</ulink> <para> This patch prevents random URLs from being inserted into content-prefs.sqllite in the profile directory as content prefs change (includes site-zoom and perhaps other site prefs?). </para> </listitem> - <listitem>Make Tor Browser exit when not launched from Vidalia + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Make Tor Browser exit when not launched from Vidalia</ulink> <para> It turns out that on Windows 7 and later systems, the Taskbar attempts to @@ -1779,7 +1793,8 @@ Browser to immediately exit in this case. </para> </listitem> - <listitem>Disable SSL Session ID tracking + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Disable SSL Session ID tracking</ulink> <para> This patch is a simple 1-line hack to prevent SSL connections from caching @@ -1789,7 +1804,8 @@ defaults. </para> </listitem> - <listitem>Provide an observer event to close persistent connections + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Provide an observer event to close persistent connections</ulink> <para> This patch creates an observer event in the HTTP connection manager to close @@ -1798,7 +1814,8 @@ by the <link linkend="new-identity">New Identity</link> button. </para> </listitem> - <listitem>Limit Device and System Specific Media Queries + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Limit Device and System Specific Media Queries</ulink> <para> <ulink url="https://developer.mozilla.org/en-US/docs/CSS/Media_queries">CSS @@ -1808,7 +1825,8 @@ resolution was equal to the content window resolution. </para> </listitem> - <listitem>Limit the number of fonts per document + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Limit the number of fonts per document</ulink> <para> Font availability can be <ulink url="http://flippingtypical.com/">queried by @@ -1820,14 +1838,16 @@ appear in the same font-family rule. </para> </listitem> - <listitem>Rebrand Firefox to Tor Browser + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Rebrand Firefox to Tor Browser</ulink> <para> This patch updates our branding in compliance with Mozilla's trademark policy. </para> </listitem> - <listitem>Make Download Manager Memory Only + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Make Download Manager Memory Only</ulink> <para> This patch prevents disk leaks from the download manager. The original @@ -1836,7 +1856,8 @@ you disable download history from your Firefox preferences. </para> </listitem> - <listitem>Add DDG and StartPage to Omnibox + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Add DDG and StartPage to Omnibox</ulink> <para> This patch adds DuckDuckGo and StartPage to the Search Box, and sets our @@ -1845,7 +1866,8 @@ Captchas and complete 403 bans from Google. </para> </listitem> - <listitem>Make nsICacheService.EvictEntires() Synchronous + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Make nsICacheService.EvictEntires() Synchronous</ulink> <para> This patch eliminates a race condition with "New Identity". Without it, @@ -1854,7 +1876,8 @@ on some platforms. </para> </listitem> - <listitem>Prevent WebSockets DNS Leak + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Prevent WebSockets DNS Leak</ulink> <para> This patch prevents a DNS leak when using WebSockets. It also prevents other @@ -1862,7 +1885,8 @@ similar types of DNS leaks. </para> </listitem> - <listitem>Randomize HTTP pipeline order and depth + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Randomize HTTP pipeline order and depth</ulink> <para> As an <ulink @@ -1872,7 +1896,8 @@ HTTP pipelining code to randomize the number of requests in a pipeline, as well as their order. </para> </listitem> - <listitem>Adapt Steve Michaud's Mac crashfix patch + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Adapt Steve Michaud's Mac crashfix patch</ulink> <para> This patch allows us to block Drag and Drop without causing crashes on Mac OS. @@ -1882,7 +1907,8 @@ using your browser's proxy settings, of course). </para> </listitem> - <listitem>Add mozIThirdPartyUtil.getFirstPartyURI() API + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Add mozIThirdPartyUtil.getFirstPartyURI() API</ulink> <para> This patch provides an API that allows us to more easily isolate identifiers @@ -1890,7 +1916,8 @@ to the URL bar domain. </para> </listitem> - <listitem>Add canvas image extraction prompt + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Add canvas image extraction prompt</ulink> <para> This patch prompts the user before returning canvas image data. Canvas image @@ -1900,7 +1927,8 @@ system fonts, and supporting library versions. </para> </listitem> - <listitem>Return client window coordinates for mouse events + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Return client window coordinates for mouse events</ulink> <para> This patch causes mouse events to return coordinates relative to the content @@ -1908,7 +1936,8 @@ window instead of the desktop. </para> </listitem> - <listitem>Do not expose physical screen info to window.screen + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Do not expose physical screen info to window.screen</ulink> <para> This patch causes window.screen to return the display resolution size of the @@ -1916,7 +1945,8 @@ content window instead of the desktop resolution size. </para> </listitem> - <listitem>Do not expose system colors to CSS or canvas + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Do not expose system colors to CSS or canvas</ulink> <para> This patch prevents CSS and Javascript from discovering your desktop color @@ -1924,7 +1954,8 @@ scheme and/or theme. </para> </listitem> - <listitem>Isolate the Image Cache per url bar domain + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Isolate the Image Cache per url bar domain</ulink> <para> This patch prevents cached images from being used to store third party tracking @@ -1932,7 +1963,8 @@ identifiers. </para> </listitem> - <listitem>nsIHTTPChannel.redirectTo() API + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">nsIHTTPChannel.redirectTo() API</ulink> <para> This patch provides HTTPS-Everywhere with an API to perform redirections more @@ -1940,7 +1972,8 @@ securely and without addon conflicts. </para> </listitem> - <listitem>Isolate DOM Storage to first party URI + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Isolate DOM Storage to first party URI</ulink> <para> This patch prevents DOM Storage from being used to store third party tracking @@ -2260,16 +2293,16 @@ javascript into the chrome (and thus gain complete control of the browser). <para> In a few cases, entrenched (mis)use of certain browser features has caused us -to choose a less extreme implementation of linkability protections than we +to choose a less thorough implementation of linkability protections than we would have liked. This section serves to enumerate those instances and describe alternative standardards that have been proposed. </para> <para> -The primary goal of this section is to help describe a web where websites can -be easily audited for good privacy practices. Right now, there are too many -ways where XXX.. +The primary goal of this section is to provide guidance towards altering web +standards such that websites can be easily audited for good privacy practices. +Right now, there are too many ways where XXX.. </para> @@ -2278,9 +2311,11 @@ ways where XXX.. <orderedlist> <listitem>The Referer Header <para> + We believe the Referer header should be either eliminated or made explicit. If a site wishes to transmit its URL to third parties or during link-click, it -should specify this as a property of its HTML. The +should specify this as a property of its HTML. + </para> </listitem> <listitem>window.name

1 0

[tor-browser-spec/master] Remove testing section for now.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit 11db38944e5e5309aeeeac3f2ce67c5277b02ec3 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Fri Feb 22 17:40:23 2013 -0800 Remove testing section for now. --- docs/design/design.xml | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index ff2580e..c775bec 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -36,10 +36,10 @@ <para> This document describes the <link linkend="adversary">adversary model</link>, -<link linkend="DesignRequirements">design requirements</link>, <link -linkend="Implementation">implementation</link>,  and <link linkend="Testing">testing -procedures</link> of the Tor Browser. It is current as of Tor Browser 2.3.25-4 +<link linkend="DesignRequirements">design requirements</link>, and <link +linkend="Implementation">implementation</link>  of the Tor Browser. It is current as of Tor Browser 2.3.25-4 and Torbutton 1.5.0. </para> @@ -814,8 +814,7 @@ as smb urls and other custom protocol handers are all blocked. </para> <para> -Numerous other third parties have also reviewed and <link -linkend="SingleStateTesting">tested</link> the proxy settings +Numerous other third parties have also reviewed and tested the proxy settings and have provided test cases based on their work. See in particular <ulink url="http://decloak.net/">decloak.net</ulink>. @@ -2040,6 +2039,7 @@ identifiers. </sect1> --> +  </sect1> +--> <appendix id="Transparency"> <title>Towards Transparency in Navigation Tracking</title> <para>

1 0

[tor-browser-spec/master] Fill in the linkability transparency section.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit 71ae9a6ec760fcd08a96e4a4cee55fad40c8b7e4 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Wed Feb 20 17:36:17 2013 -0800 Fill in the linkability transparency section. --- docs/design/design.xml | 131 +++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 113 insertions(+), 18 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 2b71a97..223ca0c 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -403,13 +403,15 @@ high-risk features pending analysis, audit, and mitigation. </listitem> <listitem><command>Strive for Linkability Transparency</command> <para> - + 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. +detectable by experts and attentive users, so they can alert the general +public about places where it occurs. To this end, we maintain a <link +linkend="deprecate">Deprecation Wishlist</link> 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> @@ -2292,42 +2294,135 @@ javascript into the chrome (and thus gain complete control of the browser). <title>Towards Linkability Transparency</title> <para> -In a few cases, entrenched (mis)use of certain browser features has caused us -to choose a less thorough implementation of linkability protections than we -would have liked. This section serves to enumerate those instances and -describe alternative standardards that have been proposed. +The <link linkend="privacy">privacy properties</link> in Tor Browser are +designed around a model that assumes that link click navigation indicates user +consent for tracking between the linking site and the destination site. This +definition of consent is primarily pragmatic: It is simply not possible to +entirely prevent the ability of a destination site to collaberate with a source +site during link-click nagivation (due to GET parameters, POST parameters, and +several other vectors, both explicit and implicit). </para> <para> -The primary goal of this section is to provide guidance towards altering web -standards such that websites can be easily audited for good privacy practices. -Right now, there are too many ways where XXX.. +However, with a few changes to web standards, it is at least possible to make +it evident to experts and attentive users when such collaboration is occurring +before they actually click on a link. In an ideal world, if a user clicks on a +link that leads to another url bar origin, the vector of tracking possible +during that link click would be limited to the contents of the URL parameters +itself. This section serves to enumerate web technologies that create other +link-click side channels that hinder user awareness of link-click tracking. </para> -<sect1> - <title>Deprecation List</title> +<para> + +Because the total elimination of side channels during cross-origin navigation +will undoubtably break federated login, we also list promising web draft +standards that would restore this functionality while still preserving +unlinkability. + +</para> + +<sect1 id="deprecate"> + <title>Deprecation Wishlist</title> <orderedlist> <listitem>The Referer Header <para> +We haven't disabled or restricted the referer ourselves because of the +non-trivial number of sites that rely on the referer header to "authenticate" +image requests and deep-link navigation on their sites. Furthermore, there +seems to be no real privacy benefit to taking this action in a vaccuum, +because many sites have begun encoding referer URL information into GET +parameters when they need it to cross http to https scheme transitions. +Google+'s +1 buttons are the best example of this activity. + + </para> + <para> + +Because of the availability of other explicit vectors, the main risk of the +referer header is through inadvertant and/or covert data leakage. In fact, +<ulink url="http://www2.research.att.com/~bala/papers/wosn09.pdf">a great deal +of personal data</ulink> is inadvertantly leaked to third parties through the +source URL parameters. + + </para> + <para> + We believe the Referer header should be either eliminated or made explicit. If a site wishes to transmit its URL to third parties or during link-click, it -should specify this as a property of its HTML. +should specify this as a property of its HTML. With an explicit property, it +would be possible for the user agent to inform the user if they are about to +click on a link that will either transmit referer information or specified a +<ulink +url="https://developer.mozilla.org/en-US/docs/HTML/Element/a#Attributes">"ping"</ulink> +attribute. </para> </listitem> <listitem>window.name + <para> +<ulink +url="https://developer.mozilla.org/En/DOM/Window.name">window.name</ulink> is +a DOM property that for some reason is allowed to retain a persistent value +for the lifespan of a browser tab. It is possible to utilize this property for +<ulink url="http://www.thomasfrank.se/sessionvars.html">identifier +storage</ulink> during click navigation. It is sometimes used for additional +XSRF protection and federated login. + </para> + <para> + +It's our opinion that the contents of window.name should not be preserved for +cross-origin navigation, but doing so may break federated login. + + </para> + </listitem> + <listitem>Javascript link rewriting + <para> + +In general, it should not be possible for onclick handlers to alter the +navigation destination of 'a' tags, transform them into POST requests, or +otherwise create situations where a user believes they are clicking on a link +leading to one URL and end up on another. This functionality is deceptive and +is frequently a vector for malware. + + </para> + <para> + +Automated cross-origin redirects are one form of behavior that it is possible +for us to address ourselves. We are still working on finding the best way to handle +<ulink url="https://trac.torproject.org/projects/tor/ticket/3600">that +issue</ulink>. + + </para> </listitem> </orderedlist> </sect1> <sect1> <title>Promising Standards</title> <orderedlist> - <listitem>Web-Send Introducers + <listitem><ulink url="http://web-send.org">Web-Send Introducer</ulink> + <para> + +Web-Send is a browser-based link sharing (aka Like button) and federated login +widget that is designed to operate without relying on third-party linkability +or abusing other cross-origin link-click side channels. It has a compelling +list of <ulink url="http://web-send.org/features.html">privacy and security +features</ulink>, as well. + + </para> </listitem> - <listitem>Mozilla Persona + <listitem><ulink url="https://developer.mozilla.org/en-US/docs/Persona">Mozilla Persona</ulink> (formerly BrowserID) + <para> + +Mozilla's Persona is designed to provide decentralized, cryptographically +authenticated federated login in a way that does not expose the user to third +party linkability or require browser redirects or side channels. While it does +not directly provide the link sharing capabilities that Web-Send does, it is a +better solution to the federated login problem. + + </para> </listitem> </orderedlist> </sect1>

1 0

[tor-browser-spec/master] Remove some redundant plugin info.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit b54317e011774c7d0c4904c5e4a5534d926d21b1 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Fri Feb 22 20:00:47 2013 -0800 Remove some redundant plugin info. --- docs/design/design.xml | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 8ffef05..65c2893 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -1453,9 +1453,10 @@ still working to determine optimal values for these prefs. </para> <para> -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. +To improve rendering, we exempt remote <ulink +url="https://developer.mozilla.org/en-US/docs/CSS/@font-face">@font-face +fonts</ulink> 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> </listitem> @@ -1676,6 +1677,7 @@ Protections UI, those cookies are not cleared as part of the above. </blockquote> </sect3> </sect2> + <sect2 id="firefox-patches"> <title>Description of Firefox Patches</title> <para>

1 0

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

28 Apr '14

commit a2aa7c3c3f1d7944bdef4dae834d041b5a7b004d Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Fri Feb 22 19:46:24 2013 -0800 Spell check. --- docs/design/design.xml | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index c3c0cd8..8ffef05 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -811,7 +811,7 @@ geolocation queries, searchbox queries, XPCOM addon HTTPS/HTTP activity, WebSockets, and live bookmark updates. We have also verified that IPv6 connections are not attempted, through the proxy or otherwise (Tor does not yet support IPv6). We have also verified that external protocol helpers, such -as smb urls and other custom protocol handers are all blocked. +as smb urls and other custom protocol handlers are all blocked. </para> <para> @@ -1158,7 +1158,7 @@ False Start</ulink> via the Firefox Pref </para> <para> -Becuase of the extreme performance benefits of HTTP Keep-Alive for interactive +Because of the extreme performance benefits of HTTP Keep-Alive for interactive web apps, and because of the difficulties of conveying urlbar origin information down into the Firefox HTTP layer, as a compromise we currently merely reduce the HTTP Keep-Alive timeout to 20 seconds (which is measured @@ -1579,7 +1579,7 @@ Timing</ulink> through the Firefox preference <listitem>Non-Uniform HTML5 API Implementations <para> -At least two HTML5 features have differnt implementation status across the +At least two HTML5 features have different 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 @@ -1772,14 +1772,14 @@ url="http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/c @mozilla.org/extensions/blocklist;1</ulink> service, because we actually want to stop plugins from ever entering the browser's process space and/or executing code (for example, AV plugins that collect statistics/analyze -URLs, magical toolbars that phone home or "help" the user, skype buttons that +URLs, magical toolbars that phone home or "help" the user, Skype buttons that ruin our day, and censorship filters). Hence we rolled our own. </para> </listitem> <listitem><ulink url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Make content-prefs service memory only</ulink> <para> -This patch prevents random URLs from being inserted into content-prefs.sqllite in +This patch prevents random URLs from being inserted into content-prefs.sqlite in the profile directory as content prefs change (includes site-zoom and perhaps other site prefs?). </para> @@ -1790,8 +1790,8 @@ url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa It turns out that on Windows 7 and later systems, the Taskbar attempts to automatically learn the most frequent apps used by the user, and it recognizes -Tor Browser as a seperate app from Vidalia. This can cause users to try to -launch Tor Brower without Vidalia or a Tor instance running. Worse, the Tor +Tor Browser as a separate app from Vidalia. This can cause users to try to +launch Tor Browser without Vidalia or a Tor instance running. Worse, the Tor Browser will automatically find their default Firefox profile, and properly connect directly without using Tor. This patch is a simple hack to cause Tor Browser to immediately exit in this case. @@ -1872,7 +1872,7 @@ Captchas and complete 403 bans from Google. </para> </listitem> <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Make nsICacheService.EvictEntires() Synchronous</ulink> +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">Make nsICacheService.EvictEntries() Synchronous</ulink> <para> This patch eliminates a race condition with "New Identity". Without it, @@ -2326,7 +2326,7 @@ auditable alternatives. <para> Because the total elimination of side channels during cross-origin navigation -will undoubtably break federated login as well as destroy ad revenue, we +will undoubtedly break federated login as well as destroy ad revenue, we also describe auditable alternatives and promising web draft standards that would preserve this functionality while still providing transparency when tracking is occurring. @@ -2343,7 +2343,7 @@ We haven't disabled or restricted the referer ourselves because of the non-trivial number of sites that rely on the referer header to "authenticate" image requests and deep-link navigation on their sites. Furthermore, there seems to be no real privacy benefit to taking this action by itself in a -vaccuum, because many sites have begun encoding referer URL information into +vacuum, because many sites have begun encoding referer URL information into GET parameters when they need it to cross http to https scheme transitions. Google's +1 buttons are the best example of this activity. @@ -2351,10 +2351,10 @@ Google's +1 buttons are the best example of this activity. <para> Because of the availability of these other explicit vectors, we believe the -main risk of the referer header is through inadvertant and/or covert data +main risk of the referer header is through inadvertent and/or covert data leakage. In fact, <ulink url="http://www2.research.att.com/~bala/papers/wosn09.pdf">a great deal of -personal data</ulink> is inadvertantly leaked to third parties through the +personal data</ulink> is inadvertently leaked to third parties through the source URL parameters. </para>

1 0

[tor-browser-spec/master] Fix charset and section issues.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit 41a1fe7108de3341a09734e49e622e839f6e08b6 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Mon Feb 25 13:32:33 2013 -0800 Fix charset and section issues. --- docs/design/build.sh | 2 +- docs/design/design.xml | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/design/build.sh b/docs/design/build.sh index 68809d5..5ffb650 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/xml/docbook/stylesheet/docbook-xsl/xhtml-1_1/docbook.xsl design.xml +xsltproc --output index.html.en -stringparam chunker.output.encoding UTF-8 --stringparam section.autolabel.max.depth 2 -stringparam section.label.includes.component.label 1 --stringparam section.autolabel 1 /usr/share/xml/docbook/stylesheet/docbook-xsl/xhtml/docbook.xsl design.xml diff --git a/docs/design/design.xml b/docs/design/design.xml index db91456..6609661 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -2336,7 +2336,7 @@ occurring. </para> -<sect2 id="deprecate"> +<sect1 id="deprecate"> <title>Deprecation Wishlist</title> <orderedlist> <listitem>The Referer Header @@ -2417,8 +2417,8 @@ permissions. </para> </listitem> </orderedlist> -</sect2> -<sect2> +</sect1> +<sect1> <title>Promising Standards</title> <orderedlist> <listitem><ulink url="http://web-send.org">Web-Send Introducer</ulink> @@ -2445,6 +2445,6 @@ Web-Send is. </para> </listitem> </orderedlist> -</sect2> +</sect1> </appendix> </article>

1 0

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

28 Apr '14

commit 565b6c71b77d5b0e63b02bcbda7079b4e3463fea Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Fri Feb 22 20:02:04 2013 -0800 Update date. --- docs/design/design.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 65c2893..db91456 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>Feb 19 2013</pubdate> + <pubdate>Feb 23 2013</pubdate> </articleinfo> <!--

1 0