Re: navigator.doNotTrack

> Is there a way to achieve this same-trueness of the property while also providing an obvious way to add extensions in the JavaScript property?
>
> Could the doNotTrack property be "1", "0" or "unspecified" and then any extension to the header should be appended to "1" and "0" (and header values shouldn't ever be "unspecified")?
>
> Thanks,
> Nick

"1", "0", and "unspecified" would work as well as "yes", "no", and
"unspecified", yes.

But I don't see how extensions would fit in here without breaking
existing logic.  Suppose you added a "foo" extension, so now people
send "DNT: 1 foo".  If we reflected this verbatim in the DOM, then
every site which checks for navigator.doNotTrack == "1" will break.

Or alternatively, suppose we added DNT: 2.  Again, websites would
handle this incorrectly if we returned it in navigator.doNotTrack,
because many sites would do an if {} elseif {} else {}.

To be clear, it's a problem that web servers would have to be updated
to handle this new DNT field, but at least there's some hope of
getting that right, since there are only a handful of web servers.
With the Web, there's no hope of getting legacy pages updated.

It seems to me that we'd want to expose an extension as
navigator.doNotTrackFoo, or perhaps
navigator.doNotTrackExtensions['foo'], or something other than
navigator.doNotTrack.

Perhaps I'm missing the point of these extensions?

-Justin

> On Apr 11, 2012, at 11:54 AM, Justin Lebar wrote:
>
>> Section 4.3.2 of the Do Not Track spec says:
>>
>> "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."
>>
>> This does not match our implementation in Firefox.  Instead, we return
>> "yes", "no", or "unspecified".
>>
>> We did this so that if a web developer writes the following buggy code:
>>
>>  if (navigator.doNotTrack) {
>>    // don't track them
>>  }
>>  else {
>>    // track them
>>  }
>>
>> it will always fall into the "do not track" branch.  Presumably the
>> developer would notice this and fix their code.  (Or not, and they
>> don't track anybody, and that's fine too.)
>>
>> In contrast, if navigator.doNotTrack returned "1", "0", or null, the
>> if statement above would fall into the "track" branch for null but not
>> "1" or "0" -- this is clearly wrong.  If developers started writing
>> this buggy code -- and I hope I don't need to argue that they will,
>> because every bug that can be made is made, and many times, on the Web
>> -- it would then be difficult for us to start returning "0" for
>> doNotTrack, since that would cause incorrect behavior.  We'd be
>> effectively stuck with DNT as a two-state value.
>>
>> The problem is, DNT has three states.  In a reasonable implementation,
>> all three states should have the same true-ness -- otherwise,
>> developers will treat it like a boolean and get incorrect behavior.
>>
>> We would like the spec changed to match our implementation.
>>
>> Regards,
>> -Justin
>>
>

Received on Wednesday, 11 April 2012 16:46:04 UTC