Re: Summary of Options for 1P Learning of 3P DNT Status

I see two technical approaches to gaming a tiered service - that is, getting the full service without being tracked.

1) The browser might tell a third party Do Not Track is enabled, while making the first party believe that Do Not Track is not enabled for the third party.

With a browser status API approach, gaming of this sort is easy.  Just spoof the API.

An inter-frame communication approach can very likely be gamed in this way - but with significantly greater difficulty.  Someone would have to reverse engineer and spoof each inter-frame DNT status protocol.  (The only way to completely prevent this is with cryptographic authentication, which seems very unlikely to be deployed.)

Whether a backend approach could be gamed in this way is implementation-specific.  If a third party understood its current Do Not Track status solely from HTTP, this sort of gaming would not be possible.  If, on the other hand, the third party ran some JavaScript that used Do Not Track status from a browser API and then reported the status back, the browser might just spoof the reporting.

2) The browser might tell a third party that Do Not Track is not enabled, or that the user has opted back into tracking, but take measures to prevent the third party from tracking the user.  How easy or effective this approach would be is very implementation-specific.

Setting aside the technical feasibility of gaming tiered service, there remain significant open questions of 1) the proportion of websites that would actually degrade service for Do Not Track users, 2) what tools would be developed to help users game tiered services, and 3) the proportion of Do Not Track users that would try to game tiered services (e.g. with a purpose-built browser extension).  I'm very skeptical that, in practice, there would be much of an issue here.

On Oct 29, 2011, at 9:04 PM, Vincent Toubiana wrote:

> 
> Hi Jonathan,
> 
> Do we want to prevent users from cheating the system (i.e. forging a message from the third party saying that DNT is disabled) ? If so, should'nt the first and the third party share an identifier anyway?
> 
> Vincent
> 
> On Oct 28, 2011, at 9:53 PM, Jonathan Mayer <jmayer@stanford.edu> wrote:
> 
>> 
>> On Oct 28, 2011, at 11:22 AM, Karl Dubost wrote:
>> 
>>> Jonathan,
>>> 
>>> Le 26 oct. 2011 à 03:13, Jonathan Mayer a écrit :
>>>> 1) The third party notifies the first party through inter-frame communication (e.g. postMessage or fragment identifiers). 
>>> 
>>> Do you have an example of what you mean by fragment identifier. 
>>> These have already a semantic and properties and I wonder how 
>>> you would use them practically.
>> 
>> Before postMessage, inter-frame communication often used the window.location.hash property.  For an example, see http://www.onlineaspect.com/2010/01/15/backwards-compatible-postmessage/
>> 
>>> 
>>>> 2) The third party notifies the first party through backend communication.  For example, the the first and third parties share a unique session identifier, and the first party makes a RESTful call to the third party.
>>> 
>>> You might mean an HTTP request here. RESTful has also a precise 
>>> meaning that I have rarely seen in deployed APIs.
>> 
>> The implementation could be RESTful.  It need not be.  Just an example.
>> 
>>> 
>>>> Drawbacks:
>>>> -The first and third parties have to establish a shared identifier, add support for a backend protocol, and do realtime backend data sharing
>>> 
>>> what do you mean by realtime?
>> 
>> For most of the use cases we've discussed, a first party has to know each third party's Do Not Track status during page load.
>> 
>>> 1, A client makes an HTTP request with a URI
>>> 2. A server might answer with a representation <A> for this URI.
>>> 3. This representation <A> might contain link to other resources. The client might choose to request them.
>>> 4. The client prioritizes the requests according to certain rules. 
>>> 
>>> One point of the Web architecture is that if I do a request on domain1 and domain2, they are not aware of each other. Sharing identifiers seem a bad idea for separation of concerns and for the users. I usually prefer solutions where the user decide what is acceptable for him, and not having the parties negotiating what is good for users.
>>> 
>>> 
>>> -- 
>>> Karl Dubost - http://dev.opera.com/
>>> Developer Relations & Tools, Opera Software
>>> 
>>