Privacy Badger does not set the doNotTrack variable in JavaScript's navigator object

[tadatitam]

It seems like Privacy Badger sends the Dnt header, but does not set the doNotTrack variable in JavaScript navigator object. This is different from Firefox's Tracking Protection (https://support.mozilla.org/en-US/kb/tracking-protection) and Chrome's Do Not Track (https://support.google.com/chrome/answer/2790761) behavior: they send the Dnt header in addition to setting the Javascript navigator doNotTrack variable.

I was wondering why Privacy Badger does not set the doNotTrack variable. Could this have privacy consequences for Privacy Badger users (e.g., against a web service that only detects Do Not Track using JavaScript)?

Attaching some screenshots displaying the doNotTrack variable using a small piece of code on w3schools.com. The screenshots show that Privacy Badger does not modify that variable, unlike Firefox's Tracking Protection and Chrome's Do Not Track features.

Baseline Firefox:

Firefox with Privacy Badger:

Firefox with Tracking Protection enabled:

Baseline Chrome:

Chrome with Privacy Badger:

Chrome with Do Not Track enabled:

Screenshots were produced on
Chrome version: 63.0.3239.132
Firefox version: 56.0
using
Chrome extension version: 2017.11.20
Firefox add-on version: 2017.11.20

[ghostwords]

We should be able to get this fixed by doing something like the following inside all pages (and frames?):

Object.defineProperty(Object.getPrototypeOf(navigator), "doNotTrack", {
  get: () => {
    return "1";
  }
});

I previously thought navigator.doNotTrack is protected from overwriting, but it looks like I just didn't do it right since the above code seems to work.

[ghostwords]

We should check if using the new doNotTrackEnabled capability of the chrome.privacy API (available as of Chrome 65) is a better fix (instead of injecting JS). If we go that route though, we may not be able to disable DNT=1 signals for pages where Privacy Badger is disabled (#1260).

[tadatitam]

@ghostwords Thanks for responding!

We should check if using the new doNotTrackEnabled capability of the chrome.privacy API (available as of Chrome 65) is a better fix (instead of injecting JS). If we go that route though, we may not be able to disable DNT=1 signals for pages where Privacy Badger is disabled (#1260).

One option is to let users make the choice. Privacy Badger (PB) can have both options:

1. Send Do Not Track only on websites where PB is enabled, which can be implemented by
   JS injection, or
2. Always send Do Not Track, which can be implemented using the doNotTrackEnabled capability of the chrome.privacy API.

That being said, this leaves open the hard question of determining which should be the default (since most users may not change settings). Personally, I am in favor of the former, since it provides users with finer-grained control: if someone is making the effort of disabling PB on a page, they should be able to remove all its effects.

I suppose there is something analogous to the doNotTrackEnabled capability for Firefox too. So, this discussion pertains to both browsers.

[michael-oneill]

If PB implements the DNT consent API (#1230) it will have to use the defineProperty method. The value of navigator.doNotTrack will depend on whether the storeTrackingException has been called, which could be web wide or site specific. Even if the implementation is not designed to immediately reflect the result of the call (the spec leaves that as an option) the correct value of navigator.doNotTrack must be available when any new browsing context is initiated (not just a 1st party i.e. top level context).