Author: arma Date: 2011-04-27 01:08:34 +0000 (Wed, 27 Apr 2011) New Revision: 24679
Modified: projects/articles/browser-privacy/W3CIdentity.tex Log: initial cleanups while reading
also, it's 5 pages again
Modified: projects/articles/browser-privacy/W3CIdentity.tex =================================================================== --- projects/articles/browser-privacy/W3CIdentity.tex 2011-04-26 15:06:46 UTC (rev 24678) +++ projects/articles/browser-privacy/W3CIdentity.tex 2011-04-27 01:08:34 UTC (rev 24679) @@ -31,12 +31,14 @@ There is a huge disconnect between how users perceive their online presence and the reality of their relationship with the websites they visit. This position paper explores this disconnect and provides some recommendations for -making the technical reality of the web match user perception, through both -technical improvements as well as user interface cues. We frame the core -technical problem as one of ``linkability'' -- the level of correlation +making the technical reality of the web match user perception. %, through both +%technical improvements as well as user interface cues. +We frame the core +technical problem as one of ``linkability''---the level of correlation between various online activities that the user naturally expects to be independent. We look to address the issue of unexpected linkability through -both improvements to the web's origin model, as well as through user interface +both technical improvements to the web's origin model, as well as through +user interface cues about the set of accumulated identifiers that can be said to comprise a user's online identity.
@@ -50,11 +52,12 @@ advertisement is relevant to the current activity, and if possible, relevant to the current user.
-The cost of this is that user privacy on the web is a nightmare. There is +The cost of this incentive structure is that user privacy on the web is a +nightmare. There is ubiquitous tracking, unseen partnership agreements and data exchange, and surreptitious attempts to uncover users' identities against their will and without their knowledge. This is not just happening in the dark, unseemly -corners of the web. It is happening everywhere\cite{facebook-like}. +corners of the web. It is happening everywhere~\cite{facebook-like}.
The problem is that the revenue model of the web has incentivized companies to find ways to continue to track users against their will, even if those users @@ -62,9 +65,9 @@ Starting with the infamous ``Flash cookies'', we have progressed through a seemingly endless arms race of secondary identifiers and tracking information: visited history, cache, font and system data, desktop resolution, keystroke -timing, and so on and so forth\cite{wsj-fingerprinting}. +timing, and so on and so forth~\cite{wsj-fingerprinting}.
-These efforts have lead to an even wider disconnect between a user's +These efforts have led to an even wider disconnect between users' perception of their privacy and the reality of their privacy. Users simply can't keep up with the ways they are being tracked.
@@ -87,23 +90,25 @@
To this end, the rest of this document is structured as follows: First, we -examine how the user perceives their privacy on the web, comparing the average +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 attempting -to bridge this disconnect from two different directions, corresponding to 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 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, which more accurately reflects the +coherent concept of identity to the user 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.}
\section{User Privacy on the Web}
-To properly examine the privacy problem, we must probe both the average user's +To properly examine the privacy problem, we must probe both the average users' perception of what their ``web identity'' is, as well as the technical realities of web authentication and tracking.
@@ -111,12 +116,13 @@
Instinctively, users define their privacy in terms of their identity: in terms of how they have interacted with a site in order to inform it of who they are. -Typically, the user's perception of their identity on the web is usually a direct +Typically, the users' perception of their identity on the web is usually a direct function of the identifiers used for strong authentication for particular sites.
For example, users expect that logging in to Facebook creates a relationship in their browsers when facebook.com is present in the URL bar, but they are -typically not aware that this also extends to their activity on other, arbitrary +typically not aware that this relationship also extends to their activity +on other, arbitrary sites that happen to include ``Like this on Facebook'' buttons or Facebook-sourced advertising content.
@@ -141,15 +147,16 @@ 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 +authentication~\cite{security-fingerprinting}, and online data aggregators utilize everything they can to build complete portraits of users' -identities\cite{tracking-identity}. +identities~\cite{tracking-identity}.
Despite what the user may believe, their 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 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 @@ -159,12 +166,12 @@ \subsection{User Privacy as Linkability}
In terms of what the user actually expects, user privacy is more accurately -modeled as the level of linkability between subsequent actions on the web, as -opposed to the mere sum of their unique identifiers and authentication tokens. +modeled as the level of linkability between subsequent actions on the web---not +just the sum of her unique identifiers and authentication tokens.
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 components. +scope. We will briefly enumerate these four 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 @@ -192,7 +199,7 @@ various browser properties that extend beyond any stored origin-related state.
The Panopticlick project by the EFF provides us with exactly this -metric\cite{panopticlick}. The researchers conducted a survey of volunteers +metric~\cite{panopticlick}. The researchers conducted a survey of volunteers who were asked to visit an experiment page that harvested many of the above components. They then computed the Shannon entropy of the resulting distribution of each of several key attributes to determine how many bits of @@ -201,7 +208,7 @@ 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 resolution information. It did not calculate the size of widgets, window decoration, or toolbar size. We believe these resolution-related properties @@ -209,19 +216,20 @@ measure clock offset and other time-based fingerprints. Furthermore, as new browser features are added, the experiment should be repeated to include them.} - -This metric also indicates that it is beneficial to standardize on +% +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 in the metric. +feature deployment leads to less entropy.
\section{Matching User Perception with Reality}
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. - -It is apparent that the user experiences disconnect with the technical +% +%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 concept of browser identity to grasp the privacy implications of the union @@ -236,7 +244,7 @@ The current identifier origin model used by the web is fundamentally flawed when viewed from the perspective of meeting the expectations of the user. Unique, globally linkable identifiers can be transmitted for arbitrary content -elements on any page, which can be sourced from anywhere without user +elements on any page, and they can be sourced from anywhere without user interaction or awareness.
However, the behavior of identifiers and linkable attributes can be improved @@ -246,26 +254,26 @@ content origin. Where linkability attributes exist, they should be obfuscated on a per-origin basis.
-An early relevant example of this idea is SafeCache\cite{safecache}. +An early relevant example of this idea is SafeCache~\cite{safecache}. SafeCache seeks to reduce the ability for third-party content elements to use the cache to store identifiers. It does this by limiting the scope of the -cache to the top-level origin in the URL bar. This has the effect that -commonly sourced content elements are fetched and cached repeatedly, but this +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 attempt to avoid tracking by clearing normal cookies.
The Mozilla development wiki describes an origin model improvement for cookie transmission -written by Dan Witte\cite{thirdparty}. Dan describes a new +written by Dan Witte~\cite{thirdparty}. He describes a new dual-keyed origin for cookies, so that cookies would only be transmitted if -they matched both the top-level origin and the third-party origin involved in +they match both the top-level origin and the third-party origin involved in their creation. This approach would go a long way towards preventing implicit tracking across multiple websites, and has some interesting properties that make user interaction with content elements more explicitly tied to the current site. % XXXX I can't tell what this paragraph is supposed to mean. --RR - +% Similarly, one could imagine this two-level dual-keyed origin isolation being deployed to improve similar issues with DOM Storage and cryptographic tokens.
@@ -292,7 +300,7 @@ amenable to improvement under this model. In particular, one can imagine per-origin plugin loading permissions, per-origin limits on the number of fonts that can be used, and randomized window-specific time offsets. - +% 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. @@ -305,9 +313,9 @@ 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 -browser conveys the sum of all linkable information as a single, storable, +browser conveys the sum of all linkable information as a single storable, mutable, and clearable user identity. - +% Providing this concept of identity to the user is also simpler than origin improvements, as it does not require extensive compatibility testing or standards coordination. @@ -321,34 +329,34 @@ The better UI appears to lead to less mode error (in which the user forgets whether private browsing is enabled) than other browsers' private browsing -modes\cite{private-browsing}. -% XXXX ‘mode error’? +modes~\cite{private-browsing}.
-The Mozilla Weave project appears to be proposing an identity-oriented method +The Mozilla Weave project~\cite{weave-manager} appears to be proposing +an identity-oriented method of managing, syncing, and storing authentication tokens, and also has use -cases described for multiple users of a single browser\cite{weave-manager}. It +cases described for multiple users of a single browser. It is the closest idea on paper to what we envision as the way to bridge user assumptions with reality.
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 +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 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. This is the direction the Tor Project -intends to head in with the Tor Browser Bundle\cite{not-to-toggle}. - +contain the entire state of the browser. The Tor Project is heading in +this direction with the Tor Browser Bundle~\cite{not-to-toggle}. +% 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 +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.
However, 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 +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. @@ -358,10 +366,11 @@ network-level adversary is IP-address linkability. However, we believe this to be a red herring. Users are quite capable of using alternate Internet connections, and -it is common practice for ISPs in many parts of the world to rotate user IP +it is common practice for ISPs (especially cellular IP networks) +%in many parts of the world +to rotate user IP addresses daily, to discourage users from operating servers and to impede the -spread of malware. -This is especially true of cellular IP networks.} +spread of malware.}
Linkability solutions within the identity framework would be similar to the origin model solutions, except they would be properties of the entire browser @@ -369,18 +378,19 @@
\section{Conclusions}
-The appeal of the prevailing revenue model of the web and the difficulties +The appeal of the web's prevailing revenue model and the difficulties 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 +%in understanding +is extreme to the point where moral issues arise 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 third-party origins must not cause the browser to transmit cookies unless the -interaction is ``verifiable'' and readily apparent to the user\cite{rfc2965}. +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.
@@ -396,7 +406,8 @@
\bibliographystyle{plain} \bibliography{W3CIdentity}
-\clearpage -\appendix +%\clearpage +%\appendix
\end{document} +