Re: DRAFT TAG feedback for fingerprinting

On May 23, 2015, at 8:16 AM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> On 22 May 2015 at 06:41, Mark Nottingham <mnot@mnot.net <mailto:mnot@mnot.net>> wrote:
> … based on our discussion this week is here:
>   https://github.com/w3ctag/spec-reviews/blob/master/2015/05/fingerprint.md <https://github.com/w3ctag/spec-reviews/blob/master/2015/05/fingerprint.md>
> 
> Feedback / issues / pulls appreciated. Nick, CC:ing FYI, but realise that this isn't final yet.
> 
> "using the technology [is] against the interests of its users"
> 
> This makes a lot of sense, but I was wondering is this always the case?

"always" is a broad term. I think it would be more useful to think about fingerprinting in the way that IETF has described pervasive monitoring in RFC 7258 [0]. The technology is an attack on user privacy, not in the sense of always being done to hurt the individual or to be malicious, but in subverting a functionality and creating a capability that limits user control over their information. In particular, because it's hard to distinguish fingerprinting done for purposes the user would welcome and for purposes the user would object to, we have to address the capability as a whole.

> As an author of client side apps, one thing I constantly find challenging with is customizing a UI, to a user, in a personalized way.  This is useful both for the app and for the users.  For example from a URI for a user, I can pull in their name, their avatar, their friends list, where there personal storage is, recent conversations, and a bunch of other nice things that can show up in the user interface.
> 
> Generally when using an app for the first time, the user will have to type a URI into a form, which identifies themselves, in order to get this personalized user experience.  This is a UX that will lose you the vast majority of your potential user base.
> 
> In an ideal world, browsers would be under the complete control of the user, and the user could allow certain websites or apps, to know who they were.  A slightly easier way to do this is to use localStorage, but this suffers from cross origin constraints.  Another way is to use the identity system built in to X.509 client side certificates, which is not cross origin, but this has traditionally had usability issues.
> 
> What I've been thinking about lately is allowing a user to persist data about who they are, globally, via fingerprinting.  Then they get a uniform user experience across the web in exchange for a slight loss of privacy, which hopefully will be responsibly managed.
> 
> I'd love to know if there is any kind of other solutions for persisting cross origin data about a user (perhaps the upcoming credentials API?).  But if not, I was wondering if maybe fingerprinting could perhaps have some uses for good, e.g. as indirect identifiers, and as a work around to restrictive same origin policies?

The fingerprinting guidance document under review [1] tries to briefly explain the privacy concerns with regard to browser fingerprinting. Of particular relevance to your suggestion would be that fingerprinting typically happens without user awareness, can't easily be turned on/off and can't be "cleared" the way cookies can. A more friendly way of implementing that functionality would be user-controlled cookies or headers that could send preferences across sites, in a way that users are aware of and can control. For example, though I'm not sure it's widely adopted, users can set their language preferences in a header sent to websites, so that the site can customize the language to the user's preferred language on the very first visit. It's a challenge to explain to users in a way where they can get customized advantages without privacy surprises though. For example, browsers have moved away from allowing cookies to be set and accessed by different origins.

—Nick

[0] http://tools.ietf.org/html/rfc7258
[1] https://w3c.github.io/fingerprinting-guidance