[tor-commits] r24747: {projects} Add a sentence to the conclusion, tighten some other languag (projects/articles/browser-privacy)

[Mike Perry <mikeperry-svn@xxxxxxxxxx>]

Author: mikeperry
Date: 2011-05-13 20:47:03 +0000 (Fri, 13 May 2011)
New Revision: 24747

Modified:
   projects/articles/browser-privacy/W3CIdentity.tex
Log:
Add a sentence to the conclusion, tighten some other language for space.



Modified: projects/articles/browser-privacy/W3CIdentity.tex
===================================================================
--- projects/articles/browser-privacy/W3CIdentity.tex	2011-05-13 16:10:10 UTC (rev 24746)
+++ projects/articles/browser-privacy/W3CIdentity.tex	2011-05-13 20:47:03 UTC (rev 24747)
@@ -83,7 +83,7 @@
 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.
+\footnotetext{We only consider privacy-by-design approaches.
 Privacy-by-policy approaches such as Do Not Track will not be discussed.}
 
 \section{User Privacy on the Web}
@@ -122,13 +122,12 @@
 pages. The default experience is such that all of this data exchange is
 concealed from the user.
 
-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
-already using fingerprinting as an auxiliary second factor of
-authentication~\cite{security-fingerprinting}, and online data aggregators
-utilize everything they can to build complete portraits of users'
+So then what comprises a user's web identity for tracking purposes? At first
+glance, it appears 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 already using fingerprinting as a
+second factor of authentication~\cite{security-fingerprinting}, and data
+aggregators utilize everything they can to build complete portraits of users'
 identities~\cite{tracking-identity}.
 
 Despite what the user may believe, her actual web identity then is a superset
@@ -150,7 +149,7 @@
 
 When privacy is expanded to cover all items that enable or substantially
 contribute to linkability, a lot more components of the browser are now in
-scope. We will briefly enumerate these four categories of components.
+scope. We will briefly enumerate these categories of components.
 
 First, the obvious properties are found in the state of the browser: cookies,
 DOM storage, cache, cryptographic tokens and cryptographic state, and
@@ -182,23 +181,21 @@
 distribution of each of several key attributes to determine how many bits of
 identifying information each attribute provided.
 
-While not perfect\footnotemark, this metric allows us to prioritize our efforts
-on the
-components that have the most potential for linkability.
+While not perfect\footnotemark, this metric allows us to prioritize our
+efforts on the components that have the most potential for linkability.
 %
-\footnotetext{In particular, the test does not take in all aspects of
+\footnotetext{In particular, Panopticlick did not measure all aspects of
 resolution information. It did not calculate the size of widgets, window
 decoration, or toolbar size. We believe these resolution-related properties
-may add high amounts of entropy to the resolution component. They also did not
+may add high amounts of entropy to the resolution component. It also did not
 measure clock offset and other time-based fingerprints. Furthermore, as new
-browser features are added, the experiment should be repeated to include
+browser features are added, the experiment should be repeated to measure
 them.}
 %
-It also shows the benefits of standardizing on
-implementations of fingerprinting resistance where possible. More
-implementations using the same defenses means more users with similar
-fingerprints, which means less entropy in the metric. Similarly, uniform
-feature deployment leads to less entropy.
+It also shows the benefits of standardizing on implementations of
+fingerprinting resistance where possible. More implementations using the same
+defenses means more users with similar fingerprints, which means less entropy
+in the metric. Similarly, uniform feature deployment leads to less entropy.
 
 \section{Matching User Perception with Reality}
 
@@ -222,15 +219,14 @@
 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 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.
+We believe that the browser UI should convey a sense of persistent identity
+prominently to the user in the form of a visual cue. This cue can either be an
+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
+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.
 
 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
@@ -351,9 +347,9 @@
 window could have a user-intuitive way of representing the user's relationship
 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.
+origin. The user could delete the entire set of top-level origin state
+(cookies, cache, storage, cryptographic tokens) simply by removing the 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
@@ -364,9 +360,8 @@
 of the web closer to what the user assumes is happening, they must be deployed
 uniformly, with a consistent top-level origin restriction model. Uniform
 deployment will take significant coordination and standardization efforts.
-Furthermore, even a vastly improved origin model cannot prevent
-instances of explicit tracking partnerships between sites and third-party
-content providers. Therefore, both origin improvements and
+Furthermore, even an improved origin model cannot protect against large
+multi-service top-level origins. Therefore, both origin improvements and
 identity-isolation approaches are necessary.
 
 \section{Conclusions}
@@ -378,20 +373,21 @@
 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 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
-control should govern the interaction of users to tracking identifiers.
+In fact, standardization efforts realized this problem early on but 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 control
+should govern the interaction of users to tracking identifiers.
 
 Without changes to both browser behavior and browser interface, informed
 consent is simply not possible on today's web. The lack of informed consent
 makes it impossible to expect privacy-by-design approaches to function
 properly. We cannot expect users who do not even understand the basic
-properties of these tracking mechanisms to effectively
-use privacy mechanisms to avoid, opt out of, or decline such tracking.
+properties of these tracking mechanisms to effectively use privacy mechanisms
+to avoid, opt out of, or decline such tracking. Therefore, browser inteface
+and behavior must be brought in line with user expectations.
 
 \bibliographystyle{plain} \bibliography{W3CIdentity}
 

_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits