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

[jfkthame]

The description in the spec of the FontFaceSet.check() method 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, but FontFaceSet.check() with the throw-on-unknown-font behavior would make it particularly easy and efficient for authors.)

[tabatkins]

Sigh, that's annoying that nobody ever fixed to match; that spec text came from fairly early in implementation progress. That does explain why nobody ever pinged me to fix the obvious FIXME there, at least.

This is a slightly easier method to probe for installed fonts than the existing "render a span with font-family: "Local Font", "Weird Metrics Web Font"; and measure the size", but it's not a significant difference; the existing one can still run at approximately the browser's frame-drawing rate, or maybe half that, which is enough to run thru several hundred fonts in a handful of seconds, and entirely off-screen so the user has no idea. I don't think pursuing a change here for the purpose of reducing this privacy hole is a significant reason, since the gain from this API is so small relative to existing methods.

That said, I'm still comfortable going with Firefox's behavior (returning true when no fonts are matched at all) if browsers don't want to converge on matching the spec. (And I recognize that, at this point, changing to throwing an error would very likely be a webcompat issue, while changing from false to true for Chrome should probably be okay.)

[jfkthame]

Agreed, the privacy issue is minor given that it's just a quicker/easier way to do what can be done anyway via other routes (that we aren't likely to be able to do anything about, aside from the broader topic -- being explored separately -- of restricting use of system-installed fonts).

The relevant commit that introduced the throw expectation just says

Make the check() function differentiate between 'your font faces don't exist' and 'none of your fonts will render that example text'

but doesn't point to any further background. There was a lengthy discussion recorded in F2F minutes from 2015-05-20, but it didn't really seem very clear; there seemed to be conflicting opinions about the use cases and no real consensus on how it should behave.

I put a possible edit in #5757 for consideration.