Full spell check.

     <address><email>sjmurdoch#torproject org</email></address>

    </affiliation>

   </author>

   <pubdate>April 30th, 2015</pubdate>

   <pubdate>May 5th, 2015</pubdate>

 </articleinfo>

<sect1>

For the purposes of the unlinkability requirements of this section as well as

the descriptions in the <link linkend="Implementation">implementation

section</link>, a <command>url bar origin</command> means at least the

section</link>, a <command>URL bar origin</command> means at least the

second-level DNS name.  For example, for mail.google.com, the origin would be

google.com. Implementations MAY, at their option, restrict the url bar origin

google.com. Implementations MAY, at their option, restrict the URL bar origin

to be the entire fully qualified domain name.

   </para>

Identifier Unlinkability</command></link> 

  <para>

User activity on one url bar origin MUST NOT be linkable to their activity in

any other url bar origin by any third party automatically or without user

User activity on one URL bar origin MUST NOT be linkable to their activity in

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

Fingerprinting Unlinkability</command></link> 

  <para>

User activity on one url bar origin MUST NOT be linkable to their activity in

any other url bar origin by any third party. This property specifically applies to

User activity on one URL bar origin MUST NOT be linkable to their activity in

any other URL bar origin by any third party. This property specifically applies to

linkability from fingerprinting browser behavior.

  </para>

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 agent allows the user to craft an exemption to allow

a plugin to be used automatically, it must only apply to the top level url bar

a plugin to be used automatically, it must only apply to the top level URL bar

domain, and not to all sites, to reduce cross-origin fingerprinting

linkability.

Instead of global browser privacy options, privacy decisions should be made

<ulink

url="https://wiki.mozilla.org/Privacy/Features/Site-based_data_management_UI">per

url bar origin</ulink> to eliminate the possibility of linkability

URL bar origin</ulink> to eliminate the possibility of linkability

between domains. For example, when a plugin object (or a Javascript access of

window.plugins) is present in a page, the user should be given the choice of

allowing that plugin object for that url bar origin only. The same

allowing that plugin object for that URL bar origin only. The same

goes for exemptions to third party cookie policy, geolocation, and any other

privacy permissions.

     </para>

     <para>

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

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.

      </para>

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. Secondary goals may include confirming

on-disk identifiers (such as hostname and disk-logged spoofed MAC adddress

on-disk identifiers (such as hostname and disk-logged spoofed MAC address

history) obtained by other means.

     </para>

We have verified that these settings and patches properly proxy HTTPS, OCSP,

HTTP, FTP, gopher (now defunct), DNS, SafeBrowsing Queries, all JavaScript

activity, including HTML5 audio and video objects, addon updates, wifi

activity, including HTML5 audio and video objects, addon updates, WiFi

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

The benefit of this approach comes not only in the form of reduced

linkability, but also in terms of simplified privacy UI. If all stored browser

state and permissions become associated with the url bar origin, the six or

state and permissions become associated with the URL bar origin, the six or

seven different pieces of privacy UI governing these identifiers and

permissions can become just one piece of UI. For instance, a window that lists

the url bar origin for which browser state exists, possibly with a

the URL bar origin for which browser state exists, possibly with a

context-menu option to drill down into specific types of state or permissions.

An example of this simplification can be seen in Figure 1.

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

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.

    <listitem><command>Cookies</command>

     <para><command>Design Goal:</command>

All cookies MUST be double-keyed to the url bar origin and third-party

All cookies MUST be double-keyed to the URL bar origin and third-party

origin. There exists a <ulink

url="https://bugzilla.mozilla.org/show_bug.cgi?id=565965">Mozilla bug</ulink>

that contains a prototype patch, but it lacks UI, and does not apply to modern

Firefoxes.

Firefox versions.

     </para>

     <para><command>Implementation Status:</command>

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/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&id=d8b98a75fb200268c40886d876adc19e00b933bf">isolate

this cache per url bar domain</ulink>.

this cache per URL bar domain</ulink>.

     </para>

    </listitem>

    <listitem><command>DOM Storage</command>

     <para>

DOM storage for third party domains MUST be isolated to the url bar origin,

DOM storage for third party domains MUST be isolated to the URL bar origin,

to prevent linkability between sites. This functionality is provided through a

<ulink

url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&id=97490c4a90ca1c43374486d9ec0c5593d5fe5720">patch

    <listitem><command>SSL+TLS session resumption</command>

     <para><command>Design Goal:</command>

TLS session resumption tickets and SSL Session IDs MUST be limited to the url

TLS session resumption tickets and SSL Session IDs MUST be limited to the URL

bar origin.

     </para>

Unlinkability <link linkend="privacy">privacy requirement</link>, the browser

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

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>

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.

HTTPS/HTTP schemes, the property is cleared.

     </para>

    </listitem>

There appears to be three options for us: 1. Disable HSTS entirely, and rely

instead on HTTPS-Everywhere to crawl and ship rules for HSTS sites. 2.

Restrict the number of HSTS-enabled third parties allowed per url bar origin.

Restrict the number of HSTS-enabled third parties allowed per URL bar origin.

3. Prevent third parties from storing HSTS rules. We have not yet decided upon

the best approach.

In cases where simple spoofing is not enough to properly conceal underlying

device characteristics or operating system details, the underlying

susbsystem that provides the functionality for a feature or API may need

subsystem that provides the functionality for a feature or API may need

to be completely reimplemented. This is most common in cases where

customizable or version-specific aspects of the user's operating system are

visible through the browser's featureset or APIs, usually because the browser

In the event that virtualization is too expensive in terms of performance or

engineering effort, and the relative expected usage of a feature is rare, site

permissions can be used to prevent the usage of a feature execpt in cases

permissions can be used to prevent the usage of a feature except in cases

where the user actually wishes to use it. Unfortunately, this mechanism

becomes less effective once a feature becomes widely overused and abused by

many websites, as warning fatigue quickly sets in for most users.

information, a fingerprint will appear unstable, but may not actually be

sufficiently randomized to prevent a dedicated adversary.  Sophisticated

fingerprinting mechanisms may either ignore randomized information, or

incorportate knowledge of the distribution and range of randomized values into

incorporate knowledge of the distribution and range of randomized values into

the creation of a more stable fingerprint (by either removing the randomness,

modeling it, or averaging it).

font set is fairly complete by itself, but Nanum and Lohit have smaller

versions of many South Asian languages. When combined in a way that chooses the

smallest font implementations for each locale, these three font sets provide

poverage for the all languages used on Wikipedia with more than

coverage for the all languages used on Wikipedia with more than

10,000 articles, and several others as well, in approximately 3MB of compressed

overhead. The <ulink url="https://www.google.com/get/noto/">Noto font

set</ulink> is another font set that aims for complete coverage, but is

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

vacuum, because many sites have begun encoding Referer URL information into

GET parameters when they need it to cross http to https scheme transitions.

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>