Author: mikeperry Date: 2011-04-27 06:57:24 +0000 (Wed, 27 Apr 2011) New Revision: 24684
Modified: projects/articles/browser-privacy/W3CIdentity.bib projects/articles/browser-privacy/W3CIdentity.tex Log: Minor tweaks.
Modified: projects/articles/browser-privacy/W3CIdentity.bib =================================================================== --- projects/articles/browser-privacy/W3CIdentity.bib 2011-04-27 06:11:22 UTC (rev 24683) +++ projects/articles/browser-privacy/W3CIdentity.bib 2011-04-27 06:57:24 UTC (rev 24684) @@ -85,9 +85,9 @@ }
@Misc{not-to-toggle, - title = {To Toggle, or not to Toggle: The End of Torbutton}, - author={Mike Perry}, - note = {\url{https://lists.torproject.org/pipermail/tor-talk/2011-April/020077.html%7D%7D + title = {To Toggle, or not to Toggle: The End of Torbutton}, + author={Mike Perry}, + note = {\url{https://lists.torproject.org/pipermail/tor-talk/2011-April/020077.html%7D%7D }
@Misc{firefox-personas,
Modified: projects/articles/browser-privacy/W3CIdentity.tex =================================================================== --- projects/articles/browser-privacy/W3CIdentity.tex 2011-04-27 06:11:22 UTC (rev 24683) +++ projects/articles/browser-privacy/W3CIdentity.tex 2011-04-27 06:57:24 UTC (rev 24684) @@ -72,17 +72,16 @@ web actually functions with respect to user tracking.
To this end, the rest of this document is structured as follows: First, we -examine how users perceive their privacy on the web, comparing the average -user's perspective to what actually is happening technically behind the -scenes, and noting the major disconnects. We then examine solutions that -bridge this disconnect from two different directions, corresponding to the two -major sources of disconnect\footnotemark. The first direction is improving -user cues and browser interface to suggest a coherent concept of identity to -users by accurately reflecting the set of unique identifiers they have -accumulated. The second direction is improving the linkability issues -inherent with the multi-origin model of the web itself. Both of these -directions must be pursued to provide users with the ability to properly use -the web in a privacy-preserving way. +compare the average user's understanding of web tracking to what actually is +happening technically behind the scenes, and note the major disconnects. We +then examine solutions that bridge this disconnect from two different +directions, corresponding to the two major sources of disconnect\footnotemark. +The first direction is improving user cues and browser interface to suggest a +coherent concept of identity to users by accurately reflecting the set of +unique identifiers they have accumulated. The second direction is improving +the linkability issues inherent in the multi-origin model of the web itself. +Both of these directions must be pursued to provide users with the ability to +properly use the web in a privacy-preserving way.
\footnotetext{We only consider implementations that involve privacy-by-design. Privacy-by-policy approaches such as Do Not Track will not be discussed.} @@ -159,17 +158,15 @@ when it comes to user identity and private browsing, but they are not the whole story.
-Next, we have long-term properties of the browser itself. These include the -User Agent string, the list of installed plugins, rendering capabilities, -window decoration size, and browser widget size. - -Then, we have properties of the computer. These include desktop size, IP +Next, we have long-term properties of the browser and the computer. These +include the User Agent string, the list of installed plugins, rendering +capabilities, window decoration size, browser widget size, desktop size, IP address, clock offset and timezone, and installed fonts.
Finally, linkability also includes the properties of the multi-origin model of -the web that allow tracking due to partnerships. These include the implicit -cookie transmission model, and also explicit click referral and data exchange -partnerships. +the web that allow tracking due to partnerships and ubiquitous third-party +content elements. These include the implicit cookie transmission model, and +also explicit click referral and data exchange partnerships.
\subsection{Developing a Threat Model}
@@ -208,7 +205,7 @@ For users to have privacy, and for private browsing modes to function, the relationship between a user and a site must be understood by that user.
-Users experience disconnects with the technical realities of the web on two +Users experience disconnect with the technical realities of the web on two major fronts: the average user is not given a clear concept of browser identity to grasp the privacy implications of the union of the linkable components of her browser, nor does she grasp the privacy implications of the @@ -221,26 +218,26 @@ \subsection{Conveying Identity to the User}
The first major disconnect that prevents users from achieving true -privacy-by-design is that the user interface of most browsers does not provide -any clearly visible cues to the user to indicate that their current set of -accumulated linkable state comprise a single, trackable web identity. +privacy-by-design is that most browsers do not provide any cues to the user to +indicate that their current set of accumulated linkable state comprise a +single, trackable web identity that can be changed or cleared.
We believe that the user interface of the browser should convey a sense of persistent identity prominently to the user in the form of a visual cue. This cue can either be an abstract image, graphic or theme (such as the user's choice of Firefox Persona~\cite{firefox-personas}), or it can be a text area -with the user's current favored pseudonym. This idea of identity should then -be integrated with the browsing experience. Users should be able to click a +with the user's current pseudonym. This idea of identity should then be +integrated with the browsing experience. Users should be able to click a button to get a clean slate for a new identity, and should be able to log into -and out of password-protected stored identities, which would -contain the entire state of the browser. +and out of password-protected stored identities, which would contain the +entire state of the browser.
To this user, the Private Browsing Mode would be no more than a special case of this identity UI---a special identity that they can trust not to store browsing history information to disk. Such a UI also more explicitly captures what is going on with respect to the user's relationship to the web. -The Tor Project is heading in this direction with the Tor Browser -Bundle~\cite{not-to-toggle}. +%The Tor Project is heading in this direction with the Tor Browser +%Bundle~\cite{not-to-toggle}.
Of the major private browsing modes, Google Chrome's Incognito Mode comes the closest to conveying this idea of ``identity'' to the user, and its @@ -262,10 +259,10 @@ Unfortunately, all current private browsing modes protect only against adversaries with access to the local computer and fail to deal with linkability against network adversaries (such as advertising -networks)~\cite{private-browsing}, claiming that it is outside their threat -model\footnotemark. If the user is given a new identity that is still linkable -to the previous one due to shortcomings of the browser, the approach has -failed as a privacy measure. +networks)~\cite{private-browsing}, claiming that the latter is outside their +threat model\footnotemark. If the user is given a new identity that is still +linkable to the previous one due to shortcomings of the browser, the approach +has failed as a privacy measure.
\footnotetext{The primary reason given to abstain from addressing a network adversary is IP-address linkability. However, we believe this argument to be a red @@ -311,7 +308,7 @@ to make linkability less implicit and more consent-driven without the need for cumbersome interventionist user interface, and with minimal damage to existing content. Where explicit identifiers exist, they should be tied to the pair of -the top-level origin and the third-party content origin. Where linkability +the top-level origin and the third-party element origin. Where linkability attributes exist, they can be obfuscated on a per-origin basis.
The work done by the Stanford Applied Crypto Group shows that it is relatively @@ -338,7 +335,7 @@ would only be transmitted if they match both the top-level origin and the third-party origin involved in their creation. Dan observed minimal breakage to popular sites, and where breakage did occur, alternative approaches that -did not violate the new model were readily available to web designers and +do not violate the new model were readily available to web designers and often already in use.
Similarly, this two-level dual-keyed origin isolation can be deployed to @@ -352,11 +349,11 @@ intuitive control over site identifiers, and thus with more control over their actual relationship to particular sites. For example, the privacy settings window could have a user-intuitive way of representing the user's relationship -with different origins, perhaps by using only the `favicon' of that top level -origin to represent all of the browser state accumulated by that origin. The -user could delete the entire set of browser state (cookies, cache, storage, -cryptographic tokens) associated with a site simply by removing its favicon -from her privacy info panel. +with different top-level origins, perhaps by using only the `favicon' of that +top-level origin to represent all of the browser state accumulated by that +origin. The user could delete the entire set of browser state (cookies, cache, +storage, cryptographic tokens) associated with a site simply by removing its +favicon from her privacy info panel.
Linkability based on fingerprintable browser properties is also amenable to improvement under this model. In particular, one can imagine per-origin plugin