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

[tor-browser-spec/master] Typo from Georg.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit cf1a6d58c41c07941e3abb6f815b865a7ac9019a Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Sun Oct 9 22:53:23 2011 -0700 Typo from Georg. --- 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 91b74a6..414241c 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -843,7 +843,7 @@ Firefoxes. As a stopgap to satisfy our design requirement of unlinkability, we currently entirely disable 3rd party cookies by setting <command>network.cookie.cookieBehavior</command> to 1. We would prefer that -third party content continue to function , but we believe the requirement for +third party content continue to function, but we believe the requirement for unlinkability trumps that desire. </para>

1 0

[tor-browser-spec/master] Add intro to implementation section.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit b405554d5a3987a679cc68aaa62156201da6d2f1 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Oct 18 21:38:32 2011 -0700 Add intro to implementation section. Also add some hyperlinks. --- docs/design/design.xml | 53 ++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 44 insertions(+), 9 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 000ad35..221d707 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>Oct 11 2011</pubdate> + <pubdate>Oct 19 2011</pubdate> </articleinfo>  </orderedlist> + </sect2> <sect2 id="privacy"> @@ -443,7 +458,8 @@ to be the entire fully qualified domain name. </para> <orderedlist> - <listitem><command>Cross-Origin Identifier Unlinkability</command> + <listitem><link linkend="identifier-linkability"><command>Cross-Origin +Identifier Unlinkability</command></link> <para> User activity on one url bar origin MUST NOT be linkable to their activity in @@ -456,7 +472,8 @@ functionality SHOULD NOT interfere with federated login in a substantial way. </para> </listitem> - <listitem><command>Cross-Origin Fingerprinting Unlinkability</command> + <listitem><link linkend="fingerprinting-linkability"><command>Cross-Origin +Fingerprinting Unlinkability</command></link> <para> User activity on one url bar origin MUST NOT be linkable to their activity in @@ -465,7 +482,8 @@ linkability from fingerprinting browser behavior. </para> </listitem> - <listitem><command>Long-Term Unlinkability</command> + <listitem><link linkend="new-identity"><command>Long-Term +Unlinkability</command></link> <para> The browser SHOULD provide an obvious, easy way to remove all of its @@ -636,6 +654,23 @@ certain new features (where possible) pending analysis and audit. <sect1 id="Implementation"> <title>Implementation</title> <para> + +The Implementation section is divided into subsections, each of which +corresponds to a <link linkend="DesignRequirements">Design Requirement</link>. +Each subsection is divided into specific web technologies or properties. The +implementation is then described for that property. + + </para> + <para> + +In some cases, the implementation meets the design requirements in a non-ideal +way (for example, by disabling features). In rare cases, there may be no +implementation at all. Both of these cases are denoted by differentiating +between the <command>Design Goal</command> and the <command>Implementation +Status</command> for each property. Corresponding bugs in the <ulink +url="https://trac.torproject.org/projects/tor/report">Tor bug tracker</ulink> +are typically linked for these cases. + </para> <sect2 id="proxy-obedience"> <title>Proxy Obedience</title>

1 0

[tor-browser-spec/master] Clean up some wording.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit 1d808a7da29843f94f2cc83f3406382b0ee6b2f8 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Fri Dec 16 19:19:08 2011 -0800 Clean up some wording. --- docs/design/design.xml | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 23ed31c..d8b62e2 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -350,7 +350,7 @@ linkend="security">Security Requirements</link>, and <link linkend="privacy">Privacy Requirements</link>. Security Requirements are the minimum properties in order for a browser to be able to support Tor and similar privacy proxies safely. Privacy requirements are the set of properties -that cause us to prefer one browser platform over another. +that cause us to prefer one browser over another. </para> <para> @@ -376,8 +376,8 @@ browser distribution. The security requirements are primarily concerned with ensuring the safe use of Tor. Violations in these properties typically result in serious risk for the user in terms of immediate deanonymization and/or observability. With -respect to platform support, security requirements are the minimum properties -in order for Tor to support the use of a web client platform. +respect to browser support, security requirements are the minimum properties +in order for Tor to support the use of a particular browser. </para> @@ -416,11 +416,12 @@ or MUST provide a mechanism for rapid, complete removal of all evidence of the use of the mode. In other words, the browser MUST NOT write or cause the operating system to write <emphasis>any information</emphasis> about the use of private browsing to disk outside of the application's control. The user -must be able to ensure that secure removal of the software is sufficient to +must be able to ensure that secure deletion of the software is sufficient to remove evidence of the use of the software. All exceptions and shortcomings due to operating system behavior MUST be wiped by an uninstaller. However, due to permissions issues with access to swap, implementations MAY choose to leave -it out of scope, and/or leave it to the user to implement encrypted swap. +it out of scope, and/or leave it to the Operating System/platform to implement +ephemeral-keyed encrypted swap. </para></listitem> @@ -441,8 +442,8 @@ Safety</command></link> The privacy requirements are primarily concerned with reducing linkability: the ability for a user's activity on one site to be linked with their activity on another site without their knowledge or explicit consent. With respect to -platform support, privacy requirements are the set of properties that cause us -to prefer one platform over another. +browser support, privacy requirements are the set of properties that cause us +to prefer one browser over another. </para> @@ -467,7 +468,7 @@ any other url bar origin by any third party automatically or without user interaction or approval. This requirement specifically applies to linkability from stored browser identifiers, authentication tokens, and shared state. The requirement does not apply to linkable information the user manually submits -to sites, or due information submitted during manual link traversal. This +to sites, or due to information submitted during manual link traversal. This functionality SHOULD NOT interfere with federated login in a substantial way. </para> @@ -566,7 +567,7 @@ failure of Torbutton</ulink> was (and still is) the options panel. Each option that detectably alters browser behavior can be used as a fingerprinting tool. Similarly, all extensions <ulink url="http://blog.chromium.org/2010/06/extensions-in-incognito.html">SHOULD be -disabled in the mode</ulink> except as an opt-in basis. We should not load +disabled in the mode</ulink> except as an opt-in basis. We SHOULD NOT load system-wide addons or plugins. </para> @@ -591,7 +592,8 @@ permissions can be written to disk. Otherwise, they should remain memory-only. Filter-based addons such as <ulink url="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/">AdBlock -Plus</ulink>, <ulink url="">Request Policy</ulink>, <ulink +Plus</ulink>, <ulink url="http://requestpolicy.com/">Request Policy</ulink>, +<ulink url="http://www.ghostery.com/about">Ghostery</ulink>, <ulink url="http://priv3.icsi.berkeley.edu/">Priv3</ulink>, and <ulink url="http://sharemenot.cs.washington.edu/">Sharemenot</ulink> are to be avoided. We believe that these addons do not add any real privacy to a proper @@ -601,8 +603,8 @@ prevented from tracking users between sites by the implementation. Filter-based addons can also introduce strange breakage and cause usability nightmares, and will also fail to do their job if an adversary simply registers a new domain or creates a new url path. Worse still, the unique -filter sets that each user creates or installs will provide a wealth -of fingerprinting targets. +filter sets that each user creates or installs will provide a wealth of +fingerprinting targets. </para> <para> @@ -624,7 +626,7 @@ so is not recommended, as it will alter the browser request fingerprint. We believe that if we do not stay current with the support of new web technologies, we cannot hope to substantially influence or be involved in their proper deployment or privacy realization. However, we will likely disable -certain new features (where possible) pending analysis and audit. +high-risk features pending analysis, audit, and mitigation. </para> </listitem> </orderedlist>

1 0

[tor-browser-spec/master] List what proxy tests we've done.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit fd9148c88fd1756f71133d4cb243a48f15a3808b Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Oct 11 15:06:24 2011 -0700 List what proxy tests we've done. --- docs/design/design.xml | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 6782dc9..000ad35 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>Oct 7 2011</pubdate> + <pubdate>Oct 11 2011</pubdate> </articleinfo> <!-- @@ -651,6 +651,26 @@ SOCKS proxy. It sets <command>network.proxy.socks_remote_dns</command>, <command>network.proxy.socks_version</command>, and <command>network.proxy.socks_port</command>. </para> + <para> + +We have verified that these settings properly proxy HTTPS, OCSP, HTTP, FTP, +gopher (now defunct), DNS, SafeBrowsing Queries, all javascript activity, +including HTML5 audio and video objects, addon updates, wifi geolocation +queries, searchbox queries, XPCOM addon HTTPS/HTTP activity, 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. + + </para> + <para> + +Numerous other third parties have also reviewed and <link +linkend="SingleStateTesting">tested</link> the proxy settings +and have provided test cases based on their work. See in particular <ulink +url="http://decloak.net/">decloak.net</ulink>. + + </para> </listitem> <listitem>Disabling plugins

1 0

[tor-browser-spec/master] Redirects really should not be allowed to store identifiers.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit e0cd4019b2bc971b4d7564d11341a3edf6ef6b7b Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Fri Dec 16 19:35:04 2011 -0800 Redirects really should not be allowed to store identifiers. Not that it really matters at this point. Detecting redirects is a nightmare.. --- docs/design/design.xml | 35 +++++++++-------------------------- 1 file changed, 9 insertions(+), 26 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index d8b62e2..f034fb5 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -1038,39 +1038,22 @@ from the last packet read on the connection) using the Firefox preference </para> </listitem> - <listitem>User confirmation for cross-origin redirects + <listitem>Automated cross-origin redirects MUST NOT store identifiers <para><command>Design Goal:</command> To prevent attacks aimed at subverting the Cross-Origin Identifier Unlinkability <link linkend="privacy">privacy requirement</link>, the browser -MUST prompt the user before following redirects that would cause the user to -automatically navigate between two different url bar origins. The prompt -SHOULD inform the user about the ability to use <link -linkend="new-identity">New Identity</link> to clear the linked identifiers -created by the redirect. - -</para> -XXX: Should redirects be allowed to set cookies? The *redirecting* domain -probably shouldn't, but the destination domain should. -<para> - -To reduce the occurrence of warning fatigue, these warning messages MAY be limited -to automated redirect cycles only. For example, the automated redirect -sequence <command>User Click -> t.co -> bit.ly -> cnn.com</command> can be -assumed to be benign, but the redirect sequence <command>User Click -> t.co -> -bit.ly -> cnn.com -> 2o7.net -> scorecardresearch.net -> cnn.com</command> is -clearly due to tracking. Non-automated redirect cycles that require -user input at some step (such as federated login systems) need not be -interrupted by the UI, and SHOULD still allow identifiers to persist. +MUST NOT store any identifiers (cookies, cache, DOM storage, HTTP auth, etc) +for cross-origin redirect intermediaries that do not prompt for user input. +For example, if a user clicks on a bit.ly url that redirects to a +doubleclick.net url that finally redirects to a cnn.com url, only cookies from +cnn.com should be retained after the redirect chain completes. </para> - <para> + <para> -We are not concerned with linkability due to explicit user action (either by -accepting cross-origin redirects, or by clicking normal links) because it is -assumed that private browsing sessions will be relatively short-lived, -especially with frequent use of the <link linkend="new-identity">New -Identity</link> button. +Non-automated redirect chains that require user input at some step (such as +federated login systems) SHOULD still allow identifiers to persist. </para> <para><command>Implementation status:</command>

1 0

[tor-browser-spec/master] Update design doc for latest Torbutton and TBB patches.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit 8fea738ab4a2049ee5b9260c716905c350183155 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Fri Dec 16 18:42:26 2011 -0800 Update design doc for latest Torbutton and TBB patches. Also address some comments from StrangeCharm and Georg Koppen. --- docs/design/design.xml | 89 +++++++++++++++++++++++++++--------------------- 1 file changed, 51 insertions(+), 38 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 7a819c2..23ed31c 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>Oct 19 2011</pubdate> + <pubdate>Dec 16 2011</pubdate> </articleinfo>  +Additionally, due primarily to an issue with Ubuntu Unity, url-based drag and drop is +filtered by this component. Unity was pre-fetching URLs without using the +browser's proxy settings during a drag action, even if the drop was ultimately +canceled by the user. </para> </listitem> </orderedlist> @@ -995,33 +1000,39 @@ settings manager</ulink>. We are currently <ulink url="https://trac.torproject.org/projects/tor/ticket/3974">having difficulties</ulink> causing Flash player to use this settings -file on Windows. +file on Windows, so Flash remains difficult to enable. </para> </listitem> - <listitem>TLS session resumption and HTTP Keep-Alive - <para> -TLS session resumption and HTTP Keep-Alive MUST NOT allow third party origins -to track users via either TLS session IDs, or the fact that different requests -arrive on the same TCP connection. - </para> + <listitem>SSL+TLS session resumption and HTTP Keep-Alive <para><command>Design Goal:</command> -TLS session resumption IDs MUST be limited to the url bar origin. -HTTP Keep-Alive connections from a third party in one url bar origin MUST -NOT be reused for that same third party in another url bar origin. +TLS session resumption tickets and SSL Session IDs MUST be limited to the url +bar origin. HTTP Keep-Alive connections from a third party in one url bar +origin MUST NOT be reused for that same third party in another url bar origin. </para> <para><command>Implementation Status:</command> -We currently clear TLS Session IDs upon <link linkend="new-identity">New -Identity</link>, but we have no origin restriction implementation as of yet. -We plan to <ulink -url="https://trac.torproject.org/projects/tor/ticket/4099">disable TLS session -resumption</ulink>, and limit HTTP Keep-alive duration as stopgaps to limit -linkability until we can implement <ulink -url="https://trac.torproject.org/projects/tor/ticket/4100">true origin -isolation</ulink> (the latter we feel will be fairly tricky). +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 +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 +False Start</ulink> via the Firefox Pref +<command>security.ssl.enable_false_start</command>. + </para> + <para> + +Becuase 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 +from the last packet read on the connection) using the Firefox preference +<command>network.http.keep-alive.timeout</command>. </para> </listitem> @@ -1034,9 +1045,11 @@ MUST prompt the user before following redirects that would cause the user to automatically navigate between two different url bar origins. The prompt SHOULD inform the user about the ability to use <link linkend="new-identity">New Identity</link> to clear the linked identifiers -created by the redirect. +created by the redirect. </para> +XXX: Should redirects be allowed to set cookies? The *redirecting* domain +probably shouldn't, but the destination domain should. <para> To reduce the occurrence of warning fatigue, these warning messages MAY be limited @@ -1046,7 +1059,7 @@ assumed to be benign, but the redirect sequence <command>User Click -> t.co -> bit.ly -> cnn.com -> 2o7.net -> scorecardresearch.net -> cnn.com</command> is clearly due to tracking. Non-automated redirect cycles that require user input at some step (such as federated login systems) need not be -interrupted by the UI. +interrupted by the UI, and SHOULD still allow identifiers to persist. </para> <para> @@ -1426,26 +1439,26 @@ All linkable identifiers and browser state MUST be cleared by this feature. <title>Implementation Status:</title> <blockquote> - First, Torbutton disables all open tabs and windows via nsIContentPolicy -blocking, 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, and the last opened URL field (via the pref -general.open_location.last_url). After clearing the browser state, we then +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. </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. + </blockquote> </sect3> - - </sect2> <sect2 id="click-to-play"> <title>Click-to-play for plugins and invasive content</title>

1 0

[tor-browser-spec/master] Describe new Firefox patches and update links.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit 122128797f57ee3d77dda4e6ebcca0645a079d30 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Fri Dec 16 20:40:26 2011 -0800 Describe new Firefox patches and update links. --- docs/design/design.xml | 50 +++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 41 insertions(+), 9 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index f034fb5..27c8769 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -727,7 +727,7 @@ supported mime types for all currently installed plugins. <para> In addition, to prevent any unproxied activity by plugins at load time, we also patch the Firefox source code to <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…">prevent the load of any plugins except +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">prevent the load of any plugins except for Flash and Gnash</ulink>. </para> @@ -806,13 +806,13 @@ 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/refs/heads/maint-2.2:/src…">prevent +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/refs/heads/maint-2.2:/src…">prevent +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">prevent intermediate SSL certificates from being recorded</ulink>, and <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…">prevent +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 @@ -930,7 +930,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/refs/heads/maint-2.2:/src…">patch +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/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. @@ -967,7 +967,7 @@ url="https://developer.mozilla.org/en/Setting_HTTP_request_headers#Observers">ht 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/refs/heads/maint-2.2:/src…">patch +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. @@ -1263,7 +1263,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/refs/heads/maint-2.2:/src…">remove +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/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> @@ -1464,8 +1464,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/refs/heads/maint-2.2:/src…">current-patches -directory of the torbrowser git repository</ulink>. They are: +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: </para> <orderedlist> <listitem>Block Components.interfaces and Components.lookupMethod @@ -1566,6 +1565,39 @@ 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 + <para> + +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 +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. + + </para> + </listitem> + <listitem>Disable SSL Session ID tracking + <para> + +This patch is a simple 1-line hack to prevent SSL connections from caching +(and then later transmitting) their Session IDs. There was no preference to +govern this behavior, so we had to hack it by altering the SSL new connection +defaults. + + </para> + </listitem> + <listitem>Provide an observer event to close persistent connections + <para> + +This patch creates an observer event in the HTTP connection manager to close +all keep-alive connections that still happen to be open. This event is emitted +by the <link linkend="new-identity">New Identity</link> button. + + </para> + </listitem> + </orderedlist> </sect2>

1 0

[tor-browser-spec/master] Correct a 2119 usage.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit 2c429a540ffde740fd7da4ce608b2ba4a8eff982 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Fri Oct 21 13:41:43 2011 -0700 Correct a 2119 usage. --- docs/design/design.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 221d707..7a819c2 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -1008,8 +1008,8 @@ arrive on the same TCP connection. <para><command>Design Goal:</command> TLS session resumption IDs MUST be limited to the url bar origin. -HTTP Keep-Alive connections from a third party in one url bar origin must -not be reused for that same third party in another url bar origin. +HTTP Keep-Alive connections from a third party in one url bar origin MUST +NOT be reused for that same third party in another url bar origin. </para> <para><command>Implementation Status:</command>

1 0

[tor-browser-spec/master] Describe CSS media query implementaion.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit fd12608603192797112c9956c2fad14744577063 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Wed Dec 28 22:08:21 2011 -0600 Describe CSS media query implementaion. --- docs/design/design.xml | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 27c8769..0a5df12 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -1296,11 +1296,18 @@ 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>. However, CSS Media Queries -still <ulink url="https://trac.torproject.org/projects/tor/ticket/2875">need -to be dealt with</ulink>. +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.  </para> + <para> + +As far as we know, this fully satisfies our design goals for desktop +resolution information. + + </para> + </listitem> <listitem>Timezone and clock offset <para><command>Design Goal:</command>

1 0

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

28 Apr '14

commit 43a53f7cdbf1523c919fd8f581482627c9fad38c Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Wed Dec 28 22:22:08 2011 -0600 Bump 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 df15dbe..3677816 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 16 2011</pubdate> + <pubdate>Dec 28 2011</pubdate> </articleinfo> <!--

1 0