svg opentype fonts

[mik0l]

https://pixelambacht.nl/chromacheck/

[Thorin-Oakenpants]

what are you asking?

feature detection is not an issue if you don't mess with prefs - you can't hide your FF version for example, and you simply want to have the same APIs and features as everyone else on that version - when something rolls, it rolls

• e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1740530 and gfx.font_rendering.colr_v1.enabled (after flipping you need to reload the test page in a new tab)

As for the linked PoC, it uses canvas, which RFP totally randomizes

[mik0l]

Disabling the pref gfx.font_rendering.opentype_svg.enabled can be detected.
Planned to remove https://bugzilla.mozilla.org/show_bug.cgi?id=1442936

[Thorin-Oakenpants]

5 years and no activity, and also used by Tor Browser's slider, so they probably won't remove it.

The linked test uses canvas. With RFP all five are red. Yes, SVG open type font support can be detected without canvas. Is this your point? And if so, how is this a bad thing?

[mik0l]

5 years and no activity, and also used by Tor Browser's slider, so they probably won't remove it.

Why keep him? It's not used anywhere. All I found is https://color.typekit.com/#people

The linked test uses canvas. With RFP all five are red. Yes, SVG open type font support can be detected without canvas. Is this your point? And if so, how is this a bad thing?

I didn't know, I don't use RFP.

[Thorin-Oakenpants]

What are you talking about? color fonts or svg open type?

The latter we flipped for security reasons - and it's because it's almost never used that I know of that we can, because no breakage,

If you are concerned about being FPed with this (svg) metric, then read the wiki. You were already unique, this makes no difference. As long as there is a measurable benefit, then we flip. This is also a very unlikely candidate to be in scripts (not that we shouldn't protect every metric in RFP/Tor Browser) - it's binary and slow (AFAIK) to determine (and given TB's slider, now also a little unstable)

Maybe this needs to be revised, and we could make it inactive. One reason it hasn't, is precisely because it causes no breakage (that we know of, i.e no one uses it).

[mik0l]

https://color.typekit.com/#people - If you disable gfx.font_rendering.opentype_svg.enabled some fonts still have color. Is this some kind of bug?

🏳️‍🌈#️⃣ 0️⃣ 1️⃣ 2️⃣ 3️⃣ 4️⃣ 5️⃣ 6️⃣ 7️⃣ 8️⃣ 9️⃣ - Firefox seems to be replacing them with built-in ones.

Maybe this needs to be revised, and we could make it inactive. One reason it hasn't, is precisely because it causes no breakage (that we know of, i.e no one uses it).

[snip by pants]

[Thorin-Oakenpants]

font vis levels (which RFP already uses) has nothing to do with svg open type fonts. Like graphite and woff, the website provides the font - I guess you could install the font, but it does not control whether or not you can render the format

IDK what you are going on about with this color.typekit test. For me they are all black + white when the pref is flipped, and the test reloaded in a new tab. Emoji's have color. I don't even see what unicode points you are using. Emoji One was actually used by Firefox until, I think, v68. Then they moved to Twemoji. When we remove the Emoji One font from the equation, e.g. below, you can see what happens (unicode code points have map fallbacks to specific fonts)

Firefox with RFP on windows

There are 4k emojis and/or combos (something like that, not going to look it up)

[mik0l]

[Thorin-Oakenpants]

am I supposed to guess your OS, your system fonts, your font configs, your font mappings and async fallback fonts, and debug all this?

Look at my picture above. When emoji one wasn't used, e.g. it's been removed and replaced by twemoji internally - and I'm not using that test page (which I assume is trying to force emojione on the characters) - my rainbow flag is the same as yours. CLEARLY the unicode code point is async fallbacking in order to render correctly. Something similar will be happening with your number buttons

[Thorin-Oakenpants]

knock yourself out: https://twemoji-cheatsheet.vercel.app : symbols for me (#, 0 etc) are actually blue. IDK why and IDFC why they render differently in github comments (same thing happens on gitlab where chicken is rendered differently) or on the emojione test (no one cares about an old emojione test)

[mik0l]

am I supposed to guess your OS

Fedora (Xfce), default fonts.

[Thorin-Oakenpants]

right. there's your answer. Fedora XFCE (you) vs Windows (me)

[Thorin-Oakenpants]

So I did some sleuthing - I can't find any CVE's for this, and a similar result from a PDF analysis from 2014 (or 2016?) said pretty much the same. SVG itself has is a large attack surface with many CVEs (across many apps), and TB also disables that in the the slider (on safest)

It's also Firefox only (see caniuse), which also says to me that it's just not going to be used in the wild: for a) websites b) fingerprinting - and it wouldn't surprise me if they deprecate the whole thing now that COLRv1 is coming

So, all things considered, we could keep it for potential security issues, or drop it as one less pref to deal with and clutter shit up. I'll go for the later, since it can't be that big a deal if no reports of issues in all these years and it's default enabled with TB's default slider

moving it to inactive under 5500 optional hardening