@ylafon and I are looking at this during a breakout at the Tokyo TAG face-to-face meeting.

One issue that doesn't appear to be addressed in the Security and Privacy questionnaire response is the question of fingerprinting. Having an API for font enumeration seems like it makes font-based active fingerprinting substantially easier and faster. That's something that needs to be traded off against the use cases for the feature -- use cases that aren't especially clear in the explainer.

It would probably be helpful if the explainer gave some compelling examples of user-facing features that would be enabled by this web feature. This would also help understand the question of whether there are other less-powerful APIs that could address the same use cases, for example, APIs designed for finding similar fonts.

It's also worth noting that past studies of font-based fingerprinting had reported entropy that included order data from plugins. One of the major plugins (I don't remember if it was Java or Flash) had a font enumeration API that returned the fonts in a system-specific sort order that I think was a function of the time the font was installed on the system. This provided a large amount of additional entropy that was totally unnecessary for the feature. At the very least it seems important for the spec to prescribe a sort order for the enumeration to avoid a repeat of this problem.

I've still been hoping to find the time to take a somewhat closer look at this, but haven't managed to do that yet.

Also, @ylafon points out that the explainer in #400 seems to provide a rather bad example of the use of this API -- it enumerates all of the fonts on the system just to find "Consolas" -- it seems like that would be much better addressed by an API that lets you ask for "Consolas".

Labeling as a Fugu-related request since it appears in Fugu's full list of capabilities.

@plinss and I took another look at this in our Cupertino F2F. We share @dbaron’s & @ylafon’s desire for a “ less-powerful APIs that could address [some of] the same use cases”—in particular, a picker-style API could allow sites to receive access to specific fonts that they need (like Consolas in the previous example) without exposing the list of installed fonts.

@plinss remembers a TPAC conversation from Fukuoka, perhaps in the Houdini TF, where a picker-style API got significant support.

@plinss and I had another look at this topic and its relevance to Font Table Access API.

There has been no progress we observed and given how tightly coupled the two API proposals are our proposal is to close the issue.

re: lack of progress - we deferred work for a while, but are planning to revisit in the very near future.

re: two proposals - we are planning to re-merge the proposals; at one point we thought splitting them made sense to unblock some discussion. Closing one of these out is fine.

Hi folks, apologies about the delays.

Here's a quick summary:

• The enumeration API now provides an object, FontMetadata that is not related to Web Fonts
• Font table data aren't accessible individually anymore
• There's a method to obtain byte-wise font data, i.e. blob()
• Use cases are now more elaborately fleshed out

I wrote in December 2019:

@plinss and I[...] share @dbaron’s & @ylafon’s desire for a "less-powerful APIs that could address [some of] the same use cases"—in particular, a picker-style API could allow sites to receive access to specific fonts that they need (like Consolas in the previous example) without exposing the list of installed fonts.

@plinss remembers a TPAC conversation from Fukuoka, perhaps in the Houdini TF, where a picker-style API got significant support.

We still believe that a picker-style API solves the most pressing user needs while having far preferable characteristics re: privacy, which we've documented in our Web Platform Design Principles document (specifically in 8.2. Use care when exposing APIs for selecting or enumerating devices).

Note that such an approach would also address WICG/local-font-access#36 and WICG/local-font-access#62.

From this comment it looks like you're considering a picker-style API alternative. We look forward to learning more about it.

Indeed, we've been making progress with the API and have been prototyping a chooser behind a flag.
We're planning to launch another Origin Trial soon, with a modified API shape.

I'll be amending the explainer and spec copy soon.

Indeed, we've been making progress with the API and have been prototyping a chooser behind a flag.
We're planning to launch another Origin Trial soon, with a modified API shape.

I'll be amending the explainer and spec copy soon.

Any updates for us?

@plinss and I took another look at this today in our F2F and it seems we're still waiting on updates from @oyiptong. We're going to close this; please let us know when you're ready for us to take another look and we'll reopen it.

@hober @torgo and anyone else - I commented over in #400 (sorry about the two issues!) but we're ready for another look. Pinging here hoping for attention too.