Re: ISSUE-116: How can we build a JS DOM property which doesn't allow inline JS to receive mixed signals?

On May 30, 2012, at 0:31 , Nicholas Doty wrote:

> (This is more broadly related to ISSUE-84, and this summary and proposal addresses ACTION-180.)
> 
> ## Quick summary
> 
> It would be nice if JavaScript on the page could access the appropriate DNT preference for the user so as to know not to take actions that initiate or involve tracking, or to provide a different user experience (like privacy options, or an exception request). One concern with a naively implemented navigator.doNotTrack property is that the DNT value may vary (in the case of user-agent-managed user-granted exceptions) for different domains but the DOM property is singular. In particular, if a script is embedded via a <script> tag, it will have the same effective script origin as the first party page but may have a different expressed tracking preference. We would like JavaScript running on the page to make decisions based on the DNT value and not receive mixed signals about the user's DNT preference.
> 
> ## Proposal
> 
> navigator.doNotTrack reflects the value of the DNT header sent to the 1st party (the top-level document origin). For the simplest implementation (DNT:1 sent for all requests, no exceptions yet granted), this is already effective; this reflects current implementations in IE and Firefox. First party JavaScript can safely use the DOM property to determine the user's tracking preference for the first party domain and as an indicator that embedded third parties may be receiving a DNT:1 value.
> 
> Guidance is provided that the doNotTrack DOM property is a hint but does not guarantee the value of the DNT header sent on future requests (via XmlHttpRequest, for example); compliant servers must use the HTTP header on a particular request to respect the user's preference. A user's preference may have changed (even within a first-party context) or may be different for different domains.
> 
> This is especially important guidance for third-party trackers which may commonly receive a different DNT header value than the first party. For trackers that do not commonly expect to receive user-agent-managed exceptions, the first party value is likely to be sufficient guidance (assuming the header is always sent to first parties, see below). For trackers that do commonly expect to receive user-granted exceptions, the user's DNT preference should be assessed during the HTTP request and should not rely on the DOM property.
> 
> ## Relevant related questions
> 
> Some questions turn on what value the first party will receive. If a first party is guaranteed to receive a DNT header starting with "1" if the user has configured *any* third party domain to receive DNT:1, then the DOM property is guaranteed to be no more permissive than the value for the third party. Some user agents might like the option of not sending DNT:1 to every first party domain if a user has configured the browser to opt out of tracking for only some trackers (as in the current self-regulatory opt-out cookie approach).
> 
> Depending on how we conclude ISSUE-111, the first party header may explicitly indicate a separate value for third parties in the case of a site-wide exception. For example, if DNT:10 is sent when a user has granted a site-wide exception, then third party JavaScript in that case could determine the presence of the relevant exception by checking the value of navigator.doNotTrack[1]. (I would support this resolution of ISSUE-111, which would help substantially with this issue and address some concerns we've heard re: publishers and server-side decision-making.)
> 
> ## Alternatives that I've heard but am not proposing
> 
> A parameterized function, a la navigator.mayTrack("thirdparty.com").
> Pros: Flexibility and detailed info for tracking JavaScript. 
> Cons: Seems inelegant, enables fingerprinting, enables one third party to determine the exception status of another.
> 
> A different navigator.doNotTrack value for JavaScript from a different domain.
> Pros: Magically gives all JS the correct value.
> Cons: Hard to distinguish in the browser (since effective script origin is the same) and especially in the case of browser plugins.
> 
> Removing the DOM property altogether.
> Pros: Straightforward.
> Cons: Non-dynamically-generated JavaScript can't make efficient decisions re: DNT status.

Also, perhaps one more function:

DoIHaveAnException()  -- implicit parameters are the current top-level domain (TLD) and the script-origin (SO), and answers whether [TLD, SO] matches a rule in the database (note that this covers site-specific and web-wide)


David Singer
Multimedia and Software Standards, Apple Inc.

Received on Thursday, 31 May 2012 00:04:09 UTC