Added a default system-ui font in FF92. We should make sure this doesn't interfere with any of our font-related patches, particularly our patch for #41043 (closed)
Edited
Designs
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
morganchanged title from Review Mozilla Bug 1226042: add support for the new 'system-ui' generic font family to Review Mozilla 1226042: add support for the new 'system-ui' generic font family
changed title from Review Mozilla Bug 1226042: add support for the new 'system-ui' generic font family to Review Mozilla 1226042: add support for the new 'system-ui' generic font family
Yep, this is a pain with #41043 (closed) (it goes back to Noto Sans JP️).
But apart from that, Linux is quite safe, because we enforce the system fonts to be the one we ship.
Windows should be on the safe side, too.
The real font is Segoe UI, which we already add to our allowed list.
macOS uses .SF NS. Notice the initial period: this is a hidden font.
Both on Firefox 104 and Tor Browser based on v91, you cannot use it directly, only as system-ui (I mean: go to a page, open the developer console, and set font-family: ".SF NS": you will see Times).
On Tor Browser based on 102, on the other hand, you can just use it, both .SF NS and system-ui.
I am very confused, because I thought (from when I debugged #41004 (closed)) that hidden fonts were added to the allow-list by default.
are the fonts hardcoded on the other platforms (good for Windows, after all we already allow Segoe UI) or are they read from some configuration? (bad, possible fingerpriting!)
for macOS we need to deal with #41110 (closed) first, possibly
The linked ticket eventually only flips the layout.css.system-ui.enabled preference (68e6a59c), the real ticket to analyze is Bug 1724907 (f501d497).
Flipping it back to false doesn't solve #41110 (closed), and I think we should keep it true anyway, and provide a custom mechanism to always use the correct fonts (Arimo on Linux, Segoe UI on Windows, and probably San Francisco on macOS).
I mean: go to a page, open the developer console, and set font-family: ".SF NS": you will see Times
Or you could use science and math ... https://arkenfox.github.io/TZP/tests/fontdebug.html .. just enter the font family name and hit run. If any change in size vs the four basefonts is detected, it is shown as green and the font was used in webcontent
Notice the initial period: this is a hidden font. I am very confused, because I thought (from when I debugged #41004 (closed)) that hidden fonts were added to the allow-list by default.
This was never my understanding, and in fact we should remove .Helvetica* in mac as it's not even shipped in 10.12+ (I think) and simply maps to Helvetica (it's been a while, so take all this as off the top of my head)
I'll take saying that I'm not already doing as a personal offense
I'm terrible at spotting visual diffs. It's a shame the console somewhere doesn't list the actual font used on an element (if it does, IDK where that is), so I prefer my approach
for(constauto&entry:mFontFamilies){if(entry.GetData()->IsHidden()){// Hidden system fonts are exempt from whitelisting, but don't count// towards determining whether we "kept" any (user-visible) fontsaccepted.AppendElement(entry.GetData());continue;}
but there are other occurrences of IsHidden, so it's something we will need to deepen.
if it does, IDK where that is
On the third column there's a font tab (it may be under the arrow menu).
If you hover the name it highlights where it's used on that element .
Also, @thorin: using font: menu automatically changes many properties in addition to the family, like the size, and possibly others. Do you know if it's fingerprintable?
Entropy can exist here (excluding major platform diffs), but I need to test/lookup more to confirm. And this is mixing e.g. the first 6 items with moz items. There are a number of factors that can change sizes (and fonts), including outside the app, but generally speaking they should be really stable if users don't change things (e.g. zoom),minimal buckets should be OS (in the case of linux, that would be DE + DE version) + language
e.g. changing windows theme/settings (e.g. Right click on desktop or through Control Panel > Personalize > Window Color > Advanced appearance settings. You can set the font for a lot of the text fields.)
I was actually considering a bugzilla to enforce the same font per platform (or DE) - edit: but this is more like we should supply the font and lock down all looks and feels + widgets as well.
So besides the font name, everything else is AFAICT equivalency of all those other factors (such as scaling, zoom, etc etc) = see this comment: #40919 (comment 2803414)
TZP system fonts
So looking at the font name: in FF Windows and Mac (and I would guess Android) should be solid in FF102+. TB should be in the same boat. The issue is Linux, even without system-ui generic font-family, has always provided entropy, as shown by changes to DE versions, and diffs between DEs
note: sizes also differed in Linux tests
note: window users could affect results by changing theme settings etc
TZP system-ui clientrec measurements
Looking at the sizes (everything else being equal)
windows seems solid
mac: two quick tests between Moneterey and Big Sur changed (but that could be equivalency of other factors)
note other generic font families also changed, so I am inclined to believe this was external factors
linux: nightmare?
tl;dr: system-ui generic font-family doesn't add anything IMO to entropy, it's already exposed: subpixels/zoom/dPI/dPR/scaling x 100 places, system font name(s)
These are Firefox user results in FF from a months ago - some may have tweaked DE settings. TB may ship bundled fonts, such as Noto Sans (without double checking), but as you said "I think this could be a nightmare" to enforce it - not to mention you would need to cover all 16 items on the TZP test - AND the sizes, which IMO is super problematic.
The issue is Linux, even without system-ui generic font-family, has always provided entropy, as shown by changes to DE versions, and diffs between DEs
Tor Browser is limiting this, by restricting the system fonts only to the bundled fonts.
This mechanism isn't perfect... and eventually relies on the font version, to decide which font should be the default one.
So, we had to add a patch, which has now regressed, with system-ui.
But, apart from being an aesthetic thing, system-ui shouldn't be a fingerpriting issue, because all users have the same font (Noto Sans JP, and I would prefer it to be Arimo).
note: sizes also differed in Linux tests
note: window users could affect results by changing theme settings etc
These might be real problems, but you said that Windows is solid.
AND the sizes
Probably a good TL; DR, since the family should be okay?
I get it. If you're limiting in windows/mac, then the font should be in the allowlist, but works in mac because it's hidden - wait, I am so confused - that says -apple-system not .SF - where are we getting the .SF name from web content
Yes, some analyses on Windows and macOS ares planned, too.
I've just started on that, and started on Linux because I already have everything compiled with debug symbols .
I get it. If you're limiting in windows/mac, then the font should be in the allowlist
Indeed, or so we'd hope . But what if someone customized their Windows installation to use Times New Roman for menus?
but works in mac because it's hidden - wait, I am so confused - that says -apple-system not .SF - where are we getting the .SF name from web content
Yeah, that's very confusing, and probably another issue on our side (or maybe some upstream bug in a not very tested configuration, like bundled fonts are, after all).
Firefox for Linux has a function called GetSystemFontInfo that queries GTK, and it gets Cantarell also on Tor Browser.
So, I've tried on my Ubuntu VM, and I got Ubuntu as a font in https://arkenfox.github.io/TZP/tzp.html#css.
Of course, Cantarell and Ubuntu are not in bundled fonts, so it falls back to Arimo (not sure where, maybe in the rendering component rather than the code I'm analyzing).
But the situation is much worse than I thought in any case, and @thorin's idea that Linux is a nightmare is quite right.
Turns out the idea of doing some RFP magic in this part of Firefox could make a lot of sense.
But I would like not to completely reset widget appearance, if possible.
e.g. if on windows if you check segoe ui it will match system-ui, if you test tahoma it will match MS Shell Dlg \32 which is exactly what MS say it should be (taken from a widget property)
a match will be in red, it didn't change size: but all are red then you don't have the font: these tests are not meant to be used by people who don't understand things
most "system" fonts (i.e supplied by the OS) are unique sizes among themselves: very few doubleups such as "times new roman", "times", "roman"
I will add system-ui to more poc/debugging font tests. I do not have a mac, but the -apple-system and SF font name intrigue me. And I think I'm semi mixing tests here. I think you said the SF font couldn't be called directly - did you mean in TB or in FF or in Macs in general
and I see you posted a comment: linux is a mare, yes
personally I would prefer something tied upstream to RFP (for FF users). On windows/mac they could enforce a system font that SHOULD be there.
Linux is a mare! and we won't get Mozilla to bundle a font, so I doubt this could be RFP'd
TBH, I think that getComputedStyle is broken.
It returns wrong data, but I think it isn't lying on purpose.
It tells I'm rendering font: menu; (or whatever) with Cantarell, because the CSS engine actually believes it's Cantarell... but the rendering system thinks differently.
And this could potentially be the case also for Windows and others.
Let me customize one of my VMs, maybe one of the most expendable ones.
I doubt macOS can be customized at this level... after all it's Apple.
long story short: if the font is detected (i.e it differs on any font/generic), then a red item is a match - which sounds counter intuitive, capsice?
IIUC, that would actually make things easier: i.e we're not leaking equivalency (because we're using the right font), and we just need to fix getComputedStyle
This is good for Linux users, if it results in higher priority, but it's very, very bad for Windows users.
Also, I confirm sizes can be fingerprinted, too, but the zoom option zooms everything, not only fonts. So it shouldn't be fingerprintable through getComputedStyle, but it probably can be found with devicePixelRatio
but as far as I'm concerned these are not the issue here
I'm not sure if I understand - are you saying with the correct font, sizes still differ (same app/web language). That makes sense if the OS/DE/Theming is supplying it
I'm not sure if I understand - are you saying with the correct font, sizes still differ (same app/web language). That makes sense if the OS/DE/Theming is supplying it
I haven't understood your question, sorry .
But let's see if I can answer.
You can customize also your font size in theming (also on Windows), and for example set menus to 14pt.
If you do a font: menu, font-size will be set accordingly (i.e., 18-19px), and this is fingerprintable.
So, even if we fix the font-family part, the font-size part remains fingerprintable.
I don't know if there are other option customizable (I don't see line-height on Windows themes, but I expect it to be customizable on Linux, in some way).
I haven't checked on the code which font/CSS properties are taken from the OS/theme interface, either.
Yeah, that's exactly what I meant - see https://github.com/arkenfox/user.js/issues/1509#issuecomment-1191842941 where I asked how it was changed. Now I know that he changed his font, and I know you can change sizes - what I hadn't confirmed was that his changes were just from changing the font or both - or that just changing sizes (in theme) propagates - but I assumed as much
bugzilla: you specifically mention the whitelist. RFP upstream does not use this, it uses font vis. And font vis is not limited to RFP. So we should make sure that any fix is for everyone, not just TB
I'm trying to work out how to build a test. Display text with each of these (edit, each one in a DIV for your easy right-click inspect)
bugzilla: you specifically mention the whitelist. RFP upstream does not use this, it uses font vis. And font vis is not limited to RFP. So we should make sure that any fix is for everyone, not just TB
TBH I haven't tested too much with Firefox, I should sacrifice a Firefox profile for this kind of tests .
But please, if you can/want to add more details to the ticket feel free to.
I'm trying to work out how to build a test. Display text with each of these (edit, each one in a DIV for your easy right-click inspect)
next to each one, report the getComputedStyle and size and clientrect the height
Good idea. I was thinking to something similar, i.e., a page with a few <div> with the name of the font we set on the CSS, and the fontFamily of getComputedStyle, to avoid inspector dances.
(so you can test linux theme line height?)
I'm not sure you can customize the line-height, it was the first property that came to my mind .
Is that all we need? Then I can test with font vis settings, and I know what you mean about sacrificing a VM
The theme self-reset in the VM I used (one of the official IE VMs, maybe it contains some self-reset code?).
element with each style e.g. `caption` | reported font + size | element with reported font (to compare)
I use VirtualBox, I can close a VM without saving changes (or I can just reset the theme I guess)
I should sacrifice a Firefox profile for this kind of tests
Hah, I use Firefox portables. With FF closed, I just rename the relative path profile to profile-master and on start FF creates a new one. Once finished, I can reset everything back (i.e delete profile, rename profile-master back). I have a portable FF for every release and ESR since FF52. Pretty sure you can just do the same on TB
IDK how "portable" FF's can be on linux - snap packs? (no need to answer)
https://arkenfox.github.io/TZP/tests/fontsystem.html - IDK if this is enough. I could add clientrect heights if you want. It's not as super clean re divs as you want, because I want things to line up vertically
anyway, the blue column is the actual item, the white column is properties (font + size) applied read from the blue column, and I added the name at the start for good measure for a visual comparison
heh. I'll widen it, I see wrapping. I think it's easy to visually spot if something is off. So now we can test theme changing etc, and if getComputedStyles is actually broken (but I think you confirmed it is?)
If getComputedStyles is incorrect, maybe the answer for all users in FF is to simply return system-ui - but still, that doesn't fix those that return the widget font, or sizes
this is turning out to be a bit messy to say the least
I know you're not very good at spotting differences, but at least you can see the differences between what my FF renders and TBB renders in the same machine
If getComputedStyles is incorrect, maybe the answer for all users in FF is to simply return system-ui
Yes, that's already happening. getComputedStyles is wrong for the other ones.
Ahh, on that second pic I can see some don't match (but I am terrible at spot the differences)
tjr seemed to agree it's a bug
IDK if he confirmed anything, he just linked it to RFP (so it doesn't get lost). But yeah, now we can offer bugzilla a test and proof. Will test FF (with + without font vis). I mean if it breaks regardless of whitelist/font-vis then it's an issue that leaks OS theming for all
I know you're not very good at spotting differences, but
I can spot the size diff, not so much any font diff .. if only there was a way to get computed styles
I'm not on IRC .. also "sounds like a bug" is not "it is a bug" .. that's what we're here for. Anyway, so glad these things are getting attention - see arkenfox discussion, and I've had that test in TZP for at least three years
PS: just wait til I ramp up element + widget clientrect tests: it will completely destroy any semblance of looks + feels unity (or which this is system fonts is a snippet of a wider local poc I have been brewing)
bugzilla: you specifically mention the whitelist. RFP upstream does not use this, it uses font vis. And font vis is not limited to RFP. So we should make sure that any fix is for everyone, not just TB
You know what? I've kept thinking about this problem, and you're just right: we don't even use the allowed list on Linux.
The problem might be simply that getComputedStyle shouldn't trust system fonts.
Imma taking a sleep break, but I thought about this earlier (outside with a coffee) and I think that it does rely on the font being blocked - see that result at arkenfox when it did report the different font (it may also be that Arial Rounded MT Bold is part of Arial font family - that's a weird ass face to be exposed as a family font? fonts are weird - and RFP's font vis which the user was likely to be using allows Arial)
In my system, I don't have Helvetica, but it's rendered with Roboto.
But if I specify font-family: Helvetica, getComputedStyle returns Helvetica.
If I specify font-family: Helvetica, Roboto, sans-serif, it returns Helvetica, Roboto, sans-serif.
So, it doesn't leak that I am using Roboto (even though a site could probably measure the metrics).
The font: $system-font case is quite an edge case, because it is automatically transformed in a series of other properties (font-family and font-size, for example).
The standard says to see the individual properties, but that system fonts cannot be accessed in any way through the other properties:
That is why this property is "almost" a shorthand property: system fonts can only be specified with this property, not with ‘font-family’ itself, so ‘font’ allows authors to do more than the sum of its subproperties. However, the individual properties such as ‘font-weight’ are still given values taken from the system font, which can be independently varied.
As an example, it says that font: large menu must be interpreted as font-size: large; font-family: menu;, and be rendered as a font called menu.
But I am still confident that its implementation should be changed also in upstream Firefox, not only in Tor Browser.
However, I am less confident that it will be treated as a bug, but rather as an enhancement, and that priority will decrease, maybe even to "accept a patch, if provided" .
a. if the font is not blocked (e.g. hidden auto-allowed, allowlisted) then it's correct, but if the font is different to expected (as per the OS) then it still reveals the theme changes
this has two issues: 1. name + 2. size
b. system-ui: not sure where we are going with this, I don't know enough about how this all fits in
Looking at a1 (and did this always "leak" in TB?), if we can get it to report what is actually used, then we can control the font (if we enforce it) by making sure it is allowed. The actual name doesn't really matter, the font can be measured.
And as far as I see it, that's where we're at. Stop leaking the theme changes and only report what actually is. Enforce the same system font on windows/mac (with RFP: segoe ui/-apple-system), and linux (in TB which bundles fonts). That still leaves size entropy
Enforce the same system font on windows/mac (with RFP: segoe ui/-apple-system)
As I wrote below, what about CJK? Segoe UI does not support them on Windows 7.
system-ui isn't a big deal, we can just disable it, it's more a UX thing.
System fonts is the real problem here. I know they can be measured... but do all the people who do fingerprinting scripts know it?
It's an information in any case.
So, blocking this information is the first step. Uniforming the behavior is more difficult (CJK is a valid example also for this case).
but do all the people who do fingerprinting scripts know it
yes. if a couple of hacks like us can work it out, expect Evil™ to have already done so
edit: this hack has had it in his TZP script for over 3 years
blocking this information is the first step
we can't, because the name is irrelevant, we just measure (so unless RFP blocks using those generics in my test). uniforming behavior, ok, fair point on regional OS setups. This really is somewhat nasty to say the least
could RFP substitute those generics - e.g. just use the default proportional font + size for all of them. Is that what emilio means when he says add a non-native?
I'm curious now: how are sans-serif and serif handled?
Also, I'm downloading a JA Windows 10 iso, just to test this.
Probably, testing on Windows 7 would be even better, but MS doesn't have a nice download page for it, AFAIK .
could RFP substitute those generics - e.g. just use the default proportional font + size for all of them. Is that what emilio means when he says add a non-native?
I'm not sure. It could be, and it would be better than reporting the actually used names.
and it would be better than reporting the actually used names
not just that, what I'm saying is in web content never allow them to be used, instead aliases then to default proportional (which is serif, sans-serif, monospace: depending on language)
good sweet I must have been tired. Lemme try again. I am wearing many hats, normal FF users, RFP uses, TB users. If the FF user changes theme to a non system font (e.g. Dodgy Gothic from FontFactory) this will be used and leak name/size/measurements. Also see regional OS diff, so a user may not even need to do anything to leak entropy? If RFP kicks in, then it will still leak the theme/OS name + size, but something else will be used = measurements. But if they changed it to an allowed font (say Times New Roman), then we're back to square one.
All of which is to say, that the answer is not fluffing around with fixing what is returned with getComputedStyle (but that is a bug), but to control what is used and it must be available (then the bug no longer exists in our situation) and this fixes name, size + measurements all in one hit
tl;dr: "fix the cause, not the symptoms" is what I was trying to say, send MOAR coffee
actually, any patch should limit to web content (we don't want to upset the chrome) and that's ignoring RFP's upcoming granularity. a11y has a principal and can be exempted, right?
I meant any a11y settings that is reflected in web content.
Let's say that you can set a big font on your theme (I don't know exactly how, without zooming everything): font: menu, font: caption, etc should reflect this change.
And a webapp that tries to improve the UX by using these font will also increase in a11y.
Firefox handles system-ui as a generic font, i.e., it treats it like sans-serif and serif, with the only exception it queries the theming code before FontConfig and equivalent API of Windows and macOS.
In particular, I've noticed that, on Linux, Firefox always asks FontConfig what to do with system-ui, and the answer is the same as #41043 (closed): it does not have preferences, and eventually uses the font with the higher version.
I have tried to add Cantarell to our fonts directory, and Firefox continued doing this check, even though then it used Cantarell for the rendering.
I have already thought of two solutions:
a solution similar to #41043 (closed): we hijack requests to FontConfig to ask for Arimo, instead of asking for system-ui (e.g., in gfxFcPlatformFontList::FindGenericFamilies, or in one of its callers);
we do that in the configuration file.
While hardcoding isn't good, @richard suggested on IRC that the second approach has the following disadvantages:
users could change the config files without actually knowing the reasons;
finding patches in tor-browser.git is easier: finding a patch in tor-browser-build.git often involves knowing of that patch in the first place.
Notice that this solution forces to use Arimo whenever it supports the related characters.
Usually, font queries are tied to a language.
CJK fonts contain also Latin characters. If this becomes a problem in other platforms we could just disable system-ui. I am not sure which UX improvements it could bring.
Note that AFAICT we can't hide or block using these. Am intrigued if they do indeed differ on different windows "versions" (IDK what MS means by that, regional or 7 vs 10 vs 11 etc)
Sorry if this is a bit OT, we can always open another issue to follow this one up
As expected, if one customizes the menu font and sets a font that is in the whitelist, that font is shown in TBB. This is already an orange flag if you think to users that might customize their OS to make it look fancy - but it becomes a very red flag if you think that CJK might have a different menu font, such as MS PGothic.
So, I think we could disable system-ui and call it a day, instead of looking for workarounds.
Donuts approved from a UX pov.
The problems with font: $system-font and with hidden fonts on macOS remain.