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

Agreed.  I would make the what-are-the-future-implications? language on the header and attribute parallel.  I would also drop the last sentence (websites already MUST check the HTTP header, right?), and instead add an explanatory note about how the doNotTrack attribute is merely a convenience accessor.


On Wednesday, July 18, 2012 at 5:44 AM, Ed Felten wrote:

> It seems more consistent to say "MUST NOT" instead of "SHOULD NOT" in
> the suggested text. Using "SHOULD NOT" implies that it might
> sometimes be acceptable to interpret the doNotTrack attribute as a
> guarantee of the header value that will be sent in future requests,
> which conflicts with the later statement that servers MUST rely on the
> header value that is actually received in a future request.
> 
> 
> On Wed, Jul 18, 2012 at 2:38 AM, Nicholas Doty <npdoty@w3.org (mailto:npdoty@w3.org)> wrote:
> > I did not see responses to this proposal back in May. Matthias asked (ACTION-224) that I ensure the editor's draft reflected this proposal. Here are the changes I think the editors would need to make (and I'm happy to help them with the actual wordsmithing and HTML-editing) to implement this proposal.
> > 
> > Thanks,
> > Nick
> > 
> > Add to section 4.3.2:
> > The doNotTrack attribute must have a string value that is the same as the DNT-field-value sent to the origin of the corresponding `document`.
> > 
> > Add to 4.3 or to a new sub-section:
> > The value of the doNotTrack attribute SHOULD be considered guidance and SHOULD NOT be interpreted as a guarantee of the value of the DNT header sent on future requests. A user's tracking preference may change and may differ for different origins. Servers MUST rely on the DNT header received in a request even if it differs from what a script previously observed in the `doNotTrack` attribute. Trackers that commonly expect to receive a user-granted exception (as described in Section 6) SHOULD assess the user's preference in the HTTP request loading that script.
> > 
> > On May 30, 2012, at 12:31 AM, 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 (http://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.
> > > 
> > 
> > 
> 
> 
>