Check Bug 1894779: Allow font-face urls to be resource:// urls and relax CORS for resource:// URLs

The font-face from resource:// will be interesting for Mullvad Browser and EOY.

However, we also have to check what is about CORS and resource:// now.

https://bugzilla.mozilla.org/show_bug.cgi?id=1894779

Thanks to @thorin for the head up.

added FF128-esr label

added 14.0 stable Roadmap::Future Task labels

added All Platforms label

marked this issue as related to #42751 (closed)

mentioned in issue #42751 (closed)

@pierov is this a problem for us or should we just let @henry know we don't have to bundle fonts as data:// urls anymore in css (for the YEC)?

We currently still do this in mullvad browser: https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/blob/53f0232816c4309dba65a66e0e5fba7f71bd2286/browser/components/mullvad-browser/content/mullvadBrowserFont.css

assigned to @pierov

added Needs Information label

removed Roadmap::Future label

/cc @tjr

Happy to be cc-ed so I can weigh in if needed, but I don't think there's a specific ask of me ATM right?

Just wanting to understand if there are consequences/considerations here beyond embedded fonts are now easier.

If a font file is marked contentaccessible in the manifest, a website can now include it (via font-face). Before you couldn't include it via font-face. But I'm not sure if you could try to include via a img tag or something.

It would allow distinguishing major versions of TB probably, maybe minor versions if you were very meticulous and you had changed something with the font files.

It would allow distinguishing major versions of TB probably, maybe minor versions if you were very meticulous and you had changed something with the font files.

We usually ship fonts close to the end of the year for the about:tor customization. So far we've always embedded them as data:// URIs.

We could switch to resource:// (if there's a way to allow only privileged pages to access them, IIRC about:tor is one, it has an actor to move data between processes for sure).

So this should only be for fonts declared in a manifest. I am using a font that happened to be here: https://searchfox.org/mozilla-central/source/browser/components/pocket/jar.mn#6,13

I don't know if there is a way to restrict it to privileged pages only, or maybe if privileged pages can override contentacessible=no - but I don't think they can.)

All in all, it sounds like unless you're adding fonts into a manifest this won't affect you negaitvely, and it might not be a feature you want to use if there are no drawbacks to your current approach

Great, thank you very much!

The main drawback is the higher size, but being desktop-only this isn't a big deal.

added Next label and removed Needs Information label

removed Next label

After reading Tom's comments, I think it isn't a problem for us, at least for now.

At most, something to remember and consider for cases such as YEC.

In the various omni.ja we include some fonts for PDF.js, but we (well, upstream) control them, so everyone will have the same, therefore they aren't a fingerprinting vector.

Moreover, these fonts aren't accessible to (unprivileged?) content, I wrote a small test, and it didn't display the embedded font.

The test

<style>
@font-face {
  font-family: 'Local LiberationSans';
  src: url('resource://pdf.js/web/standard_fonts/LiberationSans-Regular.ttf');
}
html {
  font-family: 'Local LiberationSans',monospace;
}
</style>
Test

closed

marked this issue as related to tor-browser-build#41125 (closed)

marked this issue as related to tor-browser-build#41126 (closed)

removed the relation with tor-browser-build#41125 (closed)

removed the relation with tor-browser-build#41126 (closed)

marked this issue as related to tor-browser-build#41219 (closed)

marked this issue as related to tor-browser-build#41220 (closed)