Re: [csswg-drafts] [css-fonts] incorporate mitigations for font based fingerprinting (#4055)

@frivoal 
> What do we count as "breaking the web"?

That's a very relevant question. For there to be even _change_ (leaving aside for the moment which changes are _breakage_), the Web author has to specify a font that that's not a system font and that the user has installed (or the user-installed font has to be the only fallback).

_These days_ the notion that for European languages a Web author would bet their design on the user having a particular non-system font installed as opposed to either being satisfied with known system fonts or providing a specific font via `@font-face` is ridiculous on its face, since the expected success rate would be very low.

For what language communities can a Web author generally expect users to have a nameable but non-system-bundled font installed (group 5 in my previous comment) such that it's not pretty much the only font available for the script (in which case there'd be no need to name it)?

As for the case where everyone in a language community has to install a font because their script isn't covered by system fonts at all (group 6 in my previous comment), the issue might be more solvable than it might seem. After my previous comment, I learned that macOS ships the long tail of Noto fonts but hides them from font pickers. It appears that Android ships the long tail of Noto, too. I gather Chrome OS does, too, but I didn't test. It doesn't seem unreasonable to give dead-script scholars a slightly worse out-of-the-box experience in order to protect the privacy of everyone else (i.e. require dead-script scholars to go to group 4).

The unhinted fonts in the long tail (the tail not already covered by e.g. Windows 10, Ubuntu, and Fedora out-of-the-box) of Noto are remarkably small in terms of file size. The hidden Noto folder on macOS Mojave takes a mere 6.3 megabytes.

Are there living scripts without any font out of the box on macOS, Android, and Chrome OS?

> 8. People who pay a substantial percentage of their income on data costs, and wish to reduce the weight of web pages by installing commonly used fonts to avoid them being downloaded over and over by @font-face. May overlap with 5.

Performing that optimization requires enough understanding of how browsers work that it doesn't seem unreasonable to expect users who perform that optimization to also have the knowhow to flip a pref to opt out of the privacy protection. (Whereas I'm worried that for group 5 it might be less practical to require flipping a pref.)

> 9. People on linux systems like debian where everything including the base system is installed via a package manager, and there's no distinction between system fonts and user installed fonts.

Seems unreasonable to give up in the case users of more mainstream operating systems, including Linux distros, just because one can show that there exist Linux distros that leave so much configuration to the user that the notion of "default" isn't very meaningful.

Debian is pretty out there on these matters even as far as Linux distros go. Consider a Japanese IME. Fedora installs one out of the box even if you don't install Fedora in Japanese. Ubuntu installs one when you enable Japanese text input, which I assume happens out of the box if you install Ubuntu in Japanese, though I haven't tested. OpenSuSE gives you a Japanese IME if you install OpenSuSE in Japanese (but I failed to figure out how enable a Japanese IME from GUI on an English OpenSuSE installation). Debian doesn't give you a Japanese IME even if you install Debian in Japanese and choose a Japanese keyboard layout during installation!

@tabatkins 
> No, we can't, because Privacy Budget is intended by Chrome's security folks to be the way to solve the problem discussed here.

Even if not intended for privacy reasons, do you consider this issue already incidentally solved on Chrome OS and Android by the combination of shipping Noto and it being hard for users to install fonts?

-- 
GitHub Notification of comment by hsivonen
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4055#issuecomment-537400477 using your GitHub account

Received on Wednesday, 2 October 2019 08:52:56 UTC