doNotTrack property should be derived from EventTarget

[michael-oneill]

Following on from the last issue about returning a Promise, for consistency it would make sense to do the same for the doNotTrack property. Its value cannot be calculated simply before the document is loaded as it may change as a result of user action or calls to the API. Code that uses the API is likely to need to be notified when doNotTrack changes, and having to do it inside a setInterval call back is annoying.

rather than making it simply a DOMString we could derive it from EventTarget, so code could do things like:

navigator.doNotTrack.addEventListener( "consent", function(dnt){
// doNotTrack has changed, - read and act on it now!
// dnt=="1" means DNT header will be "1" in any requests to this origin

                                                                                        },false);

WebIDL

partial interface Navigator {
readonly attribute DoNotTrack doNotTrack;
};

interface DoNotTrack: EventTarget {
DOMString? val;
}

[mschunte2]

Discuss again next time

[mschunte2]

Lukewarm support: Will be decided March 27.

[mschunte2]

The goal of this change is to allow a browser to notify a JavaScript program once a DNT preference is changed. IMHO this may put undue burden onto the browser: While it is easy to calculate a DNT value (check whether one cookie rule applies using the cookie-rules-engine), notifying all subscribing things that a rule was revoked may require extra code.

The pure computation of a DNT value works like this:

• If the general preference is DNT;0, then return 0 and exit.
• Else see if one exception cookie-pattern fires and return "DNT;0" if it does
• If not, return the general preference (DNT;1 most likely).

Creating events seems substantially more complex:

• When computing the DNT value, remember what exception rule triggered the outcome
• Register a subscription to change-events from this rule

If a rule is changed, check for each subscriber of the rule whether any other rule permits this pattern (if yes, move the subscription to the new rule). If not, notify the subscriber that the outcome has changed to DNT;1.

Overall, this effort seems too much burden for a "nice to have" feature.
Please correct me if I am wrong (there may be an elegant way to implement it much simpler).

[michael-oneill]

There is no extra burden on the browser.

The navigator.doNotTrack property "enables a client-side script with read access to the Navigator object to determine what DNT header field value would be sent in requests to the document-origin, taking into account the user's general preference (if any) and any user-granted exceptions applicable to that origin server".

So now every time any of the following occurs:

1. The user changes their general DNT preference.
2. The user gives or revokes their consent, and script somewhere (in the same browser but probably in a different browsing context) requests or removes a DNT Exception.
3. The user revokes their consent, i.e. removes a previously granted Exception, within the browser's UI.
4. A previously granted Exception expires.

the appropriate browsing context has to be calculated and its navigator.doNotTrack property has to be updated. The only extra step for the browser in my proposal is to trigger the event, only a few extra clock cycles (every browser already implements the event system)

What I am suggesting is that immediately after the appropriate navigator.doNotTrack is updated, a dntUpdated event is dispatched, probably on the document object (or it also could be on the navigator object).
(I changed that from my original proposal of making navigator.doNotTrack an EventTarget because there does not appear to be a way to specify that in WebIDL).
[N.B. this assumes navigator always derives from EventTarget - I will check this. If it doesn't I know "document" does.]

i.e. if this is done in JS it would be:
var event = new Event("dntUpdated");
navigator.dispatchEvent(event);

The browsing context interested in being notified when navigator.doNotTrack changes would have called:
navigator.addEventListener("dntUpdated",function(e){
// this function gets called when navigator.doNotTrack changes
// and inside this function navigator.doNotTrack is guaranteed to be valid and navigator.doNotTrack == e.doNotTrack
});

This gives developers a more elegant way to react to changes to DNT (they do not have to set up a setInterval or setTimeout callback with an arbitrary duration value).

More importantly it allows them to associate an asynchronous callback when navigator.doNotTrack is guaranteed to have been updated.

This allows the development of a "polyfill" script library that can simulate the Exception API even if it is not currently supported by the browser or a browser extension. An iframe context for a ad exchange or ad provider could sit on the event and be indicated if consent has been given (and recorded by the parent context (in probably a first-party cookie). If they just examine navigator.doNotTrack (i.e. not inside an asynchronous callback), this can only ever reflect the general preference in this use case (where the user agent does not implement the API).

[mschunte2]

2017-05-1: Mike will propose text

[michael-oneill]

Here is the text to complete my action. Section 2 should be inserted after 5.3 in the TPE.

https://w3c.github.io/dnt/DNTChangeEvent.html

[mschunte2]

2017-05-09 No consensus reached that there is an urgent need. May reconsider if significant implementor's pull.