Re: navigator.doNotTrack

Hi Justin,

Thanks for the note. One concern we had was that we may later add extensions to the DNT header, providing a string that matches the DNT header provides a clear way to which extensions to the DNT header can then be exposed in JavaScript.

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

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:35:40 UTC