Closed Bug 1736005 Opened 3 years ago Closed 5 months ago

Restrict system font visibility (for fingerprinting reasons) as part of tracking protection

Categories

(Core :: Privacy: Anti-Tracking, enhancement)

Product:
Core
Component:
Privacy: Anti-Tracking
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jfkthame, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: parity-safari)

Attachments

(2 files, 1 obsolete file)

win7.jpg
347.68 KB, image/jpeg
Details
macOS.png
216.72 KB, image/png
Details

Platform code has the ability to limit visibility of user-installed fonts, which can be used as a fingerprinting/tracking vector.

Bug 1715507 implemented a group of prefs that can set different levels of "font visibility" for different browsing modes: https://searchfox.org/mozilla-central/rev/cc869830d5cb2482a123ed3a63782bfd5dcf74ec/modules/libpref/init/StaticPrefList.yaml#6954-6982

Currently the defaults are to limit the browser to standard system fonts (level 1) when privacy.resistFingerprinting is set, and otherwise allow all fonts to be used (level 3).

We should consider reducing the visibility level for trackingprotection and private-browsing modes, to make it harder for sites to use fingerprinting to track these users.

One question I have is whether this should be surfaced in any way through the UI and/or documentation of these settings?

Johann, before he left Arthur indicated that you might be the best contact for moving forward here. Happy to discuss further as and when you want to pursue this; I don't know what current schedules & plans are like.

Flags: needinfo?(jhofmann)

Hey Jonathan, this is really exciting. Tim is currently looking into our plans for fingerprinting, so I'll forward the needinfo.

Flags: needinfo?(mail) → needinfo?(tihuang)

I don't think we need a dedicated UI for the font setting here because it's hard for average people to understand it as well as the privacy implications here. Instead, we should put the setting under the ETP settings, Standard and Strict, and add documentation to describe the details of these font settings.

What I imagine is that the standard mode might use level 2 or 3 depending on the potential breakages and the strict mode will use level 1. And we can talk about this protection in the SUMO article of ETP, so people can get more knowledge about this protection if they want.

Flags: needinfo?(tihuang)

(In reply to Tim Huang[:timhuang] from comment #3)

What I imagine is that the standard mode might use level 2 or 3 depending on the potential breakages and the strict mode will use level 1. And we can talk about this protection in the SUMO article of ETP, so people can get more knowledge about this protection if they want.

Do we know of any webcompat breakage caused by font visibility level 1 or 2? What information do we need to make a decision about shipping? Do we need to run an A/B experiment or just try shipping to see if anything breaks?

I believe Safari implemented level 1 or 2 in macOS 10.14 Mojave (2018):

https://gizmodo.com/apple-declares-war-on-browser-fingerprinting-the-sneak-1826549108

For a different perspective, this Twitter thread (2019) says restricting user-installed fonts "harms minority pops that don't have language support in system fonts, non-minority pops (like China and Japan!) that have ugly system fonts, and slow-internet pops that install popular webfonts."

Keeping today's default level 3 in standard mode and only using level 1 in strict mode (where some breakage may be acceptable) would still allow those use cases.

Keywords: parity-safari
OS: Unspecified → All
Hardware: Unspecified → All

I haven't seen any breakage filed because of level 1 or 2. We only enable font visibility level 1 when fingerprinting resistance is enabled, which, I believe, has a very low population. So, this is probably the reason why I haven't noticed there is a webcompat breakage.

I think the shipping criteria would be mainly based on the webcompat issues caused by this protection. We can only know the impact by running some sort of experiment. An A/B experiment is an interesting idea, but I think there will be a challenge for us to get URLs that have breakages from users. We might be able to use the breakage report to get it, however, it would be hard to tell if the breakage is really caused by the font visibility. Instead, using Nightly to experiment with the protection might be a better way to do this. We could enable the protection for one or two cycles in Nightly to see if users complain about issues with fonts. And we can always flip the pref back if we found out there are too many regressions.

(In reply to Tim Huang[:timhuang] from comment #5)

I think the shipping criteria would be mainly based on the webcompat issues caused by this protection. We can only know the impact by running some sort of experiment. An A/B experiment is an interesting idea, but I think there will be a challenge for us to get URLs that have breakages from users. We might be able to use the breakage report to get it, however, it would be hard to tell if the breakage is really caused by the font visibility. Instead, using Nightly to experiment with the protection might be a better way to do this. We could enable the protection for one or two cycles in Nightly to see if users complain about issues with fonts. And we can always flip the pref back if we found out there are too many regressions.

I ran some A/B experiments in Nightly last year to watch for webcompat breakage caused by Firefox version 100's User-Agent string having a three-digit version number [1]. Those experiments made 50% of Nightly users unknowingly spoof a "Firefox/100.0 UA" string. I also advertised the pref in Slack, Matrix, and Twitter and asked for volunteers to test and report problems.

Like you said, there is no way to automatic way to detect or gather URLs of broken web pages. We instead hoped that Nightly users would report broken pages in webcompat.com or Bugzilla. I worked with the Webcompat team to identify and prioritize bug reports that looked related to version 100.

Running those experiments was a lot of work, but we didn't have an easy alternative. Preffing on the font visibility restrictions for all Nightly users for one or two Nightly cycles would be easy and a much lower risk than the possible breakage we feared from spoofing a "Firefox/100.0 UA" string.

[1] https://mana.mozilla.org/wiki/display/FIREFOX/Firefox+100+User-Agent+Experiment

(In reply to Tim Huang[:timhuang] from comment #3)

For a different perspective, this Twitter thread (2019) says restricting user-installed fonts "harms minority pops that don't have language support in system fonts, non-minority pops (like China and Japan!) that have ugly system fonts, and slow-internet pops that install popular webfonts."

IDK if this is a definitive test, but at vis level 1 (your OS may differ: this is win 7, en, with no additional/supplemental fonts)

  • https://www.cogsci.ed.ac.uk/~richard/unicode-sample-3-2.html
  • new tofu: syriac, devanagari, bengali, gurmukhi, gujarati, oriya, tamil, telugu, kannada, malayalam, sinhala, lao, ethiopic, cherokee, unified canadian aboriginal syllabics, khmer, ... (stopped here ... but also note CJK radicals supplement, kangxi radicals, musical symbols, CJK compatibility ideographs supplement)
  • note: tofu regardless: myanmar, tagalog, hanunoo, buhid, tagbanwa

At vis level 2 all those that "broke" are no longer broken, because Supplemental Fonts

(In reply to Simon Mainey from comment #7)

IDK if this is a definitive test, but at vis level 1 (your OS may differ: this is win 7, en, with no additional/supplemental fonts)

  • https://www.cogsci.ed.ac.uk/~richard/unicode-sample-3-2.html
  • new tofu: syriac, devanagari, bengali, gurmukhi, gujarati, oriya, tamil, telugu, kannada, malayalam, sinhala, lao, ethiopic, cherokee, unified canadian aboriginal syllabics, khmer, ... (stopped here ... but also note CJK radicals supplement, kangxi radicals, musical symbols, CJK compatibility ideographs supplement)
  • note: tofu regardless: myanmar, tagalog, hanunoo, buhid, tagbanwa

On my en-US Windows 11 machine without any user-installed fonts, I see the same results with vis level 1 and 3: I see proper fonts for all of the above (including Myanmar), except tofu characters for Tagalog, Hanunoo, Buhid, and Tagbanwa.

At vis level 2 all those that "broke" are no longer broken, because Supplemental Fonts

So Win 7 includes all those fonts but hides that at vis level 1 but Win 11 doesn't? Why are the same these fonts treated differently on Win 7 and 11? Do the fonts have different metadata in Win 11? Or is this a Gecko bug interpreting Win 7's font metadata?

Maybe this can be worked around by having different font vis levels on different Windows versions.

So Win 7 includes all those fonts but hides that at vis level 1 but Win 11 doesn't? Why are the same these fonts treated differently on Win 7 and 11? Do the fonts have different metadata in Win 11? Or is this a Gecko bug interpreting Win 7's font metadata?

Is it the testing method? Let's see; side by side, Nightly and Beta, Win 7 (I'll test win 10 later)

Test1:

  • Nightly RFP on + layout.css.font-visibility.resistFingerprinting = 1 (64 fonts available from base 117)
  • Beta RFP on + layout.css.font-visibility.resistFingerprinting = 2
  • result: tofu on nightly as per original list not seen in beta
  • TZP: immaterial since when RFP is on the test code only uses the base 117 font list

Test2: (new sessions, prefs reset, ETP = standard mode)

  • Nightly + layout.css.font-visibility.standard = 1
  • Beta + layout.css.font-visibility.standard = 2
  • result: tofu on nightly as per original list not seen in beta
  • TZP: 1= 64 fonts from 251, 2 = 135 from 251, 3 = 150 from 251

Test3: (new sessions, prefs reset)

  • using one off PB windows
  • Nightly + layout.css.font-visibility.private = 1
  • Beta + layout.css.font-visibility.private = 2
  • result: tofu on nightly as per original list not seen in beta
  • TZP: 1= 64 fonts from 251, 2 = 135 from 251, 3 = 150 from s51

Hmmm. Methodology seems stable :) Is win 11 allowing more fonts and shouldn't? Surely the TZP font counts/check (which is basically all windows fonts) will tell us that for starters

(In reply to Chris Peterson [:cpeterson] from comment #8)

(In reply to Simon Mainey from comment #7)

IDK if this is a definitive test, but at vis level 1 (your OS may differ: this is win 7, en, with no additional/supplemental fonts)

  • https://www.cogsci.ed.ac.uk/~richard/unicode-sample-3-2.html
  • new tofu: syriac, devanagari, bengali, gurmukhi, gujarati, oriya, tamil, telugu, kannada, malayalam, sinhala, lao, ethiopic, cherokee, unified canadian aboriginal syllabics, khmer, ... (stopped here ... but also note CJK radicals supplement, kangxi radicals, musical symbols, CJK compatibility ideographs supplement)
  • note: tofu regardless: myanmar, tagalog, hanunoo, buhid, tagbanwa

On my en-US Windows 11 machine without any user-installed fonts, I see the same results with vis level 1 and 3: I see proper fonts for all of the above (including Myanmar), except tofu characters for Tagalog, Hanunoo, Buhid, and Tagbanwa.

That sounds like what I see on Win10, too. The base fonts on Win10 have pretty wide coverage, so there won't be many gaps until you start looking at some of the much-lesser-known writing systems (like Tagalog, Hanunoo, Buhid, and Tagbanwa).

On Win7, the base fonts are much more limited, and many Asian languages were only supported via supplemental font packs.

I suspect that when Simon checks level 2 (in comment 7), and many of the Asian languages become supported, this means he's seeing different fonts there on Win7 than the base fonts we see on Win10/11 for the same languages. E.g. on Win7, the supplemental fonts would have provided Mangal for Devanagari, whereas on Win10 we're seeing Nirmala UI.

All of which means that limiting visibility level to 1 carries a lot more risk on Win7 than on Win10, because on Win7 it effectively disables support for a bunch of relatively major Asian languages. Level 2 is a lot less risky from that point of view (but is also less privacy-protective, because it means a site could easily detect which supplemental font package(s) the user has installed).

I tested https://www.cogsci.ed.ac.uk/~richard/unicode-sample-3-2.html in Firefox, Chrome, and Safari on macOS 11.6.4. Here are the differences between the browsers:

Font Firefox 99 vis level 1 Firefox 99 vis level 2 Firefox 99 vis level 3 Chrome 100 Safari 15.4
Combining Diacritical Marks OK OK OK some tofu OK
Syriac tofu tofu OK OK OK
Thaana tofu tofu OK OK OK
Tagalog tofu tofu OK OK OK
Hanunoo tofu tofu OK OK OK
Buhid tofu tofu OK OK OK
Tagbanwa tofu tofu OK OK OK
Gothic tofu tofu OK OK OK
CJK Unified Ideographs Extension B tofu tofu OK OK tofu

(In reply to Chris Peterson [:cpeterson] from comment #11)

I tested...

I automated it for you: WIP (more scripts to add)

  • https://arkenfox.github.io/TZP/tests/fontscripts.html
  • be aware: allow time for async font fallback (1 or 2 secs) so all the displayed chars can render properly
  • [x] all assigned code points
    • if unchecked, it removes possible noisy results: such as medievalist additions to latin extended additional, such as any assigned code points that weren't assigned in older font versions on older platforms (looking at you win7)
    • toggling this rebuilds the codes and chars
  • clicking [codes], [chars] will output the objects to console
  • legend of script names are all linked to anchors
  • clicking run will create a summary, linked to, under the script legend where you can click copy to clipboard
  • it does this by calculating a giant known tofu size and width and then testing each x chars - x being the depth option
    • it recalculates the tofu size on each run in case you zoom in or out (in which case the tofu sizes change)

If you want any additional scripts added, let me know: I've been using this (and subsequent links)

Attached image win7-allcodepoints.png (obsolete) —

example: one was with RFP on (vis = 1), the other without (vis = nothing? or 3)

Attached image win7.jpg —

windows 7
script blocks: 129
test parameters

  • up to 20 (code points checked per script)
  • reduced (meaning some scripts rolled back to earlier unicode versions to avoid tofu noise on older platforms with older font versions)

someone feel free to test Win8/10/11 .. mac ... linux

Attachment #9272134 - Attachment is obsolete: true
Attached image macOS.png —

attaching my tests for macOS.

Depends on: 1771810

We now effectively do this.

The visibility of fonts to websites has been restricted to system fonts and language pack fonts in Enhanced Tracking Protection strict mode to mitigate font fingerprinting.

https://www.mozilla.org/en-US/firefox/119.0/releasenotes/

Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: