Fingerprinting resistance

[pes10k]

Most browsers have a variety of similar-but-different fingerprinting protections, which make things unpredictable for site authors and cause web-compat problems on all browsers.

This deliverable would be for PrivacyCG to (i) document, (ii) standardize and (iii) extend these fingerprinting protections.

This deliverable would aim (i) to give web authors had a common set of expectations to target, (ii) make it easier for browser users to understand protections in platform, and (iii) reduce web compat problems fingerprinting protections cause, though a "strength in numbers" approach.

A "fingerprinting resistance mode" wouldn't need to be an explicit "mode" either. Some vendors might wish to have "fingerprinting resistance" enabled all the time, others might alias it with "private browsing", etc.

[othermaciej]

Maybe the deliverable should just be "fingerprinting resistance" and we shouldn't start with the assumption that it's a mode. If some vendors only choose to offer it as a mode, that's up to them. But web standards should mainly be about the default mode.

[othermaciej]

There's a variety of methods I'm aware of to reduce fingerprintability. Here I focus mainly on web platform observables, and not fingerprinting at the network layer, though perhaps that should be discussed as well.

When a web platform feature provides cross-user or cross-device variation that can be used to fingerprint, the following methods can be applied:

(1) Always give the same answer, or only a few distinct answers that correlate with other available information. But the answer is still accurate. For example, Safari's approach to installed font fingerprinting is to hide user-installed fonts and only expose fonts that come with the system. Then all devices in a broad class give the same answer.

(1a) Like (1) but in some way limited to known/suspected fingerprinters. This allows giving answers that are consistent but possibly inaccurate.

(2) Cause some operations that expose variability to fail, throw an exception, or return an error.

(2a) Like (2) but in some way limited to known/suspected fingerprinters. For example, throw or return all zeros on attempts to read back bits from a canvas.

(3) Remove some web platform features entirely. For example, the ability to enumerate devices without user permission in WebRTC is not necessary for its use cases.

(4) Inject deliberate noise into certain info channels. For example, add random tokens to the user agent string so that hashing it gives a different result every time. Or add undetectable pixel noise to canvas read back. A challenge here is that if noise addition is done at scale, trackers may figure out how to remove enough noise to get only a clean signal back.

Maybe there are others?

It may be worthwhile to start by designing common solutions, but ultimately many should be fed back into core web standards.

[hober]

Did you mean to file this as a proposal? I can move it if so.

[pes10k]

@othermaciej

I like your taxonomy, I wrote up a similar one too. The only think I'd add yours are threshold / budget style approaches (Privacy Budget and PrivacyBadger for examples). I don't think that is a promising approach, but worth noting maybe.

It may be worthwhile to start by designing common solutions, but ultimately many should be fed back into core web standards.

I think this all makes sense, but I'm proposing this effort here partially out of frustration with trying to deal with the WG's that own the relevant specs, and seeing how hesitant they have been to address harms they've introduced.

To my mind, a good strategy would be (I think 100% compatible with what you're saying, maybe just diff emphasis):

1. Design and implement common FP protections (even if they're floors) among interested vendors
2. Make formal objections to new versions of the relevant specs until the FP surface has been dealt with in the spec

[pes10k]

@hober yes, thanks! (and apologies, won't make the error again)

[hober]

Marked agenda+ per discussion in #privacycg slack.

[othermaciej]

The only think I'd add yours are threshold / budget style approaches (Privacy Budget and PrivacyBadger for examples). I don't think that is a promising approach, but worth noting maybe.

Agreed, both that it's worth noting and that it may not be very promising.

2. Make formal objections to new versions of the relevant specs until the FP surface has been dealt with in the spec

I think we should start with milder forms of feedback on the relevant specs, such as filing issues. If there is cross-browser agreement on a change, it shouldn't be that hard to get it in. Also WHATWG doesn't have such a thing as formal objections, and many changes will likely need to be in specs developed there. (There is a way to appeal to the Steering Group but it's never been used and I hope it stays that way).

I'm wondering if this has overlap with PING work to do privacy reviews of existing specs.

[pes10k]

I think we should start with milder forms of feedback on the relevant specs, such as filing issues.

Most definitely :) I was jumping a head one step ahead in my head based on past experience, but you're def right, issues first!

[AramZS]

While I agree consistent fingerprinting resistance makes sense I think there is a need to be aware of the current use-cases in the marketplace that may need some degree of support in the future. The question here is how (or if) to retain some degree of anti-fraud protection which is one of the (theoretically) privacy-respecting ways that fingerprinting is being used. Even if the position is "we don't want to support that use case" we should still be aware of it and be able to articulate why not and if there is an interest in presenting an alternative.

[hober]

Hi @pes10k! Any appetite to come back to this? I think the anti-fingerprinting browser feature landscape has changed at least some in the last couple of years.

[pes10k]

I think there is probably less need for this, since PING and TAG (at least it seems to me) have been more aggressive (in a good and welcome way) in preventing passive fingerprinting surface for winding up in new proposals.

If vendors would be interested in a "fingerprinting resistance" mode to standardize privacy protections to deal with legacy features, though, that could be useful, especially all browsers have some "tracking resistance" mode now, though with different names and framing.

Are other vendors interested? If so, i think its worth continuing this; if not, i think fine to archive and close.

[annevk]

Mozilla would certainly be interested in exploring this space further. Ideally things that can be shipped to all users, but engine-wise we have some support for opt-in fingerprinting resistance as well.

cc @tomrittervg

[spanicker]

Chrome doesn’t have a resist fingerprinting mode right now, but we’re happy to join the conversation.