Re: editor's note on the navigator property

> On Jul 17, 2017, at 6:42 AM, David Singer <singer@mac.com> wrote:
> 
> I don’t understand this editor’s note in the draft:
> 
> "the doNotTrack property which now appears to be useless”
> 
> Why is it useless?  It computes the header that would be sent to the domain of the requestor. The result is impacted by (at least):
> 
> a) the user’s general preference
> b) whether there is a web-wide exception that I have requested and been granted (ok, this is something I both should know and could verify in other ways)
> c) whether I am embedded in a site that has requested a site-specific exception that includes me (OK, I could try to confirm the duplet formed by the top-level browsing context and me, and confirm that exception, but what a hassle)
> 
> There are (at least) these three to check, and I don’t believe a script has any other way to get (a).
> 
> What am I missing?

The doNotTrack property originally contained the user's general preference.

Later it was changed to be a dynamic value based on what DNT value would
be sent to the document's domain.  The problem is that the DNT value sent
to a given domain might be site-specific, so it depends not only on the
document's domain but also the context in which the domain is referenced.

In order to be useful to scripts, the value should be defined with respect
to the tuple [context, target]:

  context = top-level browsing context (if the document is within an iframe)
  target  = current browsing context (domain of the effective script origin)

and then it would be usable for things like scripts within iframes.

In any case, the definition needs to be improved so that this
is clear to browser developers expecting to implement the property.
Also, we should note that the property might only be set when the
browsing context is loaded, so don't expect it to change immediately
after calling the storeException API.

....Roy

Received on Monday, 17 July 2017 17:34:02 UTC