[tor-commits] r24684: {projects} Minor tweaks. (projects/articles/browser-privacy)

Wed Apr 27 06:57:24 UTC 2011

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}}
+   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}}
 }
 
 @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

