W3C home > Mailing lists > Public > public-tracking@w3.org > June 2012

Re: Towards a DNT Grand Bargain

From: Jonathan Mayer <jmayer@stanford.edu>
Date: Sun, 10 Jun 2012 23:32:00 -0700
To: Shane Wiley <wileys@yahoo-inc.com>
Cc: "public-tracking@w3.org" <public-tracking@w3.org>
Message-ID: <EA1E5D709D4E44CD97DEAA7EB3E6079E@gmail.com>
Our proposal accommodates non-outsourced third-party business practices in four ways:

1) protocol information,
2) low-entropy cookies (and equivalents),
3) unlinkable datasets, and  
4) statistical inference from non-DNT users.

The impact varies by business practice.  For many, the status quo is unaffected (e.g. contextual targeting).  For some practices, performance would stay the same, but websites would need to implement a new technical approach (e.g. conversion measurement).  A few practices would become substantially more challenging (e.g. social personalization).

We held conversations with a number of stakeholders about this component of our proposal.  The reception was generally positive.  Here are some of the concerns we heard and our responses.

-It will take time to transition to non-ID cookie systems.
Entirely understandable.  An implementation grace period would be reasonable.


-The standard should not require particular privacy-preserving technologies.
We completely agree.  This proposal sets requirements for certain privacy properties; it does not require any particular privacy-preserving technology.

-Some privacy-preserving approaches add latency with an extra roundtrip or client-side processing.
Yes.  Delaying ad display by a tenth of a second seems a slight price for keeping a user's browsing history private.

-Storing more information in the browser could expose the user to additional privacy risks.
That depends on what's stored in the browser.  Even in the absolute worst case, where a third party stores the user's browsing history, there isn't much marginal privacy risk.  A local attacker can already access the user's browsing history in a well-known location.  A remote attacker cannot access the user's browsing history unless the third party fails in rudimentary security precautions (e.g. XSS defense).

Jonathan


On Sunday, June 10, 2012 at 5:46 PM, Shane Wiley wrote:

>  
> Thank you Jonathan – I was not following the use of IDs during the grace period – this makes it much clearer (outside of security, no IDs whatsoever).  As there are other permitted uses outside of security/fraud that require an identifier, your proposal as it stands would significantly harm the current internet ecosystem.  Without an identifier even a pathway to aggregation is unreachable as you need an anonymous identifier to link events to properly aggregate them (simplest example here is a “returning visitors” metric).
>  
>  
>   
>  
>  
> Thank you again,
>  
>  
> - Shane
>  
>  
>   
>  
>  
> From: Jonathan Mayer [mailto:jmayer@stanford.edu]  
> Sent: Sunday, June 10, 2012 4:45 PM
> To: public-tracking@w3.org (mailto:public-tracking@w3.org)
> Subject: Re: Towards a DNT Grand Bargain
>  
>  
>  
>   
>  
>  
> (swapping threads for organization)
>  
>  
>  
>   
>  
>  
>  
> Our proposal does not allow for ID cookies (or equivalents), unless a) the user consents, or b) there's some reason to believe the user is attempting fraud or security breach.  I'm uncertain how you came to be confused on this point.
>  
>  
>  
>   
>  
>  
>  
> Jonathan
>  
>  
> On Sunday, June 10, 2012 at 3:08 PM, Shane Wiley wrote:
> >  
> > Jonathan,
> >  
> >  
> >  
> > They collect the identifier only for delivery of the service and move to unlinkability within a short period of time – I thought that outcome was provided for in your proposal.  Are you saying no identifiers, of any type, may be used in your proposal?
> >  
> >  
> >   
> >  
> >  
> > - Shane
> >  
> >  
> >   
> >  
> >  
> > From: Jonathan Mayer [mailto:jmayer@stanford.edu]  
> > Sent: Sunday, June 10, 2012 3:06 PM
> > To: Shane Wiley
> > Cc: Justin Brookman; public-tracking@w3.org (mailto:public-tracking@w3.org)
> > Subject: Re: Considering browser vendor as a third party
> >  
> >  
> >  
> >   
> >  
> >  
> >   
> >  
> >  
> > On Sunday, June 10, 2012 at 2:37 PM, Shane Wiley wrote:
> > >  
> > > Jonathan,
> > >  
> > >  
> > >   
> > >  
> > >  
> > > For the examples I listed, I’ve seen a step in either install or first use of the browser where I’ve been asked to consider participation (research panel, phishing scanning) and/or how I would like a certain option configured (default search engine for example).  With respect to the “proxy traffic” example - I had a Kindle Fire for a brief time and they “collect” very little information, for a limited period of time, and only retain aggregate (unlinkable) data – but was NOT shown this information in a separate “pop-up” during first use (has that changed – no longer have the Kindle Fire so I can’t check).
> > >  
> > >  
> > >  
> > >  
> >  
> >  
> > Ok, so we're on the same page—some products in this space get explicit consent ex ante, while many (most? almost all?) don't.
> >  
> >  
> > >  
> > > I would have thought based on your proposal they would be in the clear for not needing consent based on the limits they place on their business practices (and their PP is crystal clear on this feature for anyone with questions).  Based on your current proposal, if you were to treat as a 3rd party (non-service provider), would they require opt-in consent based on their limited use and retention of the data collected – or would their approach be covered under your grace period?
> > >  
> > >  
> > >  
> > >  
> >  
> >  
> > These products collect a user's browsing history in connection with a unique identifier.  Moreover, the identifier is in some instances an unchangeable hardware value or deliberately linked to a user's identity.  The practices plainly exceed "protocol information" as defined in the compromise proposal.
> >  
> >  
> > >  
> > > - Shane
> > >  
> > >  
> > >  
> > >  
> >  
> >  
> >  
> >  
>  
>  
>   
>  
>  
>  
>  
>  
Received on Monday, 11 June 2012 06:32:32 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:30 UTC