W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2020

[csswg-drafts] [css-font-loading] FontFaceSet.check() method: reality vs spec vs privacy (#5744)

From: jfkthame via GitHub <sysbot+gh@w3.org>
Date: Wed, 25 Nov 2020 12:42:15 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-750785267-1606308134-sysbot+gh@w3.org>
jfkthame has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-font-loading] FontFaceSet.check() method: reality vs spec vs privacy ==
The description in the spec of the [FontFaceSet.check() method](https://drafts.csswg.org/css-font-loading/#font-face-set-check) does not match reality as implemented in any of the major browsers I've tried; moreover, the behavior called for by the spec is bad for privacy as it trivially exposes the set of installed fonts.

Consider the behavior of `document.fonts.check("12px foobar")`, assuming no font family named "foobar" is present.

According to step 3 of the algorithm in the spec,

>  If _found faces_ is false, throw an XXX error and abort this algorithm.

this should throw an (unspecified?) error.

No browser I have tested does this. It seems that:

* Gecko (Firefox) returns `true`, which makes sense in terms of the general description of what `check()` does:

> If the given text/font combo will render without attempting to use any unloaded or currently-loading fonts, this method will return true

but does not take account of step 3 in the algorithm, which is explicitly called out as the second "special case" in the note.

* Webkit (Safari) also returns `true`.

* Blink (Chrome, Brave) returns `false`, which I believe must be considered a bug: the given font/text will not "use any unloaded or currently-loading fonts", so this is both misleading to the author (it implies the given font is known but currently unloaded or loading) _and_ non-spec-compliant.

The fact that browsers are supposed (per spec) to _throw_ if `check()` is called with a non-existent font name was noted 5 years ago in bug reports against both (Gecko)[https://bugzilla.mozilla.org/show_bug.cgi?id=1252821#c7] and (Blink)[https://bugs.chromium.org/p/chromium/issues/detail?id=591602#c7], but the situation remains unchanged: no browser does so.

Given that:

* Nobody has apparently implemented step 3 of the specified algorithm (so the web cannot be depending on it); and

* If implemented, it would offer authors a trivial way to probe the set of installed system fonts, which represents an attractive fingerprinting vector;

I propose we should simply remove this step (and the corresponding note about the special-case behavior) from the spec.

(I am aware that font fingerprinting can also be achieved through `@font-face`, as mentioned [in the spec](https://drafts.csswg.org/css-font-loading/#priv-sec), but `FontFaceSet.check()` with the throw-on-unknown-font behavior would make it particularly easy and efficient for authors.)

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5744 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 November 2020 12:42:17 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:22 UTC