Closed Bug 1466025 Opened 6 years ago Closed 10 months ago

enforce DNT header when privacy.resistFingerprinting=true

Categories

(Core :: DOM: Security, defect, P3)

Product:
Core
Component:
DOM: Security
Version:
60 Branch
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: simon.mainey, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fingerprinting][domsecurity-backlog1][fp-triaged]) 

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20100101

Steps to reproduce:

When resisting fingerprinting, we should make all RFP users uniform re DNT headers. Recommended setting is to enforce it as enabled, so it does not interfere with Tracking Protection (i.e TP sends a DNT=true regardless of the `privacy.donottrackheader.value` pref). RFP should do the same.
Flags: needinfo?(tom)
Flags: needinfo?(arthuredelstein)
Note: DNT is spec'ed as Opt-In: When the RFP UI eventually lands, the current Tracking Protection UI would need to be updated from the current option reading "Only when using Tracking Protection" to something like "Only when using Tracking Protection or Fingerprinting Protection" (might pay to update https://support.mozilla.org/en-US/kb/firefox-protection-against-fingerprinting )

Otherwise, since it's not documented or front facing yet, would there be any spec or legal issues doing this. Just asking :)
We'll triage this when we begin triage next month; but in general I agree we should do this.
Flags: needinfo?(tom)
Whiteboard: [fingerprinting]
I think this sounds like a good plan too. Thanks, Simon!
Flags: needinfo?(arthuredelstein)
Hi Tom!

Can you please help me out and assign a component, as you seem to be more familiar and experienced with this issue.
Flags: needinfo?(tom)
Component: Untriaged → DOM: Security
Flags: needinfo?(tom)
Product: Firefox → Core
Blocks: uplift_tor_fingerprinting
Priority: -- → P3
Whiteboard: [fingerprinting] → [fingerprinting][domsecurity-backlog1]
It seems I am late to this party. I am not convinced that we should set DNT=true with resist fingerprinting on, because DNT=true does essentially nothing to resist fingerprinting. It can basically get ignored by tracking servers and the user is as unprotected as without it. We should not come and beg to website owners to please not track us but provide privacy by design which is done by the features behind the `privacy.resistFingerprinting` preference.

We closed the "enable-Do-Not-Track DNT by default" as WONTFIX 6 years ago. For some debate about it, see: https://trac.torproject.org/projects/tor/ticket/5501. See https://trac.torproject.org/projects/tor/ticket/5545 as well.

So, please leave the statement that DNT is out of the privacy by design approach.
(In reply to Georg Koppen from comment #5)
> It seems I am late to this party. I am not convinced that we should set
> DNT=true with resist fingerprinting on, because DNT=true does essentially
> nothing to resist fingerprinting.

I don't see it as "DNT is needed to resist fingerprinting" but rather "A consistent value of DNT is needed or the DNT header itself provides one bit of fingerprinting information".

So the choice is either "Turn DNT off in RFP mode" or "Turn DNT on in RFP mode".  And between those two, I think it makes much more sense to turn it on.
Wouldn't enabling DNT in RFP mode simply make it easier to fingerprint users though? RFP mode meant to make people look like a normal Firefox LTS install which by default has DNT turned off. 
The minority of users have DNS on, whilst RFP mode is meant to make you look as much like the majority as possible so you can't be fingerprinted.

If you are worried about RFP mode conflicting with Tracking Protection then perhaps RFP mode should just enable tracking protection by default.
(In reply to Georg Koppen from comment #5)
> It can basically get ignored by tracking servers and the user is as unprotected as without it

Whether it helps or not is not the point

> We closed the "enable-Do-Not-Track DNT by default" as WONTFIX 6 years ago.

privacy.resistFingerprinting is not enabled by default

The choice between "Turn DNT off in RFP mode" or "Turn DNT on in RFP mode" is a no brainer. In order to unify RFP users to return the same DNT value, it needs to be "on", otherwise it conflicts with Tracking Protection and complicates matters.
(In reply to Spazturtle from comment #7)
> Wouldn't enabling DNT in RFP mode simply make it easier to fingerprint users
> though? RFP mode meant to make people look like a normal Firefox LTS install
> which by default has DNT turned off. 

Not really. RFP mode is meant to make a user look like every other user who is on the same OS and has RFP on.  There are too many differences between RFP mode and non-RFP mode that it's trivial to differentiate between an ESR user without RFP and a ESR user with RFP.  Also, the version spoofing is 'best effort' at best - feature detection can still reveal the real browser version.

> If you are worried about RFP mode conflicting with Tracking Protection then
> perhaps RFP mode should just enable tracking protection by default.

Tracking Protection is a good point. We need another bug like this for TP.  In practice, RFP is being driven towards being a PBM option, which has TP by default so only the users who disable it will stand out, but nonetheless we may want to hardcode an option for it (just like DNT...)
(In reply to Spazturtle from comment #7)
> Wouldn't enabling DNT in RFP mode simply make it easier to fingerprint users though?

No.

> RFP mode meant to make people look like a normal Firefox LTS install

Says who? RFP mode is meant to make the set of RFP users have the same fingerprint. It does not care about a normal FF install.

> The minority of users have DNS on, whilst RFP mode is meant to make you look as much like the majority as possible so you can't be fingerprinted.

The number of overall users with DNT on does not matter, it is only important that the RFP set of users be the same.
(In reply to Simon Mainey from comment #8)
> (In reply to Georg Koppen from comment #5)
> > It can basically get ignored by tracking servers and the user is as unprotected as without it
> 
> Whether it helps or not is not the point
> 
> > We closed the "enable-Do-Not-Track DNT by default" as WONTFIX 6 years ago.
> 
> privacy.resistFingerprinting is not enabled by default

It is enabled by default in Tor Browser and Tracking Protection is disabled.
 
> The choice between "Turn DNT off in RFP mode" or "Turn DNT on in RFP mode"
> is a no brainer. In order to unify RFP users to return the same DNT value,
> it needs to be "on", otherwise it conflicts with Tracking Protection and
> complicates matters.

I think you are mixing things up here. So, the first argument is it needs to be unified for RFP users. I am not sure if I buy that argument yet, but if so, then that argument alone does not imply that everyone having RFP on should send that header. The other argument is: it would conflict with Tracking Protection. But why is that an issue as the privacy guarantees are coming from the features which are behind the RFP mode (and FPI) and not some URL filtering or some DNT header sent? Tracking Protection is essentially orthogonal to FPI and RFP.
(In reply to Georg Koppen from comment #11)
> It is enabled by default in Tor Browser and Tracking Protection is disabled.

Sorry, I was talking about Firefox. What TBB wants is also relevant - this is the Tor Uplift after all :)

> So, the first argument is it needs to be unified for RFP users. I am not sure if I buy that argument yet

Its one bit of entropy. Unifying it makes sense.

> The other argument is: it would conflict with Tracking Protection...

From a Firefox end-user's perspective, it is simpler to unify with TP. If not, then a decision would have to be made which "feature" overrides the other: TP or RFP, and that makes it complicated. But I get your point.
(In reply to Simon Mainey from comment #12)
> > The other argument is: it would conflict with Tracking Protection...
> 
> From a Firefox end-user's perspective, it is simpler to unify with TP. If
> not, then a decision would have to be made which "feature" overrides the
> other: TP or RFP, and that makes it complicated. But I get your point.

If Mozilla does not want to make that decision it's no problem. You could introduce another preference which flipped would enable tracking protection, resist fingerprinting, dnt and what else you think belongs together. Mozilla could set that for Firefox if it really wants to and it would leave the resist fingerprinting preference for features that actually mitigate fingerprinting.
(In reply to Simon Mainey from comment #10)
> (In reply to Spazturtle from comment #7)
> > Wouldn't enabling DNT in RFP mode simply make it easier to fingerprint users though?
> 
> No.

Enabling DNT creates more bits of identifying data and puts you in a smaller pool of users which makes it easier for you to be fingerprinted, I don't see how giving trackers more information and narrowing down the list of people you could be to a small pool doesn't make it easier to track you.

> 
> > RFP mode meant to make people look like a normal Firefox LTS install
> 
> Says who? RFP mode is meant to make the set of RFP users have the same
> fingerprint. It does not care about a normal FF install.

Says the wiki page "Security/Fingerprinting". 
"The browser version is reported to be the most recent ESR version (but the OS is not spoofed)"

> > The minority of users have DNS on, whilst RFP mode is meant to make you look as much like the majority as possible so you can't be fingerprinted.
> 
> The number of overall users with DNT on does not matter, it is only
> important that the RFP set of users be the same.

No it isn't, the whole point of the setting is to make it harder to fingerprint users by making them look as generic as possible. If only the RFP set of users look the same then it is easy to fingerprint RFP users as sites might only get a single user who has RFP enabled, making it easy to pin point that user.
(In reply to Spazturtle from comment #14)
> (In reply to Simon Mainey from comment #10)
> > (In reply to Spazturtle from comment #7)
> > > Wouldn't enabling DNT in RFP mode simply make it easier to fingerprint users though?
> > 
> > No.
> 
> Enabling DNT creates more bits of identifying data and puts you in a smaller
> pool of users which makes it easier for you to be fingerprinted, I don't see
> how giving trackers more information and narrowing down the list of people
> you could be to a small pool doesn't make it easier to track you.

DNT has three values = true, false, undefined. *Enforcing* a value makes it harder to FP users, because all RFP users now return the same value. It's already easy enough to FP a user as an RFP user (eg inner + browser + screen + available screen measurements are in hundreds etc and a few other items). We're not trying to hide that RFP users are RFP users, we're trying to reduce entropy in the RFP set.
I agree with Simon. 

> If only the RFP set of users look the same then it is easy to fingerprint RFP users as sites might only get a single user who has RFP enabled, making it easy to pin point that user. 

This is unfortunate; but correct.
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.
Flags: needinfo?(gk)
Flags: needinfo?(arthuredelstein)
Whiteboard: [fingerprinting][domsecurity-backlog1] → [fingerprinting][domsecurity-backlog1][fp-triaged]
(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.

I still agree that locking the DNT state for RFP is a good idea. I suppose the policy could be "do not send the header at all", which is consistent with Georg's approach and also prevents entropy.

We also need to decide on the behavior of the JS API `navigator.doNotTrack`, which I just confirmed returns `1` in Tor Browser, even though "privacy.donottrackheader.enabled" is set to false. If we want to be consistent, maybe we need to delete the doNotTrack property from navigator altogether.
Flags: needinfo?(arthuredelstein)
I think it's way too messy and complicated to disable DNT with RFP. about:preferences#privacy options which (FF63) now have two options: "Always" or "Only when Firefox is set to block Detected trackers". We already have logic for "Always", so just enforce that. I also think disabling DNT with RFP goes against what the PB Mode devs are trying to achieve (Tracking Protection and thus DNT are enabled by default in PB Mode, and at some stage RFP will be a PB Mode option if not a mainstay).

Can we not put this behind a hidden pref, just like we did with privacy.resistFingerprinting.block_mozAddonManager. That way Tor can flip it: privacy.resistFingerprinting.block_DNT
(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.
Flags: needinfo?(gk)
(In reply to Arthur Edelstein (Tor Browser dev) [:arthuredelstein] from comment #18)
> (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.
> 
> I still agree that locking the DNT state for RFP is a good idea. I suppose
> the policy could be "do not send the header at all", which is consistent
> with Georg's approach and also prevents entropy.
> 
> We also need to decide on the behavior of the JS API `navigator.doNotTrack`,
> which I just confirmed returns `1` in Tor Browser, even though
> "privacy.donottrackheader.enabled" is set to false. If we want to be
> consistent, maybe we need to delete the doNotTrack property from navigator
> altogether.

That's in Firefox > ESR60, right? Because right now it still says "undefined" which sounds right to me given that the user has not made a choice in a vanilla Tor Browser.
(In reply to Simon Mainey from comment #19)
> I think it's way too messy and complicated to disable DNT with RFP.
> about:preferences#privacy options which (FF63) now have two options:
> "Always" or "Only when Firefox is set to block Detected trackers". We
> already have logic for "Always", so just enforce that. I also think
> disabling DNT with RFP goes against what the PB Mode devs are trying to
> achieve (Tracking Protection and thus DNT are enabled by default in PB Mode,
> and at some stage RFP will be a PB Mode option if not a mainstay).
> 
> Can we not put this behind a hidden pref, just like we did with
> privacy.resistFingerprinting.block_mozAddonManager. That way Tor can flip
> it: privacy.resistFingerprinting.block_DNT

Could we keep the resist fingerprinting preference for things that *really* resist fingerprinting and not mix it up with other stuff that is orthogonal to it? See my comment:13 for a proposal.

(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.

Severity: normal → S3

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

Status: UNCONFIRMED → RESOLVED
Closed: 10 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.