Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
tantek opened this issue Jan 24, 2020 · 12 comments
Assignees
Labels

Comments

@tantek
Copy link
Member

@tantek tantek commented Jan 24, 2020

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:

Labels: css-fonts, css-fonts-4

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

@tantek tantek added the css-fonts-4 label Jan 24, 2020
@tantek tantek changed the title CSS Fonts 4 needs a proper Security and Privacy Considerations section [css-fonts][css-fonts-4] CSS Fonts 4 needs a proper Security and Privacy Considerations section Jan 24, 2020
@svgeesus

This comment has been minimized.

Copy link
Contributor

@svgeesus svgeesus commented Jan 24, 2020

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

@svgeesus svgeesus self-assigned this Jan 24, 2020
@pes10k

This comment has been minimized.

Copy link

@pes10k pes10k commented Jan 24, 2020

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

@svgeesus

This comment has been minimized.

Copy link
Contributor

@svgeesus svgeesus commented Jan 24, 2020

@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

This comment has been minimized.

Copy link
Contributor

@svgeesus svgeesus commented Jan 24, 2020

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

This comment has been minimized.

Copy link
Contributor

@svgeesus svgeesus commented Jan 24, 2020

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

This comment has been minimized.

Copy link
Contributor

@svgeesus svgeesus commented Jan 24, 2020

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

This comment has been minimized.

Copy link
Contributor

@svgeesus svgeesus commented Feb 18, 2020

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

@litherum

This comment has been minimized.

Copy link
Contributor

@litherum litherum commented Feb 19, 2020

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

This comment has been minimized.

Copy link
Member

@tabatkins tabatkins commented Feb 20, 2020

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

This comment has been minimized.

Copy link
Contributor

@litherum litherum commented Feb 21, 2020

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

This comment has been minimized.

Copy link

@khaledhosny khaledhosny commented Feb 21, 2020

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

This comment has been minimized.

Copy link
Contributor

@svgeesus svgeesus commented Feb 21, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.