Bug 75008 - navigator.doNotTrack returns wrong values.
: navigator.doNotTrack returns wrong values.
Status: RESOLVED INVALID
Product: WebKit
Classification: Unclassified
Component: HTML DOM
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To: Nobody
: InRadar
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-21 08:07 PST by Justin Lebar
Modified: 2011-12-21 16:00 PST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Lebar 2011-12-21 08:07:25 PST
We decided that navigator.doNotTrack would return "yes/no/unspecified" in Firefox, but Safari 5.1 apparently [1] returns "1/0/(empty string)" to match the DNT header.

The reason we did "yes/no/unspecified" is because we wanted no value to parse as "false" in JS.  This way, buggy code which does |if (navigator.doNotTack)| will fail closed.  With 1/0/(unspecified), the bogus boolean check works so long as you never have people explicitly opting in to DNT; thus we were afraid that sites would rely on DNT being a boolean, rather than a tri-state, and then we'd never be able to send navigator.doNotTrack == "0".

How would you feel about changing to match Firefox's implementation?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=712616
Comment 1 Justin Lebar 2011-12-21 11:00:20 PST
> With 1/0/(unspecified), the bogus boolean check works

Er, that should be "With 1/0/(empty string)".
Comment 2 Alexey Proskuryakov 2011-12-21 15:56:14 PST
<rdar://problem/10616671>
Comment 3 Alexey Proskuryakov 2011-12-21 15:59:58 PST
Perhaps confusingly, WebKit doesn't implement the doNotTrack property yet. Adding it is tracked by bug 73088.

In Safari, doNotTrack property is injected by closed source browser code. I have migrated your report to Apple's internal system, and will close this bug now as a non-WebKit issue. Thank you very much for letting us know!