[css-fonts][css-fonts-4] CSS Fonts 4 needs a proper Security and Privacy Considerations section

[tantek]

Currently the CSS Fonts Level 4 Security and Privacy Considerations section has a single sentence:

> “The system-ui keyword exposes the operating system’s default system UI font to fingerprinting mechanisms.”

This is insufficient. The Security and Privacy Considerations section needs to at a minimum include:

• Answers to the Security and Privacy Questionnaire from the W3C TAG: https://www.w3.org/TR/security-privacy-questionnaire/
• Explicitly note the fingerprinting dangers as being discussed in #4497

Labels: css-fonts, css-fonts-4

(Originally published at: https://tantek.com/2020/024/b1/css-fonts-needs-security-privacy)

[svgeesus]

Agreed, it is insufficient. I'm happy to take a first pass for that section. I hope @snyderp will be able to help.

[pes10k]

@svgeesus i would be very happy to. Please let me know how I can be most helpful in this regard

[svgeesus]

@snyderp I have written these before, so in this instance maybe it is better if I do the first draft and you (and other privacy experts, and security experts) review that text.

Looking through CSS Fonts 4 just now, I realized that at minimum Font fetching requirements (which mandates CORS and thus forbids cross-origin webfont requests that are not CORS-enabled) needs to be noted.

[svgeesus]

Also Localized name matching which requires a specific type of caseless string matching (thus avoiding platform differences and local differences in string matching) and requires all localized names to be matched (thus avoiding determining the user's locale by which names match).

This is a recent change, previously the spec mandated that the US locale be the only one used for font name matching. This was a disadvantage for users in non-English locales, but was originally done for consistency and privacy reasons. The new text is better, I think.

[svgeesus]

In terms of security, at least Chrome and Firefox use the OpenType Font Sanitizer whose reason for existence is:

However, on many platforms the system-level TrueType font renderers have never been part of the attack surface before, and putting them on the front line is a scary proposition... Especially on platforms like Windows, where it's a closed-source blob running with high privilege.

There is currently no mention of this security aspect in the specification, so it seems that should go into this Security and Privacy section.

As an example of the security risk: Vulnerabilities in Windows Kernel-Mode Drivers Could Allow Remote Code Execution (2783534)

The more severe of these vulnerabilities could allow remote code execution if a user opens a specially crafted document or visits a malicious webpage that embeds TrueType or OpenType font files.

[svgeesus]

Installed Fonts states

Installed Fonts must not be Web Fonts, and Web Fonts must not be Installed Fonts.

This is significant, as on the one hand it prevents Web Fonts from being collected by the browser and installed as system fonts; and on the other hand, requires that Installed Fonts do not actually trigger a network request which would be a privacy risk.

[svgeesus]

@snyderp first draft of a Security & Privacy section checked in.

[litherum]

Oh, there's a well-documented attack where a site has a gazillion @font-face blocks, and each one has a unicode-range with a distinct character and a distinct remote src url. This means that the server hosting the font files can see which characters are used on a page.

[tabatkins]

I guess this relies on CSS injection to actually be a threat? Since otherwise the page could just observe the actual text. Or I guess it allows the page to attack in the absence of JS.