1850275 - Firefox 116.0.3 doesn't respect layout.css.font-visibility.*

Status: RESOLVED INVALID

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

Description

[HCT]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0

Steps to reproduce:

setting layout.css.font-visibility.* to level 3 with Resist Fingerprinting and Tracking Protection enabled

Actual results:

Firefox 116.0.3 about:preferences allows user to select user-installed fonts, but web page doesn't use any user-installed fonts unless I copy the same user-installed fonts into <firefox_installed_directory>/fonts

downgrading back to 115.0.2 and layout.css.font-visibility.* settings are respected again. looks like something changed (didn't see anything mentioned in 116.0.x release notes) or a regression of 116.0.3

Expected results:

Firefox 115.0.2 and older versions respect layout.css.font-visibility.* and uses user-installed fonts when appropreiate

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Tom S. (please needinfo tschuster)]

Since bug 1847599 enabling privacy.resistFingerprinting automatically forces the OS base fonts. This can not be overwritten.

Comment 4

[HCT]

@Tom S, you removed these configurations and their functions with your "enhancement patch" in bug 1847599, then say setting cannot be overwritten. this seems contradicting to me

Comment 5

[Thorin [:thorin]]

this seems contradicting to me

Not at all. The pref layout.css.font-visibility.resistFingerprinting controlling RFP's level was removed in Bug 1838415.

The remaining prefs ( layout.css.font-visibility.private, layout.css.font-visibility.standard, layout.css.font-visibility.trackingprotection have never controlled RFP's font vis. The level is/was determined in normal windows as first applicable: RFP over TP over Standard and in Private Browsing as the most restrictive between normal and private. This is now a little hand wavy, what with FPP and ETP etc - wait and see how it shakes out.

As far as I'm concerned this is working as intended, and it actually hardens RFP's level edit: to change RFP levels you need to use RFPTargets IIUIC

Comment 6

[HCT]

(In reply to Simon Mainey from comment #5)

The remaining prefs ( layout.css.font-visibility.private, layout.css.font-visibility.standard, layout.css.font-visibility.trackingprotection have never controlled RFP's font vis. The level is/was determined in normal windows as first applicable: RFP over TP over Standard and in Private Browsing as the most restrictive between normal and private. This is now a little hand wavy, what with FPP and ETP etc - wait and see how it shakes out.

As far as I'm concerned this is working as intended, and it actually hardens RFP's level edit: to change RFP levels you need to use RFPTargets IIUIC

as far as I can see, I have been able to use user installed font with RFP up until Firefox 115 and Firefox 116 broke it. there are reason user choose to use user installed font with RFP enabled due to few other long time Firefox bugs with no fixes in sight

the thing on 116 is now really confusing. pre-116, you won't be able to select or see a font if your privacy config doesn't allow the font to be used. on 116, you can see and select the fonts you want, but Firefox just won't use it because some new code make that decision and ignore your config

Comment 7

[Thorin [:thorin]]

How did you use a user installed font with RFP in FF115 and earlier?

• What is your OS, what is the font, where is the font (e.g. in the bundled fonts dir?), what was your RFP font-vis setting?

Bypassing RFP's settings to undermine your own font fingerprint is not how RFP should work. If you can't handle RFP, then don't use it - it's not front facing in Firefox (and never will be). You are better off using FPP when it's ready

Comment 8

[Tom Ritter [:tjr]]

(In reply to HCT from comment #6)

as far as I can see, I have been able to use user installed font with RFP up until Firefox 115 and Firefox 116 broke it

We should better understand how this happened. I wonder if it is related to my experience in Bug 1835289.

HCT - it sounds like you were able to find a corner case where the intended behavior was not working as expected. When we rearchitected things, the intended behavior began to work and the corner case ceased.

there are reason user choose to use user installed font with RFP enabled due to few other long time Firefox bugs with no fixes in sight

Just to better understand the use case, could you point us to these bugs?

the thing on 116 is now really confusing. pre-116, you won't be able to select or see a font if your privacy config doesn't allow the font to be used. on 116, you can see and select the fonts you want, but Firefox just won't use it because some new code make that decision and ignore your config

That is not ideal, especially since this behavior will also affect FPP. So we will need to dig into that as well.

Comment 9

[Tom Ritter [:tjr]]

Bug 1851278 may be related

Comment 10

[Fatih Kilic [:fkilic]]

Tom S is right, RFP targets take precedence over layout.css.font-visibility. See the following from nsPresContext.cpp#771-794

  int32_t level;
  // Rule 3
  if (mDocument->ShouldResistFingerprinting(
          RFPTarget::FontVisibilityBaseSystem)) {
    // Rule 2: Check RFP pref
    // This is inside Rule 3 in case this document is exempted from RFP.
    // But if it is not exempted, and RFP is enabled, we return immediately
    // to prevent the override below from occurring.
    if (nsRFPService::IsRFPPrefEnabled(isPrivate)) {
      mFontVisibility = FontVisibility::Base;
      return mFontVisibility != oldValue;
    }

    level = int32_t(FontVisibility::Base);
  }
  // Rule 4
  else if (mDocument->ShouldResistFingerprinting(
               RFPTarget::FontVisibilityLangPack)) {
    level = int32_t(FontVisibility::LangPack);
  }
  // Rule 5
  else {
    level = StaticPrefs::layout_css_font_visibility();
  }

We could check Preferences::HasUserValue("layout.css.font-visibility") and re-set the level to it but I'm not sure if this is desired. Also we use layout.css.font-visibility for exempted websites, so we'll probably need a new pref but at that point, it is easier for a user to set their prefs to

privacy.resistFingerprinting = False 
privacy.fingerprintingProtection = True
privacy.fingerprintingProtection.overrides = +AllTargets,-FontVisibilityBaseSystem,-FontVisibilityLangPack

I think setting the prefs as above also conveys the user is doing a privacy tradeoff.

Comment 11

[Fatih Kilic [:fkilic]]

Do you believe the solution I mentioned above works for you? If so, should we close the issue?

Comment 12

[HCT]

this bug was opened more than a year ago. I have been using a different browser so not really bother by this anymore. you can close if you want

Comment 13

[Fatih Kilic [:fkilic]]

Alright then closing the issue as invalid as this the expected behaviour.