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

Re: Prototype of Do Not Track Exceptions

From: Peter Cranstone <peter.cranstone@gmail.com>
Date: Fri, 29 Jun 2012 20:46:13 -0600
To: Jonathan Mayer <jmayer@stanford.edu>, <public-tracking@w3.org>
Message-ID: <CC13C376.4967%peter.cranstone@gmail.com>
Jonathan,

Quick follow up ­ I realize that this is just a "test" that eventually this
will all be coded into the browsers as part of the OEM's support of the
spec. What we're seeing here is just a way to see how complex it is to code
something thatıs all. Which in turn makes my question regarding Mobile moot
as it will have to be coded by the OEMs due to the plugin issue. That said
though Mozilla's currently Android browser does support plugins so its an
option there.


Peter
___________________________________
Peter J. Cranstone
720.663.1752


From:  Peter Cranstone <peter.cranstone@gmail.com>
Date:  Friday, June 29, 2012 7:13 PM
To:  Jonathan Mayer <jmayer@stanford.edu>, W3 Tracking
<public-tracking@w3.org>
Subject:  Re: Prototype of Do Not Track Exceptions

> Jonathan,
> 
> Great job, it's good to see implementation "code" ideas.
> 
> I do have two questions (and this is NOT designed to start another flame war
> on the forum) - what about Mobile? There's currently no way to "plugin" into
> the mobile browsers and also JavaScript is not as well supported on the
> current crop of mobile browsers.
> 
> Second question ­ looking at your source code
> 
> var headerName = "DNT";
> var headerValueDefault = "1";
> var headerValueException = "0";
> 
> Do you foresee the need to add additional values to resolve the exception?
> (e.g. "2") Looking at your UI screen shots I don't see the need because you're
> still asking the user what is essentially a binary question ­ do you want to
> share or not? I'd be interested in your thoughts on this.
> 
> Thanks.
> 
> 
> Peter
> ___________________________________
> Peter J. Cranstone
> 720.663.1752
> 
> 
> From:  Jonathan Mayer <jmayer@stanford.edu>
> Date:  Friday, June 29, 2012 5:13 PM
> To:  W3 Tracking <public-tracking@w3.org>
> Subject:  Prototype of Do Not Track Exceptions
> Resent-From:  W3 Tracking <public-tracking@w3.org>
> Resent-Date:  Fri, 29 Jun 2012 23:15:30 +0000
> 
>>  
>> 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
>> 
>> 
>>  
Received on Saturday, 30 June 2012 02:46:58 UTC

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