712616 - navigator.doNotTrack documentation inconsistency

Status: RESOLVED FIXED

(Developer Documentation Graveyard :: General, defect)

Description

[Anthon Pang]

Reference: https://developer.mozilla.org/en/DOM/navigator.doNotTrack states, "dnt is the value of the string sent for the do-not-track header."

In bug 628197, the value of the string sent in the header is "1" if enabled.  But in FF9, per bug 629535, navigator.doNotTrack returns "yes" (if enabled), or "unspecified".

For comparison, in Safari 5.1, if "Send Do Not Track HTTP Header" is enabled, the value of the string in the header is "1" and navigator.doNotTrack similarly returns "1".

It's a bit disappointing that Mozilla led the DNT proposal, but didn't implement it as proposed.
 
Quick fix:
 * update the online documentation

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Justin?

Comment 2

[Justin Lebar (not reading bugmail)]

> "dnt is the value of the string sent for the do-not-track header."

The docs are wrong.  I'll file a webkit bug on fixing their implementation.

Anthon, the reason we did "yes/no/unspecified" is because we wanted no value to parse as "false" in JS.  If we did "1/0/(empty string)", then the broken code

  // BAD; don't do this.

  if (navigator.doNotTrack) {
    // don't track user
  } else {
    // ok to track user
  }

would track users who haven't chosen a DNT preference and not track everyone else.  In contrast, this broken code does not track all users when we send "yes/no/unspecified".

(Historically, the reason DNT sends 1/0/(empty string) is to save bandwidth, because HTTP headers are not compressed, not because it's user-friendly.)

Comment 3

[Justin Lebar (not reading bugmail)]

Okay; it looks like the docs have already been fixed.

Comment 4

[Justin Lebar (not reading bugmail)]

https://bugs.webkit.org/show_bug.cgi?id=75008

Are you satisfied with the new documentation, Anthon?  If so, please close this bug.

Comment 5

[Justin Lebar (not reading bugmail)]

er...now the docs are updated properly.

Comment 6

[Anthon Pang]

Ok with me.  Thanks.

Comment 7

[Anthon Pang]

p.s. please coordinate with MS on their draft which includes DNT.  http://www.w3.org/Submission/web-tracking-protection/

Comment 8

[j.j.]

Changing resolution, this bug, as reported, is invalid.

Comment 9

[j.j.]

Sorry, nonsense. Updating the docs was the point here.

Comment 10

[Anthon Pang]

The latest working draft of the TPE http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html states:

4.3.2 Attributes

doNotTrack of type DOMString, readonly

When a tracking preference is enabled, the doNotTrack attribute must have a string value that is the same as the DNT-field-value defined in section 4.2 DNT Header Field for HTTP Requests. If a tracking preference is not enabled, the value is null.

Should I re-open?  Or is Mozilla's representative in the TPE working group going to address this?

Comment 11

[Luke Crouch [:groovecoder]]

Since MDN is a wiki, you can make changes to the page yourself. I'm sure the docs team will see it and discuss if needed.

Comment 12

[Justin Lebar (not reading bugmail)]

(In reply to Luke Crouch [:groovecoder] from comment #11)
> Since MDN is a wiki, you can make changes to the page yourself. I'm sure the
> docs team will see it and discuss if needed.

Well, he's saying he wants to change it back to match the spec, which is intentionally what we do not do.  So I think he did the right thing posting in the bug, rather than changing the wiki!

I'll bring it up with the working group.  Thanks.

Comment 13

[Anthon Pang]

No, I meant re-opening to edit the wiki.  (I didn't know I could do this myself.)  I've added a reference to the TPE, Opera 12 support, and some footnotes below the compatibility table.

Comment 14

[Justin Lebar (not reading bugmail)]

(In reply to Anthon Pang from comment #13)
> No, I meant re-opening to edit the wiki.  (I didn't know I could do this
> myself.)  I've added a reference to the TPE, Opera 12 support, and some
> footnotes below the compatibility table.

Okay.  :)  Looks great.

I've e-mailed the WG.

Comment 15

[Karl Dubost]

The actual thread is available at http://lists.w3.org/Archives/Public/public-tracking/2012Apr/thread.html#msg119

According to the thread there is no will to do what is suggested here. Not only the wiki MDN is wrong or doesn't reflect reality of the discussions and issues.

But The firefox implementations is wrong too.

Comment 16

[Justin Lebar (not reading bugmail)]

> According to the thread there is no will to do what is suggested here.

I've explained ad nauseum in that thread why I think this is the right course of action.  Just because we don't match the current W3C spec doesn't mean our implementation "wrong"; I would argue and have argued that the spec is in fact wrong.

Comment 17

[Karl Dubost]

Justin, I have seen that. 

The principles of consensus make it that at a point you have to be compatible with the Web and the rest of what others are doing.  Currently the WG doesn't think, Firefox does the right thing. Or at least Mozilla didn't convince the rest of the WG. That doesn't make Firefox right either.

If you are drifting from the specification then say it in MDN, no issue with that. The message could be along: 

===================================================
According to the  June 23, 2012 version of the specification, http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html, The WG recommends to implement 

Navigator.doNotTrack == "1"

The issue 84 of the Tracking Protection WG is still open. 
http://www.w3.org/2011/tracking-protection/track/issues/84

The implementation of Firefox is different from the spec because Mozilla thinks [here insert your reasoning]

===================================================

Remove this sentence, because it is *wrong*:

"IE9, Opera 12, and Safari 5.1 are based on an earlier version of this specification where navigator.doNotTrack is the value sent for the do-not-track header."

These browsers follow the current spec.

Comment 18

[Justin Lebar (not reading bugmail)]

Karl, we don't /have/ to do anything.

I would love to be compatible with other implementations and the w3c's spec.  But it is an incorrect understanding of how web browser development works to suggest that web browsers which do not follow "consensus" in working groups are somehow in the wrong.

Moreover, I would argue that there is no consensus by any reasonable definition of the word here.  The discussion on the mailing list was abusive, to put it lightly, and the fact that I chose to stop participating does not reflect my assent to the conclusions others reached there.  Some loud and perhaps important people feel one way, but it's hard to imagine how one can reasonably label this spec a "consensus" without agreement from a browser vendor with 25% of the desktop market share.

The only trump card web browser developers have to get their way in the working groups is stubbornly refusing to change their implementation to match the spec.  Mozilla and others use this all the time.  I'm sorry that it's frustrating in this case; if it's any consolation, I'm also frustrated.

Comment 19

[j.j.]

Karl, as said before in this bug, MDN is a wiki and _everybody_ can edit it.
Seems you have deep insight in this issue especially what other browsers have implemented an where/why Mozilla differs from the spec.
Cross browser information is always very welcome in Mozilla docs.
Please don't hesitate and improve MDN!
(But be aware that just now a major wiki software change is going on, may be better to wait some days.)

Comment 20

[Karl Dubost]

@j.j. 

Yes I'm aware of the MDN wiki changes. I will wait for it to be stable. 
The implementation right/wrong should not be part of this bug discussion, it has to be in the appropriate bug of Firefox. My bad for introducing it here. That said MDN is clearly not aligned with the current state. 

@jlebar

I know a little bit about browser development… :) but that's not the point.

Comment 21

[Justin Lebar (not reading bugmail)]

> The implementation right/wrong should not be part of this bug discussion, it has to be in the 
> appropriate bug of Firefox. My bad for introducing it here.

I feel like we've already had this discussion on the w3c list, but please feel free to file a bug.  I'd love to reach an actual consensus.

Comment 22

[Anthon Pang]

Given that I updated the wiki in April, let me clarify that "this specification" refers to the MDN wiki page for DNT, as Mozilla led the DNT proposal which predates the W3C TPE effort and other browser implementations.  By "earlier specification", I mean an earlier version of the wiki page before it was changed to reflect the as-is implementation in Firefox.

The point made for "yes/no/unspecified" is justified ... indeed I got it wrong in Piwik (circa January 2011 when I was following the DNT proposal).

Note: I'm not a proponent of the TPE draft, primarily because /.well-known/dnt is mandatory, alien to most webmasters, and not supportable by a web app such as Piwik.