Re: How long is a Javascript return DNT value good for?

> On May 2, 2017, at 14:48 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> David,
> 
> Also, it is not accurate to say the processing is cheap.

well, I asked people here who (a) would implement it and (b) know how polyfills would implement it, and they assure me that all properties are cheap to read (and if they are not, you have a reasonable beef against the implementation).


> There are several  reasons DNT can change after a browsing context (say for origin adexchange.com) has been initiated:

Yes, we know DNT values can change. Users change their minds, for a start, and exceptions can be registered.

> 
> 6) The JS Exception API is not supported by the UA, but the publisher has included a "polyfill" library that simulates the API. This can communicate DNT using the navigator.doNotTrack property to collaborating JS in each subresourse browsing context. Unfortunately this has to be communicated sometime after the subresource browsing context has loaded (in all browsers).

The polyfill can establish this property in the browsing context in which it is invoked. And it can change the value when it needs to.


> What I am actually saying is:
> 1) It is always better to wait on an event than having to "poll" with an arbitrary time interval using setInterval or setTimeout

I still do not see why you need to poll. There are certain discrete places in the code of a site where it will make a decision: if (tracking-allowed) do X else do Y. Test the value in that if clause, directly. The only advantage to an event is that it allows you to cache, manually, the value of the property, but honestly, you should let the platform do that caching automatically.

> 2) If someone wants to implement a polyfill library they need to specify a context, such as an event callback, when navigator.doNotTrack is valid.

The property should be initialized as early as possible by the polyfill, and then it’s always valid…

Sorry, I still do not see the reason to have an event to say that a cheap-to-read, rarely changing (in machine terms), property has changed. 

> 

> -----Original Message-----
> From: David Singer [mailto:singer@mac.com] 
> Sent: 02 May 2017 20:11
> To: public-tracking@w3.org (public-tracking@w3.org) (public-tracking@w3.org) <public-tracking@w3.org>
> Subject: How long is a Javascript return DNT value good for?
> 
> This issue came up on the call.  Clearly the DNT value in an HTTP header applies to that transaction (only). But if I call the JS property, which returns the DNT value that would be sent in an HTTP header at that moment, how long can I treat the answer as being true? We’re no longer tied to a transaction.
> 
> Mike proposes that the value is only good for as long as you don’t think it has changed, and that we therefore need an event ‘DNT for your origin has changed’ (I am not sure how we distinguish origins). 
> 
> I wondered if this was needed, and whether we could set a reasonable temporal scope on the return value. We toyed with ‘while the page remains open’ but this doesn’t answer the question for service workers.
> 
> My colleagues point out that
> a) the JS property is cheap, it’s simply checking the base value and exceptions, not doing any disk or network traffic
> b) the number of places that the code might take a different branch, depending on the answer, is probably quite small
> c) it'd be reasonable to require its value to be stable per turn of the runloop. So if you had a function like so:
> 
> function thingy() {
>   if (navigator.doNotTrack && navigator.doNotTrack.startsWith("1")) {
>       a();
>   }
>   ...
>   if (navigator.doNotTrack && navigator.doNotTrack.startsWith("1")) {
>       b();
>   }
> }
> 
> The caller of thingy would know (modulo an exception being raised) that either both A and B got called or neither did.
> 
> 
> 
> Given these, I think we should adopt (c) and also say roughly “you don’t need to ‘poll’ this value, but you should check it at the points where your Javascript would branch depending on the answer, and not cache previous returns for any significant length of time”.
> 
> Dave Singer
> 
> singer@mac.com
> 
> 
> 
> 

Dave Singer

singer@mac.com

Received on Wednesday, 3 May 2017 23:34:38 UTC