(In reply to Georg Koppen from comment #20)

(In reply to Tom Ritter [:tjr] from comment #17)

Georg, Arthur - My attitude is that we should lock DNT to <something>; to
prevent the user from being fingerprintable if they change the setting. But
it seems like Tor has decided a long time ago not to do that. If you stand
by that decisionit sounds like we should close this as WONTFIX.

Locking it to "Do not send the header at all" sounds okay with me.

Apple is removing DNT from Safari it seems: https://developer.apple.com/documentation/safari_release_notes/safari_12_1_beta_3_release_notes

"Removed support for the expired Do Not Track standard to prevent potential use as a fingerprinting variable."

For the "expired" part:

"Since its last publication as a Candidate Recommendation, there has not been sufficient deployment of these extensions (as defined) to justify further advancement, nor have there been indications of planned support among user agents, third parties, and the ecosystem at large. The working group has therefore decided to conclude its work and republish the final product as this Note, with any future addendums to be published separately." (https://w3c.github.io/dnt/drafts/tracking-dnt.html)

So, yes, this is essentially dead and it seems to me another argument for not sending the header once privacy.resistfingerprinting is enabled.

IMHO:
1 DNT should be set to the most common value among all the users.
2 Though DNT is standardized to be optin, it is possible to encourage users to optin. For example show them a window with the question "Do you want to say websites that you want to be tracked/stalked/spied/<something nasty here>?" and 2 buttons "yes" and "no", "no" sets the header to 1, yes sets the header to 2. Sane people would choose "no", and if the majority is sane (I am not sure in this, but hope so), we will have dnt=1 for the majority. Though one must understand that ones tracking would just ignore that value and ones ont tracking have nothing to do with it, si this header is pointless, it may make sense to drop its support completely.

I would just get rid of DNT altogether, remove it from Firefox.

The new "do not track" is the Tracking Protection, not some header that never had any chance to be followed but instead increases entropy, allows passive tracking (no JS needed, just record headers as resources are requested), and increase the payload of all network requests.

If we want to normalize DNT, we should kill it like Apple is about to do with Safari 12.1.

increase the payload of all network requests

I meant the size of the packets. Obviously DNT is part of the headers.

Wouldn't enabling DNT in RFP mode simply make it easier to fingerprint users though?

No.

Yes: RFP users cannot be distinguished from the larger ESR group from request headers alone. If I request an image from a third party site, all they will know is that I am part of the ESR + RFP group. (I wouldn't spoof Firefox version for this reason btw: JavaScript makes knowing that a user is part of the RFP group easy, but without JS it can be harder, and likely impossible in some cases for third parties.)

However if RFP enables DNT, they will know that I am part of some mere 5% of the Firefox ESR population: ESR's TP group + ESR's RFP group + Non-ESR's RFP group + ESR's DNT-only group.

In other words, by enabling DNT, I went from being indistinguishable from 100% of the ESR+RFP group, to being indistinguishable from about 5% of this group, when loading a passive asset from a third-party website.

In other words, by enabling DNT, I went from being indistinguishable from 100% of...

That's not quite how fingerprinting works in this situation. You were always distinguishable. This is purely a case of lowering the entropy of one metric (DNT) in a set group of users (RFP) by enforcing a value. i.e all RFP users would be the same, rendering the metric as useless for fingerprinting. It's that simple.

The question was not about whether DNT should be removed or if it is effective: that is for another topic. The question is, since it exists, it adds entropy: therefore, what should we set it to?. Tor Browser already does this. It would be nice to reduce entropy for Firefox RFP users as well. Ultimately this is a Tor Uplift, and DNT is not tied (or no longer tied) in any functional way to ETP (which is what I thought it may have been) and we should match what Tor Browser want/use (as long as Mozilla are OK with that, which I think they are given the changes since this ticket was created 18 months ago).

That's not quite how fingerprinting works in this situation. You were always distinguishable.

As I said, "I" am not distinguishable from the larger ESR group from HTTP headers alone, i.e. what a third-party server can see from a request to one of its passive third-party asset.

IIRC, Firefox-ESR and Release-with-RFP send the same HTTP headers. Therefore if RFP sends a DNT value, users split from a larger group into a 20x smaller one.

i.e all RFP users would be the same, rendering the metric as useless for fingerprinting.
[...] since it exists, it adds entropy: therefore, what should we set it to?

And the single best answer is we remove it: Set it to the value where it is not set, like Apple is doing and like Georg Koppen from the Tor project agrees to in comment 20. DNT has 3 values, one of which where it is simply not sent. That's the best one to normalize everyone around.

Your initial concern included Tracking Protection, but Tor Browser does not use that, IIRC, so that does not apply to them. They are fine regardless of whether RFP sends DNT or not, basically.

The DNT header only makes a difference to Firefox users, and this is where it should IMO be normalized on "never send it", including with Tracking Protection or Private Browsing.

In terms of relevant groups to hide in with regards to third-party servers, we have:

A- Firefox with RFP but not (TP or PB)
B- Firefox with RFP and (TP or PB)
C- Firefox ESR without (RFP or TP or PB)
D- Firefox ESR with RFP but not (TP and PB)
E- Firefox ESR with RFP and (TP or PB)

1/ RFP sends no DNT header:

Groups A and D look exactly like group C, which happens to be the largest one by far.
Groups B and C look the same but are both small groups

2/ RFP sends a uniform DNT header:

Groups A, B, D and E look the same, but they are all small groups.
Group C is not leveraged to help people who want to resist fingerprinting.

We see that the best solution is to not set DNT... And in a different bug, remove it from Tracking Protection and Private Browsing.

Groups B and C look the same but are both small groups

Crap, sorry for email recipients. I meant Group B and E. They send DNT through TP or PB and are cut off from the large Firefox ESR group because of it, unlike groups A and D.

All FF users return 1 because of ETP (Strict or Standard). ETP custom users are not our concern (why would they disabled blocking trackers?). All TB users return unspecified (because ETP's block trackers is not used). RFP is not front facing, is for TB, and TB is already covered ... so this is fine. Closing as invalid