[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.

[litherum]

The attack relies on the CSS being hosted by a third party. E.g. google fonts hosts css files that contain a bunch of @font-faces already. If they wanted to be evil, they could use this attack to “read” users’ webpages in real-time.

[khaledhosny]

But the attacker would get only a list of unique characters used in the page, not the actual text (andthe list for any sufficiently big page would be close to an entire alphabet).

[svgeesus]

But the attacker would get only a list of unique characters used in the page, not the actual text (and the list for any sufficiently big page would be close to an entire alphabet).

For most languages, yes. Specifically, this is an issue for Chinese, where knowing the 400 characters used in some text, out of the tens of thousands in the language does indeed pose a privacy risk.

[SelenIT]

Some fonts, like Material Icons or this one, can also potentially test whether the page contains the whole specific words using the ligatures feature...

[khaledhosny]

How would this happen? Processing font data is done by user agent not the server.

[SelenIT]

@khaledhosny thanks for correction! I had a misconception that user agent would not request the font if it has only a combined ligature glyph, but not separate glyphs for individual characters :). Now I realized that it would require the ability to predict the content of the requested file in advance, which is impossible.