[tor-commits] r24680: {projects} finish light mucking. still 5 pages. i suggest a complete re (projects/articles/browser-privacy)

Wed Apr 27 01:30:49 UTC 2011

Author: arma
Date: 2011-04-27 01:30:49 +0000 (Wed, 27 Apr 2011)
New Revision: 24680

Modified:
   projects/articles/browser-privacy/W3CIdentity.tex
Log:
finish light mucking. still 5 pages.

i suggest a complete rewrite, first by picking several key points
you want to communicate, and then putting those points in the abstract,
and then expanding on them.

(topics you plan to talk about in the paper do not count as points.)


Modified: projects/articles/browser-privacy/W3CIdentity.tex
===================================================================

--- projects/articles/browser-privacy/W3CIdentity.tex	2011-04-27 01:08:34 UTC (rev 24679)
+++ projects/articles/browser-privacy/W3CIdentity.tex	2011-04-27 01:30:49 UTC (rev 24680)
@@ -97,11 +97,9 @@
 two major sources of disconnect\footnotemark. The first direction is improving
 the linkability issues inherent with the multi-origin model of the web itself.
 The second direction is improving user cues and browser interface to suggest a
-coherent concept of identity to the user by accurately reflecting the
+coherent concept of identity to users by accurately reflecting the
 set of unique identifiers they have accumulated. Both of these directions can
 be pursued independently.
-% "the user" is not the thing that "accurately reflects". 'which' is a
-% klunky term here. -RD
 
 \footnotetext{We only consider implementations that involve privacy-by-design.
 Privacy-by-policy approaches such as Do Not Track will not be discussed.}
@@ -142,7 +140,7 @@
 pages. The default experience is such that all of this data exchange is
 concealed from the user.
 
-So then what comprises the user's web identity for tracking purposes? In terms
+So then what comprises a user's web identity for tracking purposes? In terms
 of authentication, it would at first appear to be limited to cookies, HTTP
 Auth tokens, and client TLS certificates. However, this identifier-based
 approach breaks down quickly on the modern web. High-security websites are
@@ -151,15 +149,14 @@
 utilize everything they can to build complete portraits of users'
 identities~\cite{tracking-identity}.
 
-Despite what the user may believe, their actual web identity then is a
+Despite what the user may believe, her actual web identity then is a
 superset of all the stored identifiers and authentication tokens used by the
-browser. It is the ability to link a user's activity in one instance to their
+browser. This identity can link a user's activity in one instance to her
 activity in another instance, be it across time, or even on the very same page
 due to multiple content origins.
-% 'It'? Their web identity is the ability to link...? -RD
 
-Therefore, instead of viewing the user's identity as the sum of their
-identifiers, or as their relationship to individual websites, it is best to
+Therefore, instead of viewing the user's identity as the sum of her
+identifiers, or as her relationship to individual websites, it is best to
 view it as the ability to link activity from one website to activity in
 another website. We will call this property ``user linkability''.
 
@@ -231,12 +228,12 @@
 %It is apparent that
 Users experience disconnects with the technical
 realities of the web on two major fronts: the average user does not grasp the
-privacy implications of the multi-origin model, nor are they given a clear
+privacy implications of the multi-origin model, nor is she given a clear
 concept of browser identity to grasp the privacy implications of the union
-of the linkable components of their browsers.
+of the linkable components of her browser.
 
 We will now examine examples of attempts at reducing this disconnect on each
-of these two fronts. Note that these to fronts are orthogonal. Approaches from
+of these two fronts. Note that these two fronts are orthogonal. Approaches from
 them may be combined, or used independently.
 
 \subsection{Improving the Origin Model}
@@ -260,7 +257,8 @@
 cache to the top-level origin in the URL bar. Commonly sourced content
 elements are then fetched and cached repeatedly, but this
 is necessary to prevent linkability: each of these content elements can be
-crafted to include an identifier unique to each user, thus tracking users who
+crafted to include an identifier unique to each user, thus tracking even
+users who
 attempt to avoid tracking by clearing normal cookies.
 
 The Mozilla development wiki describes an origin model improvement for
@@ -285,7 +283,7 @@
 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 their privacy info panel.
+removing its favicon from her privacy info panel.
 
 The problem with origin model improvement approaches is that individually,
 they do not fully address the linkability problem unless the same
@@ -304,15 +302,16 @@
 So, while these approaches are in fact useful for bringing the technical
 realities of the web closer to what the user assumes is happening, they must
 be deployed uniformly, with a consistent top-level origin restriction model.
-This may take significant coordination and standardization efforts. Without
-this, it is necessary to fill the remaining linkability gaps by presenting
-the user with a visual representation of their overall web identity.
+Uniform deployment will take significant coordination and standardization
+efforts. Until then,
+it is necessary to fill the remaining linkability gaps by presenting
+the user with a visual representation of her overall web identity.
 
 \subsection{Conveying Identity to the User}
 
 Even if the origin model of identifier transmission and other linkable
-attributes is altered uniformly to be more in line with what users expect, it
-is likely that the average user will still experience privacy benefits if the
+attributes is altered uniformly to be more in line with what users expect,
+the average user can still experience privacy benefits if the
 browser conveys the sum of all linkable information as a single storable,
 mutable, and clearable user identity.
 %
@@ -346,21 +345,24 @@
 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. The Tor Project is heading in
-this direction with the Tor Browser Bundle~\cite{not-to-toggle}.
+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}.
 
-However, all current private browsing modes fall short of protecting against a
+Unfortunately, all current private browsing modes fall short of protecting
+against a
 network-level adversary and fail to deal with linkability against such an
 adversary~\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, this approach has
 failed as a privacy measure.
 % XXXX Define network-level adversary.
+% I agree. You could do that here or in the footnote. -RD
 
 \footnotetext{The primary reason given to abstain from addressing a
 network-level
@@ -382,16 +384,15 @@
 associated with altering browser behavior have lulled us into accepting user
 deception as the norm for web use. The average user completely lacks the
 understanding needed to grasp how web tracking is carried out. This disconnect
-%in understanding
-is extreme to the point where moral issues arise about the
+is so extreme that it raises moral issues about the
 level of consent actually involved in web use and associated tracking.
 
 In fact, standardization efforts seemed to realize this problem early on but
-failed to create a feasible recommendations for improving the situation. RFC
-2965 governing HTTP State Management mandated in section 3.3.6 that
+failed to create feasible recommendations for improving the situation.
+RFC~2965 governing HTTP State Management mandated in Section~3.3.6 that
 third-party origins must not cause the browser to transmit cookies unless the
 interaction is ``verifiable'' and readily apparent to the user~\cite{rfc2965}.
-In section 6, it also strongly suggested that informed consent and user
+In Section~6, it also strongly suggested that informed consent and user
 control should govern the interaction of users to tracking identifiers.
 
 Without changes to browser behavior, browser interface, or both, such informed
@@ -400,6 +401,7 @@
 the linkability issues with the web's origin model with minimal breakage.
 Additionally, the first steps towards providing the user with an explicit
 representation of their web identity have been taken.
+% Taken by who? Change to active tense. -RD
 
 The pieces are in place to build robust private browsing modes based on these
 two approaches, and metrics exist to measure their success.

