Fingerprinting v3: Font Fingerprinting

tildelowengrimm commented 6 years ago

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 commented 5 years ago

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

i imagine implementation would be something like:

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

pes10k commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

"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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

"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 commented 5 years ago

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 commented 5 years ago

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

ghost commented 5 years ago

default fonts to region

What do you mean?

pes10k commented 5 years ago

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

ghost commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.

tildelowengrimm commented 5 years ago

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 commented 5 years ago

yep yep, unless the site fetched the font itself

pes10k commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Example of popular deployed lib that uses font-based fingerprinting

jeroenev commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

kristian-welsh commented 5 years ago

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

diracdeltas commented 5 years ago

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 commented 4 years ago

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

Reduce entropy: When shields are up, restrict websites to system (i.e. OS provided) fonts
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 commented 4 years ago

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 commented 4 years ago

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:

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

g4gg433 commented 3 years ago

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.

Font fingerprinting in combination with #720 and TCP stack fingerprinting is enough to identify virtually anyone considering the main demographic of users who'd want to use this browser. You have a non-negligible user base you should easily be able to see this.

The only way to "fix" those "bugs", without throwing millions of dollars into forking Chromium, is to use Firefox as a base, this has been proven scientifically by the federally funded Tor project 10 years ago (which means now days it'd probably cost 10¹⁰ times more).

affffc commented 3 years ago

Any update on this? This is the main reason Firefox is better for privacy than Brave. Well this and container tabs.

pes10k commented 2 years ago

Just to follow up here, this is getting close (screenshot demonstrates font fingerprint randomization)

babafc commented 2 years ago

Hello why is this closed? Someone who is on Windows/Mac wouldn't need a browser with "fingerprinting protection". For Mac Safari already does it and Macs are standardized anyway. For Windows these people are running Windows so the last they should worry about is privacy.

I understand there is no "default" Linux font pool but Firefox is able to prevent font fingerprinting on all desktop platforms.

pes10k commented 2 years ago

I understand there is no "default" Linux font pool but Firefox is able to prevent font fingerprinting on all desktop platforms.

This is closed because we are not aware of a policy we could enable by default on linux that we think would have acceptable breakage-risk, and because the parts we do have a path forward on (linux and MacOS) are implemented and shipped.

We're still considering options on linux, even if we're not sure there is a way forward there. Once we have an idea we think we can enable by default though, we'll create a follow up ticket and continue there

babafc commented 2 years ago

Well ig that makes Brave useless on Linux since fonts are an incredibly high entropy vector, especially with developers installing custom fonts even worse the rendering behaviour.

pachainti commented 2 years ago

Any update on this? This is the main reason Firefox is better for privacy than Brave. Well this and container tabs.

I agree. Brave provides many protections against particular types of fingerprinting, while this simple possibility of attack is still unresolved.

aocorporation commented 1 year ago

Any update on this? This is the main reason Firefox is better for privacy than Brave. Well this and container tabs.

I agree. Brave provides many protections against particular types of fingerprinting, while this simple possibility of attack is still unresolved.

I find that this argument is pretty weak. Brave has a lot that Firefox does not offer still. For clarification, I would like this issue to be prioritized in fixed. But still.

pes10k commented 1 year ago

Addressed here: https://github.com/brave/brave-browser/issues/11770#issuecomment-1676032746

brave / brave-browser