Font Enumeration API

[chasephillips]

こんにちはTAG!

I'm requesting a TAG review of:

• Name: Font Enumeration API
• Specification URL: https://wicg.github.io/local-font-access/
• Explainer (containing user needs and example code)¹: https://github.com/inexorabletash/font-enumeration
• GitHub issues (if you prefer feedback filed there): https://github.com/WICG/local-font-access/issues
• Tests: TBD
• Primary contacts (and their relationship to the specification): @chasephillips, @inexorabletash

Further details:

• Relevant time constraints or deadlines: We'd like to discuss this at TPAC (Sep 16, 2019) so getting TAG review before then would be great. Overall, we plan to Dev Trial in M79 (mid Oct, 2019) and Origin Trial in M80 (early Dec, 2019).
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles
• The group where the work on this specification is: TBD

We recommend the explainer to be in Markdown. On top of the usual information expected in the explainer, it is strongly recommended to add:

• Links to major pieces of multi-stakeholder review or discussion of this specification:
• Links to major unresolved issues or opposition with this specification:

We'd prefer the TAG provide feedback as (please select one):

• open issues in our GitHub repo for each point of feedback
• open a single issue in our GitHub repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

---

Please preview the issue and check that the links work before submitting. In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document.

¹ For background, see our explanation of how to write a good explainer.

[dbaron]

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

[dbaron]

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

[hober]

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

[hober]

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

[atanassov]

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

[inexorabletash]

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.

[oyiptong]

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

[hober]

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.

[oyiptong]

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.

[hober]

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?

[hober]

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

[inexorabletash]

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