Brave-browser: Fingerprinting v3: Font Fingerprinting

[tomlowenthal]

re https://github.com/brave/brave-browser/issues/11770

default protection:

• Reduce entropy: When shields are up, restrict websites to system (i.e. OS provided) fonts
• Farbling / randomize fingerprint: Also bundle a small number of additional fonts that are i) looked for by fingerprinting scripts and ii) have OSS or similar licenses so that we can bundle them. We will then use the farbling seed to change the font fingerprints detected by common fingerprinting scripts, to extend the farbling protections

max protection: Same as above

[diracdeltas]

this is probably near the top of priority WRT fingerprinting protection according to tests like panopticlick.

i imagine implementation would be something like:

1. Internally get the list of fonts available on the system
2. Intersect (1) with the 10 or so most commonly-supported fonts
3. If intersection is nonzero, report the intersection. Otherwise report the single font which is available that is the most commonly supported

[pes10k]

A similar, maybe simpler, option would be to just hard code a set of supported fonts for each supported platform, and always report those being installed.

This is what Safari does FWIW for FP detection
https://trac.webkit.org/changeset/225641/webkit

If the above sounds acceptable, that could be a pretty quick, Shields up option

[diracdeltas]

@snyderp what if the underlying platform doesn't actually support one of those hardcoded fonts?

should this be tied to fingerprinting protection or on in general? i think @bradleyrichter or someone voiced concern about having limited fonts generally

[pes10k]

@diracdeltas "doesn't actually support one of those hardcoded fonts" would be in the case of someone deleting a default system front from their machine? Possible, but a def edge case. Could be intersection of available fonts and platform default fonts then. I bet having a deleted system font though is pretty dang identifying though.

I'm in favor of tying to shields in general, but no strong pref either way. Either is better than the SQ, and easy to change one way or the other if things get wacky in dev / beta.

Re @bradleyrichter, i think (🤞) that sites will include non-default fonts when they're not available on the system, so there would only be a perf hit for uncommon-but-installed fonts, shouldn't be user-visable

[diracdeltas]

"doesn't actually support one of those hardcoded fonts" would be in the case of someone deleting a default system front from their machine? Possible, but a def edge case.

Don't fonts vary a lot between Linux distributions for instance?

[pes10k]

ah, yea, derp, good point.

what about one of the below?
1) Survey of whatever linux distros are used to download brave, till we get to the 20% long tail or so, and special case those
2) Just assume everyone at least uses msttcorefonts (no idea if this is accurate, good idea, or whats done in non-English locals…)
3) Leave linux as is, and handle on window and mac to handle at least the common cases?

[pes10k]

2 above might not be a horrible idea actually, since i'd guess (?) that sites are not being built assuming odd ball linux fonts are in place (we could crawl + test if this seems shaky)

[ghost]

"doesn't actually support one of those hardcoded fonts" would be in the case of someone deleting a default system front from their machine? Possible, but a def edge case. Could be intersection of available fonts and platform default fonts then. I bet having a deleted system font though is pretty dang identifying though.

I agree. An edge case not worth increasing "fingerprintability" over.

Don't fonts vary a lot between Linux distributions for instance?

Fonts matter because they tell the server what fonts the device supports. How about having the same approach as Safari and translating the fonts on the browser level? If the browser sends an unrecognized serif font, display default serif font (obviously this could be way more precisely mapped in practice).

[diracdeltas]

I would like to address Linux in our first iteration of this since that's where some of our most privacy-conscious users are. (people who actually turn on all fingerprinting protection, etc.)

[pes10k]

okie dokie. Maybe we could default fonts to region then, at least on linux. So that there is no additional fingerprint entropy

[ghost]

default fonts to region

What do you mean?

[pes10k]

advertising a different set of system fonts, depending on if the user language is en vs cn etc

[ghost]

Why wouldn't this:

How about having the same approach as Safari and translating the fonts on the browser level? If the browser sends an unrecognized serif font, display default serif font (obviously this could [...]).

work?

[pes10k]

Not sure what you mean by "the browser sending a font", but all browsers already have fall back fonts. The question isn't what to do when the site requests a unknown font; its what to do when the site requests an uncommon font the browser knows about

[ghost]

its what to do when the site requests an uncommon font the browser knows about

Only advertise that the browser supports certain fonts. In the uncommon case that the browser receives one of these common fonts that the user doesn't have on his machine, fall back to the closest one in the intersection @diracdeltas described.

[tomlowenthal]

Just to be clear: if a site tries to use an uncommon font which _is_ installed, we'd still fall back to a generic rather than displaying it, correct?

[pes10k]

yep yep, unless the site fetched the font itself

[pes10k]

For future ref

Chromium docs for font matching

https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/platform/fonts/README.md#Font-Matching

W3C spec for how font matching should happen

https://drafts.csswg.org/css-fonts/#font-style-matching

System level implementation for determining system fonts

https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/skia/font_cache_skia.cc
https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/mac/font_cache_mac.mm
https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/linux/font_cache_linux.cc
https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/android/font_cache_android.cc

[ghost]

Just to be clear: if a site tries to use an uncommon font which is installed, we'd still fall back to a generic rather than displaying it, correct?

Assuming JS can detect the displayed font, yes.

In what ways are fonts leaked? Displayed font and supported fonts (both using JS)?

[pes10k]

https://cdn.tinypass.com/api/libs/fingerprint.js

Example of popular deployed lib that uses font-based fingerprinting

[jeroen7s]

For linux, can't you use a standard set of common fonts in Brave, or choose a standard set that's used on Ubuntu and download missing fonts for other Linux Distro's? So they are fixed and can't break fingerprinting?

[pes10k]

Yep yep! The solution we're aiming for is a combination of identifying the core set of fonts expected on each platform, and then having the browser lie about the presence of any other fonts on the system (i.e. tell the website the client doesn't have them installed, even if they do)

[Miyayes]

+1 https://www.reddit.com/r/brave_browser/comments/cjteen/why_is_brave_still_vulnerable_to_fonts/

[kristian-welsh]

Is there anything blocking this right now? Do we need to decide on a list of core fonts per OS?

[diracdeltas]

Is there anything blocking this right now? Do we need to decide on a list of core fonts per OS?

i believe that is still needed. @snyderp got pulled away for other work

[pes10k]

Just a quick update on this. The new plan here is to do the following:

1. Reduce entropy: When shields are up, restrict websites to system (i.e. OS provided) fonts
2. Confuse via farbling: Also bundle a small number of additional fonts that are i) looked for by fingerprinting scripts and ii) have OSS or similar licenses so that we can bundle them. We will then use the farbling seed to change the font fingerprints detected by common fingerprinting scripts, to extend the farbling protections

No timeline yet. Not because we dont want to get this addressed, but because we think the farbling work has bought us a lot of space here while the fingerprinters catch up, and so we're prioritizing other high-urgency privacy+webcompat issues (more clever 3p storage management, other ways of generating privacy-preserving resource replacements, bounce tracking, etc). But, just want to make clear that this hasn't fallen off our radar, and that we're not getting lazy re-privacy; font fingerprinting just isn't where the marginal improvement is highest at the moment.

Updates to come!

[varenc]

Thanks for this update!

Though regarding this...

we think the farbling work has bought us a lot of space here while the fingerprinters catch up

The other farbling work is all for naught if you're a user that can be uniquely identified based solely on your list of fonts. Any designer/font nerd with ~10 unusual fonts could be caught by this. I'd be one of them. IMHO this should warrant a bump in priority since it's pretty sad using Brave and having amiunique.org tell me I'm unique just based on my font list. (I have an extension that tries to block font fingerprinting, but it has issues)

[pes10k]

uniquely identified based solely on your list of fonts

I appreciate your point here, but I think we're going to stick with the current prioritization for 3 three reasons:

1. as nasty as font fingerprinting is, its not as nasty as storage based tracking (and needing to turn off shields to unbreak sites). So i think https://github.com/brave/brave-browser/issues/8514 is likely to have the biggest privacy + webcompat win at the moment
2. Addressing font fingerprinting in chromium (I expect in WebKit and Gecko too, though I haven't checked) requires pretty deep changes, to make sure we address all the different ways fonts can be queried (canvas, WebGL, CSS), and so getting this don't will take a while, so its ideal to get other (slightly?) lower hanging fruit first
3. I really encourage you to not understand amiunqiue.org in that way. Seeing your unique for one or a small number of values on a simulated test like this does not give you a good understanding of how unique you are to trackers, who nearly universally consume a large number of inputs (bc any "successful" tracker will need to distinguish a much larger number of users than amiunqiue.org sees). As long as a tracker consumes at least one of Brave's farbled endpoints, you should consider yourself well protected against the vast majority of trackers.

None of the above is to disagree, or say that font fingerprinting isn't a concern; we all 100% agree with you that its another hole we need to close. We're just scheduling this way bc we don't think its where the biggest "bang for the buck" lies at the moment for privacy improvements.

P.S. you might be interested to know that Brave has been working with the CSS working group in W3C to figure out a standards based solution too. See https://github.com/w3c/csswg-drafts/issues/4497 and https://github.com/w3c/csswg-drafts/issues/4055 for example.