weighted fonts & FontFace

[Thorin-Oakenpants]

https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41330#note_2857743

One thing I can do initially is to add a parameter to existing PoC/tests (not TZP main) to set the font-weight (used in the style for base measurements and each font+fallback), but my gut feeling is this doesn't pick up anything new

And if we only applied it to the font + fallback being measured, then the span would produce false positives: because we changed it from the base)

So the key is to only apply it to the font-name being tested, not the fallback - @abrahamjuliot how do we do this

---

Edit: this is twofold

• can we detect the actual font, which can provide outlier entropy from users who install or delete those fonts - or detect default minor OS versions (not really, it's not guaranteed that is the minor version it is above/below, it's all about entropy)
• can we get any sizes

To point one, we should investigate what leaks via font-face: as that has already been shown to have differences e.g. with win11+ only fonts. So queue .. a small Songti* test for the 🐟 coming up in 1000, 999, 998 ....

[Thorin-Oakenpants]

@abrahamjuliot ... see https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41330#note_2858133

The code is using the fntList set by TZP based on your OS etc. - it's just a quick test to see what's going on

Try this

• load TZP in Firefox and from the console run get_fontface() - it works
• load TZP in TB and do the same thing - nothing found, returns an empty string

Interesting huh? I still need to check if a whitelist in Firefox would still leak a "variant"

[Thorin-Oakenpants]

say hello to my new liddle friends

[abrahamjuliot]

returns an empty string

Same... empty string on Windows. Here's Ubuntu & Fedora. There should be much more on Android.

laptop

I used to troubleshoot a handful of x360s when I worked at an office suite. It's a very nice laptop. Just make sure not to drop. The fans are fragile.

[Thorin-Oakenpants]

It's a very nice laptop

I bought it almost a year ago - it cost almost double what the iMac did (which I bought today) - what I like is the large screen, high dPI/devicePixelRatio, it's not win7 (which is about to die next ESR I think will the last to support it), and the touch (10 points) - so I get to test all sorts of weird subpixel behavior and rounding

[PieroV]

say hello to my new liddle friends

Hello new Thorin's friends lol

[fxbrit]

jeez look at that horsepower on these shiny new machines. I've been waiting for your to unbox the spectre for months, and now you flex on me with not one but two new machines? I'm kinda jealous ngl..

[Thorin-Oakenpants]

OK, so there's a few different scenarios here

The idea is to split all fonts being tested into font weight buckets

let fntList = {
   100: ['fntA Thin', 'fntB Thin'],
   200: ['fntC Extra Light'],
   300: ['fntC Light'],
   400: ['fntA','fntB','fntC','fntD'],
   500: ['fntA Medium'],
   600: ['fntC Semi Bold'],
   700: ['fntD Bold'],
   800: ['fntB Extra Bold'],
   900: ['fntA Black'],
   950: ['fntB Extra Black'],
}

code

• loop each weight, then each font, then each fallback - record if size different to fallback
• no font is listed twice

A user may (blocked/font.vis/whitelist or not installed/added-or-removed by the user)

• note: just using one variant for this example
• i. have Regular, Black
• ii. have neither
• iii. have only Regular
• iv have only Black

Initial testing indicates a font will fallback within it's family before using the fallback base font

Effects (assuming tests were right)

• i. + ii. Both are detected at their actual weight measurements (width x height), or not detected at all
  • thus we pick up fonts that are not detected at normal
• iii. Black falls back to using Regular - and this size probably differs from what Black would have been = entropy
• iv. I don't think Regular would fall back to a non Regular variant (this is why we don't detect all those variants at normal), only a variant to normal .. but if it did the same would apply as per 2 above

So in case iii (maybe in case iv), the entropy is in the measurements + the font being tested. So we might say we detected Black at size Regular. This differs from case i or iv where we say we detected Black at size Black.

@PieroV - does this make sense

[PieroV]

Actually you're not considering bold.

Black is more likely to fall back to bold, not to regular. I think that bold is often synthesized if you don't have the real bold variant, whereas other variants are either approximated to 400 or 700.

But I haven't looked up for the specs, nor double checked.

[Thorin-Oakenpants]

Black is more likely to fall back to bold

Yes. I thought about that (I have done zero testing yet) .. was just trying to keep it simple ... whatever the non-Regular falls back to, if it's within the family and NOT the fallback, we catch it, which is the point: and the entropy is the size (hopefully it differs)

I'm going to keep discussions here to reduce noise at gitlab. I know what to do.

This approach picks up changes to all variants (user adds/removes any of them, or they are OS version dependent) depending on the font protection (none, whitelist, font.vis) and I can tailor the lists accordingly.

I may have to rethink how to handle common size collisions of expected fonts: currently I don't bother testing for them, just wanting to get at least a single size collected.

[Thorin-Oakenpants]

I may have to rethink how to handle common size collisions of expected fonts

Okie dokie .. under #216 I realized that we can leverage a better test string to create more size buckets, and bump the size to 512px (the size increase gave me one extra bucket in win7). And I can massage the string per OS if need be to find a happy medium

I got to 128 size buckets max (win7), and my happy medium is 127 using 6 unique chars (the more different chars used the perf takes a hit). So I will only not bother to test for fonts we know really should be there and are a size collision, So windows is 240 instead of 219 (excluding the poison pill font)

I don't really think the size buckets matter that much, i.e finessing them to split two very closely sized fonts. If a system is different for some reason, it will most likely already manifest (as already shown in arkenfox results where we got conflicting size collision results)

Also, this means I don't have to worry about reducing fonts lists this way, and it ensures we pick up outliers who add/remove system fonts

[Thorin-Oakenpants]

was feeling very rebellious and cypherPUNKish ... I have too many stickers ... might stick em on the mac screen .. no wait ... I'd better buy another laptop - @fxbrit 😈

[fxbrit]

stop flexing on me. if you have extra stickers you can send them my way, P. Sherman 42 Wallaby Way Sydney.

[Thorin-Oakenpants]

The atomic ones came from the "fission" team :) and the one in between them signifies whistler all hands and depicts an Inukshuk .. there's one up at Rendezvous Lodge on Blackcomb. The lodge is huge and all-hands spent the last evening there

here's a pic from the internet. So we were down in the village for the week. And on the Friday night all 800+ of us went up in the gondola (it takes half an hour) to the lodge and had pizza and beers etc

[Thorin-Oakenpants]

@abrahamjuliot FYI (PS: how's things)

testing weighted fonts, such as Black, Light, Semi* etc is problematic with font-family as you can't be sure that the result is from an actual font, a variable font, or synthesized - and how do you determine what to compare to. Also gecko at least has issues detecting some fonts on first use per session (seen in mac and windows), albeit that was without setting a weight - some sort of async font fallback and caching.

Instead we can use FontFace, which won't give us measurements, but we have plenty of that already due to the large font lists per OS, and decimal precision from skewing the cllientrect, and high font size.

FontFace is also not perfect - it will not detect

• FontSubtitutes
• aliases
• fonts starting with a numeral or ones that contain ( or )
• localized names
• and some fonts simply refuse to be detected

Also, noticed with a lot of Noto fonts, and on Linux, that often a font will require Regular added, but can also detect both, or one or the other - interesting entropy to be gained there e.g. across linux

• e.g. Nimbus Sans Regular (on a FF on someone's Debian), Nimbus Sans (on a FF on someone's Ubuntu)

Anyway, we can use FontFace to pick up on some additional font enumeration entropy with weighted fonts, and also check font vis doesn't leak - either TB's lists, RFP level 1, or FPP level 2

This is enough entropy. We also don't need to test for every weighted font (we do for TB as we are checking for missing fonts and expect an exact result), so can just be judicious with our small selection

I'm not even that convinced there is that much font enumeration entropy to be gained here: Win 10 vs 11 is minimal. Mac 10.15 to 15 (7 versions) may be fertile. Linux and Android needs some thought

[Thorin-Oakenpants]

Win 10 vs 11 is minimal. Mac 10.15 to 15 (7 versions)

Win 10 and Mac 10.15 are the minimum supported versions for FF128+

[Thorin-Oakenpants]

and also check font vis doesn't leak - either TB's lists,

We also don't need to test for every weighted font (we do for TB as we are checking for missing fonts and expect an exact result)

FYI: TB will move from using a whitelist to their own font.vis lists - https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43322 - right now in nightly, you can blank font.system.whitelist and it will start using TB's font.vis and fontFace now works