Open Thorin-Oakenpants opened 1 year ago
@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
get_fontface()
- it worksInteresting huh? I still need to check if a whitelist in Firefox would still leak a "variant"
say hello to my new liddle friends
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.
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
say hello to my new liddle friends
Hello new Thorin's friends lol
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..
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
A user may (blocked/font.vis/whitelist or not installed/added-or-removed by the user)
Initial testing indicates a font will fallback within it's family before using the fallback base font
Effects (assuming tests were right)
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
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.
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.
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
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 😈
stop flexing on me. if you have extra stickers you can send them my way, P. Sherman 42 Wallaby Way Sydney.
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
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
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 ....