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

Re: Prototype of Do Not Track Exceptions

From: Jonathan Mayer <jmayer@stanford.edu>
Date: Fri, 29 Jun 2012 18:12:27 -0700
To: Schunter, Matthias <matthias.schunter@intel.com>
Cc: "public-tracking@w3.org" <public-tracking@w3.org>
Message-ID: <06C2473BCEE843F6A20812880D321BA1@gmail.com>

My understanding in Bellevue was that this is your proposal for explicit-explicit exceptions.  Some participants thought there should be no explicit-explicit exceptions.  Others thought there should be an ordinary API.  Many (most?) were totally zonked out after two long days.  I don't believe it would be accurate to characterize your proposal as the outcome of our discussion or a preliminary consensus.


On Friday, June 29, 2012 at 4:25 PM, Schunter, Matthias wrote:

> Hi Jonathan,
> here my current perspective on where we stand:
> - we will have an explicit/explicit functionality implemented as follows:
> * a site may publish its third parties via
> the well-known URI
> * if it has done so and calls the api asking for a
> site-wide exception, the user agent may scope
> this exception to the third parties in the list
> (i.e. Continue to send dnt;1 to other thirs parties
> - this feature is optional for sites and clients.
> - this is my take on the outcome of our discussion. We need to validate consensus once we have text.
> Regards,
> Matthias
> -----Original Message-----
> From: Jonathan Mayer
> Sent: 29-06-2012, 16:16
> To: public-tracking@w3.org (mailto:public-tracking@w3.org)
> Subject: Prototype of Do Not Track Exceptions
> Last week's meeting left open three sizable questions about the Do Not Track exception API.
> 1) Should we provide for explicit-explicit exceptions?
> 2) Should a compliant user agent be required to implement the exception API?
> 3) Should we specify some UI elements or language for the exception API?
> Several working group participants suggested it could be difficult to build consensus on these issues in the abstract. I agree. And so I went ahead and implemented a prototype exception API in a Firefox extension. The source is at https://github.com/jonathanmayer/Do-Not-Track/tree/master/exceptions, and I've attached a few screenshots. I want to emphasize: this is a prototype implementation. It's buggy, slow, insecure, and has a number of feature limitations.
> Here are a few takeaways for the group to consider.
> 1) Once site-wide and web-wide exceptions are supported, the marginal effort to support explicit-explicit exceptions is slight.
> 2) A reasonable UI seems possible for explicit-explicit exceptions.
> 3) Implementing the exception API requires orders of magnitude greater effort than implementing the "DNT: 1" header. Developers need to additionally build:
> -a JavaScript API
> -an exception backend
> -an exception request backend
> -an exception request UI
> -an exception management UI
> -more complicated header modification
> And asynchronous message passing among many of those modules. As a rough comparison, my reference Chrome header extension is 9 lines, while my prototype Firefox exception extension is already 521 lines. If we were to require the exception API in compliant user agents, I would expect some user agents would just be non-compliant and some would decide against implementing Do Not Track.
> 4) The exception request and management UIs are *very* hard to get right. I've already iterated a few times, and the prototype still needs *a lot* of work. I would strongly caution against specifying UI elements or language; getting the Do Not Track UI right is going to be a long-term learning process.
> Best,
> Jonathan
> --------------------------------------------------------------------------------------
> Intel GmbH
> Dornacher Strasse 1
> 85622 Feldkirchen/Muenchen, Deutschland 
> Sitz der Gesellschaft: Feldkirchen bei Muenchen
> Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
> Registergericht: Muenchen HRB 47456 
> Ust.-IdNr./VAT Registration No.: DE129385895
> Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
Received on Saturday, 30 June 2012 01:12:54 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:44:51 UTC