Font fingerprinting defenses roadmap (parent ticket)
Defending against font fingerprinting is complex. We have to worry about distinguishing attacks via differing installed font sets, text rendering engine differences, and font variants. There are a variety of tickets involved. This ticket is to track our progress.
Here's an overview of our approach:
In #13313 (moved), we introduced a Tor Browser pref, "font.system.whitelist", which accepts a list of fonts and excludes all others from the browser. We introduced a separate whitelist for OS X, Windows, and Linux. (For the Linux Tor Browser bundle, we do not use the "font.system.whitelist" pref. Instead we bundle all fonts and use a
fonts.conf file to restrict the browser to use only the bundled fonts.)
src:local (#17759 (moved)) queries and also the Canvas
font property. It does not prevent an attacker from identifying the operating system, nor from distinguishing two versions of an operating system by detecting different variants of the same font.
In #16707 (moved) we whitelisted a largish set of fonts for Windows and OS X that are shipped with the operating system by default. In #17220 (moved) we added some standard Math fonts to the whitelist. And in #17250 (moved) and #17661 (moved), we expanded the font whitelist to include UI fonts found on some versions of Windows and OS X. See also #17999 (moved).
David Fifield (dcf) wrote a script that fingerprints the user by measuring the bounding box of glyphs at certain code points. We found that different flavors of Linux render the same fonts differently and thus produce different fingerprints. We also expect different versions of Windows and Mac to also be distinguishable by font metrics. For the Linux case, we hope to adjust rendering settings and/or bundle rendering libraries to make the flavors indistinguishable: see #16672 (moved).
We might also be able to reduce the effectiveness of fingerprinting attacks on all platforms by only allowed a limited number of font queries per URL bar domain: see #16312 (moved).
Our #13313 (moved) patch whitelists fonts by name, so it likely allows a font installed on the system to supersede a font bundled with the browser if they have the same font name. So we would consider changing the patch to whitelisting by font filename or restricting allowed directories for font loading: see #16739 (moved).