- From: Schunter, Matthias <matthias.schunter@intel.com>
- Date: Fri, 29 Jun 2012 23:25:41 +0000
- To: "public-tracking@w3.org" <public-tracking@w3.org>, Jonathan Mayer <jmayer@stanford.edu>
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 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 Sunday, 1 July 2012 00:01:53 UTC