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

>> If users are given choice, we can't protect users who use the ability to make choices from being fingerprinted on those choices.
>
> I believe that's the problem the working groups (CSS WG + privacy WG + other related WG like i18n, etc.) need to working together and figure out.

For clarity: I'm not suggesting taking away choice from users. That exercising choice makes a user fingerprintable is just a fact and there's nothing for WGs to work out about it. (I think most of this issue is probably not a standard-setting one but a browser product decision one.)

What I see as a problem is that what I believe to be substantial populations of users who don't need to exercise such choice and _could_ be protected are not. It's not particularly nice to know that there are users who are _cannot_ be protected, but that's not a good reason not to protect the substantial user population who _could_ be protected.

Consider the following types of users:

1. Users who never install fonts.
2. Users who install fonts unknowingly by installing apps that add fonts that are available system-wide.
3. Users who knowingly install fonts for non-browser use but don't change the default font prefs in their browser.
4. Users whose language is well-served by system fonts but who as a matter of individual taste still change their browser font prefs.
5. Users whose language is merely covered by system fonts and who as a matter of community norm install additional fonts for their language.
6. Users whose language isn't covered by system fonts and who _have to_ install fonts for stuff to work at all.
7. Web developers who want to prototype with local non-system fonts before deploying with `@font-face`.

(The taxonomy is simplified: The most notable complication is the one seen upthread on Windows 10 with Chinese and Japanese: That there are fonts that are bundled with the system and that are conditionally enabled. For example, for someone in Japan, having the conditionally-enabled Japanese fonts enumerable probably isn't a substantial fingerprinting vector. For someone in Europe who has a Japanese IME in the text input menu, they are. For the purpose of the below paragraphs, I'm hand-waving conditionally-enabled system fonts into group 1.)

Users in group 1 need no protection mechanisms compared to status quo. Evidently users in group 4 can change browser prefs and could uncheck whatever "don't expose user-installed fonts to the Web" checkbox to opt out of protection.

Browsers _cannot_ protect users in group 6 without developing all-encompassing font download mechanisms as part of the browser.

Groups 2 and 3 _could_ be protected but aren't. As a user in group 3 (previously in group 4), I'm unhappy that I'm not made indistinguishable from group 1. It should be within technical feasibility to do so without breaking use cases for groups 5, 6, and 7, but the details do need careful thought. In particular, it would be good to know what language communities are in group 5 and with what details (e.g. in the context of particular operating systems only or out of habit despite operating system font repertoire having improved). Group 4, as noted, will manage.

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

Received on Saturday, 28 September 2019 09:22:50 UTC