1651368 - reconcile font whitelist and font visibility

Status: RESOLVED FIXED

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

Description

[Thorin [:thorin]]

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

Steps to reproduce:

layout.css.font-visibility.level

Tor Browser uses the pref font.system.whitelist for desktop to somewhat limit font enumeration entropy. They do bundle some fonts and bundled fonts are automatically included.

While I realize this is a work-in-progress, and that Tor Browser can set the visibility pref as it wants, we should decide how to reconcile the two

My preference is for the whitelist to be auto included

Actual results:

For example

• whitelist on windows FF same as Tor Browser [4]
• set visibility to 2 or 1
• some whitelisted fonts are blocked

[1] https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/StandardFonts-win10.inc
[2] https://github.com/ghacksuserjs/TorZillaPrint/tree/master/txt: similar to the lists in mozilla-central/source/gfx/thebes/StandardFonts-*.inc. Linux is a mess, but Windows/Mac/Android have been compiled from official docs
[3] https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#fonts - running the OS test

Note: the lists in [2] are OS specific, so you won't find items like Adobe in it, and the test in [3] auto detects your OS

[4] TB windows whitelist (with Twemoji Mozilla added)

Arial, Batang, 바탕, Cambria Math, Courier New, Euphemia, Gautami, Georgia, Gulim, 굴림, GulimChe, 굴림체, Iskoola Pota, Kalinga, Kartika, Latha, Lucida Console, MS Gothic, ＭＳ ゴシック, MS Mincho, ＭＳ 明朝, MS PGothic, ＭＳ Ｐゴシック, MS PMincho, ＭＳ Ｐ明朝, MV Boli, Malgun Gothic, Mangal, Meiryo, Meiryo UI, Microsoft Himalaya, Microsoft JhengHei, Microsoft JhengHei UI, Microsoft YaHei, 微软雅黑, Microsoft YaHei UI, MingLiU, 細明體, Noto Sans Buginese, Noto Sans Khmer, Noto Sans Lao, Noto Sans Myanmar, Noto Sans Yi, Nyala, PMingLiU, 新細明體, Plantagenet Cherokee, Raavi, Segoe UI, Shruti, SimSun, 宋体, Sylfaen, Tahoma, Times New Roman, Tunga, Twemoji Mozilla, Verdana, Vrinda, Yu Gothic UI

Comment 1

[Jonathan Kew [:jfkthame]]

Yes, I agree we should figure out a model for how these settings interact.

I wonder -- is there any purpose for the layout.css.font-visibility.level setting when using a font whitelist, or should that simply take precedence? ISTM that if whitelisted fonts are always included as "visible", and fonts not in the whitelist are by definition blocked, the font-visibility.level setting doesn't really have any meaning.

Comment 2

[Thorin [:thorin]]

Well, it's currently most restrictive and that's never a bad thing :) I pinged some tor project devs

On the face of it, I don't think vis is needed with whitelist: but it would be nice to code around it whatever is decided

• do nothing: most restrictive
• merge whitelist with allowlists
• if whitelist is not blank, ignore visibility setting

Comment 3

[Tom Ritter [:tjr] (OOTO until April)]

Hrm. I like the current behavior, and would be fine documenting it and keeping it as-is, but I could easily see how going forward it could become difficult to keep engineering-wise - having to figure out how to apply multiple restrictions in a certain order.

If that assessment is correct, I think it would be fine to ignore layout.css.font-visibility.level if the allowlist pref is set.

Comment 4

[Georg Koppen]

(In reply to Tom Ritter [:tjr] (ni? for response to sec-[advisories/bounties/ratings/cves]) from comment #3)

Hrm. I like the current behavior, and would be fine documenting it and keeping it as-is, but I could easily see how going forward it could become difficult to keep engineering-wise - having to figure out how to apply multiple restrictions in a certain order.

If that assessment is correct, I think it would be fine to ignore layout.css.font-visibility.level if the allowlist pref is set.

Sounds good to me.

Comment 5

[Jonathan Kew [:jfkthame]]

I think we should do the simple thing here: when an explicit whitelist is set, this overrides the font-visibility classification and directly controls what fonts are available.

Comment 6

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1651368 - Using an explicit font whitelist overrides font visibility-level. r=jwatt

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6dfbbf5236a4
Using an explicit font whitelist overrides font visibility-level. r=jwatt

Comment 8

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/6dfbbf5236a4

Comment 9

[Thorin [:thorin]]

verified working as expected: hashes match [1] on Windows

• whitelist (which includes fonts detected on the system not in kBase or even in kLangPacks)
• whitelist + RFP
• whitelist + visibility = 1
• whitelist + RFP + visibility = 1
• [1] https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#fonts

Do we want to backport this to 80 for Tor Browser, or let them patch it in if needed? I'm not sure what Tor Project are doing here, but they are building a FF80 based release (for testing to rapid release?)

Comment 10

[Jonathan Kew [:jfkthame]]

I think it'd be fine to uplift to 80 if release managers will accept it, given how trivial the patch is and that it has no effect with default prefs, it only applies to a combination of non-default settings. (It may be too late, though; but in that case Tor Browser could still backport the patch for their build.)

Comment 11

[Jonathan Kew [:jfkthame]]

Comment on attachment 9169131 [details]
Bug 1651368 - Using an explicit font whitelist overrides font visibility-level. r=jwatt

Beta/Release Uplift Approval Request

• User impact if declined: Interaction of multiple prefs related to font fingerprinting resistance is confusing.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Small/trivial code change; no effect on behavior with default prefs. This just serves to make it explicit which pref takes precedence when multiple non-default settings are present.
• String changes made/needed:

Comment 12

[Julien Cristau [:jcristau]]

Comment on attachment 9169131 [details]
Bug 1651368 - Using an explicit font whitelist overrides font visibility-level. r=jwatt

we're out of betas for 80, I think this should ride the trains

Comment 13

[Cornel Ionce [:noni]]

(In reply to Jonathan Kew (:jfkthame) from comment #11)

• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No

Setting qe- per comment 11.