1863574 - Disable font fingerprinting protection if a user has unchecked "Allow pages to choose their own fonts"

Status: VERIFIED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Install some non-default font, e.g. on Ubuntu, sudo apt install fonts-sixtyfour to get a retro-looking font.
2. Start Firefox with a fresh profile, and go to about:preferences
3. Search preferences for "Font" and click "Advanced"
4. For the "Serif"/"Sans-serif"/"Monospace" dropdowns, choose your just-installed font (C-64 in my case)
5. Uncheck "Allow pages to choose their own fonts"
6. Open a new tab and go to https://example.org/ to be sure your font selection took effect.
7. Open a new private window and go to https://example.org/

ACTUAL RESULTS:
The private window doesn't use your specified font.

EXPECTED RESULTS:
The private window should use your specified font.

This is related to bug 1849903. It feels like overkill to apply that protection to users who have checked the box to not allow websites to choose their own fonts, because:
(A) it's annoying/surprising -- those users have expressed an explicit preference for a particular very-small set of fonts, and it's odd for them to tell Firefox that preference, and then for Firefox to just ignore them (particularly if they're browsing in "permanent private browsing" mode).
(B) the intervention is arguably ineffective -- those users have opted in to a different category of fingerprintability already by unchecking the checkbox (comment 5). They won't be exposing most of our "standard/default" allow-list of fonts to the web, so they're already going to look different from other default installations.

(This might be what's going on in bug 1861196, but I'm not entirely sure.)

Comment 1

[Daniel Holbert [:dholbert]]

Note: I can work around this bug (and get EXPECTED RESULTS) by toggling about:config pref privacy.fingerprintingProtection.pbmode to false, OR (more targeted) by creating about:config pref privacy.fingerprintingProtection.overrides and setting it to
-FontVisibilityLangPack.

I think ideally, we would effectively do the same thing as setting -FontVisibilityLangPack, specifically when this "Allow websites to choose their own fonts" checkbox is unchecked.

(We would need to take some care to update our behavior when that box is checked/unchecked, too -- I think this font-fingerprinting pref stuff is mostly initialized at startup time, which is ~fine since it's not configurable via the UI and not expected to dynamically change. But once this protection becomes partially-configurable via this checkbox, we need to be sure it gets disabled/reenabled as the checkbox is unchecked/checked, without requiring a restart.)

Comment 2

[Tom Ritter [:tjr] (OOTO until 9/2)]

(In reply to Daniel Holbert [:dholbert] from comment #1)

(We would need to take some care to update our behavior when that box is checked/unchecked, too -- I think this font-fingerprinting pref stuff is mostly initialized at startup time, which is ~fine since it's not configurable via the UI and not expected to dynamically change. But once this protection becomes partially-configurable via this checkbox, we need to be sure it gets disabled/reenabled as the checkbox is unchecked/checked, without requiring a restart.)

We're all dynamic here, even if you flip the pref while pages are open it will cause them to get reflowed with the new settings.

The question here is if we should take the 'Allow websites to choose their own fonts' checkbox as a user override on the fingerprinting behavior. It seems reasonable to me, but I definetly want to get thoughts from Tim, Martin...

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to Tom Ritter [:tjr] from comment #2)

We're all dynamic here, even if you flip the pref while pages are open it will cause them to get reflowed with the new settings.

(Not entirely, as it turns out; see bug 1863624 which I just filed. But that's a separate issue.)

Comment 5

[Daniel Holbert [:dholbert]]

In comment 0 and in the bug summary, I was proposing additional-permissiveness based on the "Allow pages to choose their own fonts" checkbox.

But it feels slightly odd to make this conditional on that. Maybe really we should just generally give "special dispensation" to always allow the user's selected default-fonts to be used, regarldess of whether they're on our fingerprinting-protection system-font allow-list?

(This does partially-defeat font-fingerprinting protections, but as discussed at the end of comment 0, it'd be in a non-default configuration where a user is already opting in to increase their fingerprintability. Really, any user selection in Firefox's "default font" UI will impact their fingerprintability, whether the user chooses a local font or a system font -- pages can just measure the metrics of the user's default font, and use that as a means of distinguishing between users who have selected Calibri vs. Arial vs. something else as their default font. If the user happens to pick a local font, it'll be a somewhat larger increase in fingerprintability, but it's an increase either way, and it feels like we should honor the user choice here.)

Comment 6

[Martin Balfanz [:mbalfanz]]

We discussed this issue within the team and agree that we should respect the user choice. At the same time, we want to inform users that a custom font choice can increase their fingerprintability. We'll add this to our task list and will look into the details.

Comment 7

[Jonathan Kew [:jfkthame]]

(In reply to Daniel Holbert [:dholbert] from comment #0)

This is related to bug 1849903. It feels like overkill to apply that protection to users who have checked the box to not allow websites to choose their own fonts, because:
(A) it's annoying/surprising -- those users have expressed an explicit preference for a particular very-small set of fonts, and it's odd for them to tell Firefox that preference, and then for Firefox to just ignore them (particularly if they're browsing in "permanent private browsing" mode).
(B) the intervention is arguably ineffective -- those users have opted in to a different category of fingerprintability already by unchecking the checkbox (comment 5). They won't be exposing most of our "standard/default" allow-list of fonts to the web, so they're already going to look different from other default installations.

Actually, (B) here isn't entirely true; depending on the approach used, it's still possible to do font fingerprinting even when "Allow pages to choose their own fonts" is turned off. So the anti-font-fingerprinting protection does still serve some purpose.

(Note that turning off the use_document_fonts pref causes us to prioritize the user's chosen fonts, but does not necessarily eliminate any use of other fonts; they will still be used if necessary for fallback.)

Ideally, I think we'd only remove the restriction from fonts that they've explicitly requested in prefs, rather than disabling it altogether. (But haven't dug into the code yet to see how feasible that looks.)

Comment 8

[Jonathan Kew [:jfkthame]]

Actually, maybe the solution here is really simple: just don't apply visibility restrictions when resolving CSS generics via the font prefs (without reference to the use_document_fonts setting).

Usually those prefs resolve to standard system fonts like Times and Arial, but if the user has customized them then presumably they really do want to use their chosen fonts instead -- both for content that isn't explicitly styled (so just uses the default), and if they've also turned off "Allow pages to choose...", then for all web content, overriding the page designer's choices.

So if the font name came from resolving a generic, rather than being explicitly requested by the page, we should always regard it as available.

Comment 9

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1863574 - patch 2 - Create an RFPTarget option to control whether the resolution of CSS generics is subject to font-visibility restrictions. r=tjr,#layout

Comment 10

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1863574 - patch 1 - Fix typo 'Fingerinting' in nsRFPService code. r=tjr

No functional change.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/faa11ed2907c
patch 1 - Fix typo 'Fingerinting' in nsRFPService code. r=tjr
https://hg.mozilla.org/integration/autoland/rev/e97fdef60f19
patch 2 - Create an RFPTarget option to control whether the resolution of CSS generics is subject to font-visibility restrictions. r=jwatt
https://hg.mozilla.org/integration/autoland/rev/4097494f85fc
apply code formatting via Lando

Comment 12

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/faa11ed2907c
https://hg.mozilla.org/mozilla-central/rev/e97fdef60f19
https://hg.mozilla.org/mozilla-central/rev/4097494f85fc

Comment 13

[Daniel Bodea [:danibodea]]

I have reproduced this issue in Release v121.0 and 121.0.1 and verified the fix in Beta v122.0b7 and Nightly v123.0a1 using the steps in comment 0 in Ubuntu 22.