In #13313 (moved), we introduced a patch to restrict the fonts allowed to be loaded in Tor Browser. But different versions of the same font could still be used to distinguish users. We could potentially limit the damage by introducing a second patch that restricts the number of allowed font requests per URL bar domain.
Previously we had a patch for #2872 (closed) that worked something like this, although it wasn't tied to URL bar domain.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
I haven't lost sight of #13313 (moved) but I'll have to page in a lot of information in order to resume working on it. It would be good to have someone else try the patches there and help figure out how to fix the problems with it.
I think #13313 (moved) is our plan here for the immediate future, but it is going to increase the bundle sizes by 15MB, not 3.. I am retitling this ticket to represent the approach mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1121643, in case we decide that the 15MB is not worth it for some reason.
In the meantime, I am taking this ticket off of our 5.0 radar in favor of #13313 (moved).
Trac: Resolution: N/Ato duplicate Summary: font limit patch to Limit fonts to a whitelist? Status: assigned to closed Keywords: ff38-esr, tbb-5.0a-highrisk, tbb-5.0a4 deleted, N/Aadded
In #13313 (moved), we introduced a patch that more or less implements a pref like the one described in https://bugzilla.mozilla.org/show_bug.cgi?id=1121643. If we decide in the long term not to bundle fonts (because 15 MB is too much), this pref, "font.system.whitelist", could also be used to expose a restricted set of pre-installed system fonts.
Trac: Description: Until we land #13313 (moved), we need a font limiting patch for the ESR38 version of Tor Browser, because it wasn't really feasible to port the patch for #2872 (closed). I would suggest a patch that limits font usage per url bar domain.
to
In #13313 (moved), we introduced a patch to restrict the fonts allowed to be loaded in Tor Browser. But different versions of the same font could still be used to distinguish users. We could potentially limit the damage by introducing a second patch that restricts the number of allowed font requests per URL bar domain.
Previously we had a patch for #2872 (closed) that worked something like this, although it wasn't tied to URL bar domain. Summary: Limit fonts to a whitelist? to Limit font queries by URL bar domain
In a paper (I'll dig up the reference if required), it was shown that the most fonts used (legitimately?) by sites (using an Alexa top sites listing) was around 30, with one site using close to 50. Most were 10 or under. Without the reference to hand, I do not know for sure that they were only counting installed fonts. But where would you draw the line vs breakage. I assume the analysis excluded FPing scripts that have a font component (e.g fingerprintjs2 starts at 60+ fonts). It would be interesting if OpenWPM could return anything meaningful on installed font queries per site
I also wonder how easy this would be to bypass - I can think of a number of ways: i.e I am thinking about what happens on subsequent domain pages in the same session, or sub-domains, etc - do I get another free hit? Additionally, by using targeted font lists, I can still get all the entropy possible that I know of (e.g. within TB Window users I only need five or six fonts: and you can't hide that you are the Tor Browser on Windows, and I will always come in under your limit).
Limiting the installed fonts used per whatever (domain, sub-domain, eTLD+1?) and per session might make it harder for current FPing scripts, but will ultimately not hold up. The only real solution, IMO, is for all users to have the same identical bundled fonts (different per OS if need be) as this also mitigates other font FPing techniques.
However, given that bundling all fonts for all users might beis a pipe-dream, this would probably be the next best measure, certainly upstream for Firefox RFP users .. assuming it's even feasible (IDK think if it is)