Font Table Access API

[chasephillips]

こんにちはTAG!

I'm requesting a TAG review of:

• Name: Font Table Access API
• Specification URL: https://wicg.github.io/local-font-access/
• Explainer (containing user needs and example code)¹: https://github.com/inexorabletash/font-table-access/
• 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.

[annevk]

The various non-goals seem like they would make it rather hard for alternative approaches to doing fonts to enter the market or for smaller players with alternative approaches to compete. If even on the same platform the data you get back depends on the implementation it's highly likely sites will code toward a single implementation.

[chasephillips]

Hi Anne, thanks for taking a look at the table access API. I filed https://github.com/inexorabletash/font-table-access/issues/6 to discuss it further. Let's follow up there.

[dbaron]

A very brief comment here after looking at #399 -- it seems like there's less additional fingerprinting surface here -- but it's not zero, and worth mentioning. In particular, it seems like there are some changes in fonts that are not detectable on the web today, but would be detectable with raw font table access. Thus this might be providing the additional fingerprinting entropy to distinguish a user with version 1.0.4 of a font from one with version 1.0.5 of the same font in cases where that wasn't detectable today.

Hoping to look more later...

[plinss]

@hober and I reviewed this at our December F2F, this still feels like it's too low-level of an API and is geared strongly to OpenType fonts, where there are a number of different font technologies in use (and are likely to be more down the road). We'd rather see higher level APIs exposing font metrics and glyph vectors that are font technology agnostic.

[atanassov]

@plinss and I looked at the proposal as part of the March F2F. There isn't any new information or updates in the explainer or relevant issues.
Additional concern here is the dependency on Font Enumeration API and the fact that this proposal isn't progressing anymore.

Given we haven't heard back from the authors, should we consider there is no longer interest of making progress on either of these two proposals?

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

[hober]

We (@dbaron @hober @plinss) looked at this again during the TAG F2F this week. We've tried to file issues in the WICG/local-font-access repo which capture each of the concerns that have come up during the several TAG breakouts on these two reviews. Given the lack of engagement in these reviews thus far, we don't see any value in keeping these issues open. Please feel free to ping us to re-open or file a new issue when there are significant changes.

• Non-OpenType fonts #19
• Anne's feedback re: Non-goals and alternative approaches #20
• Fonts need to be sorted #23
• mention additional fingerprinting surface in details of font versions #25
• Please add a Table of Contents to the explainer #26
• explainer suggests iterating all the fonts in order to find Consolas #27

[inexorabletash]

Hey @hober - I think we're ready for another go-round on this. Should we re-use this or #399, or open a new issue?

Relative to the above list:

• Non-OpenType fonts #19
• Anne's feedback re: Non-goals and alternative approaches #20

⬆️ I believe these are effectively the same issue, although I may be missing nuance here. These are still fundamental issues, but apply to similar APIs for accessing local resources, e.g. file uploads, such as for images or videos, where web apps must be future-proof against new formats. That might suggest an approach, e.g. allowing (requiring?) web apps to specify accept to identify supported content types, e.g. query({accept: ['font/otf']})

• Fonts need to be sorted #23

⬆️ Should be resolved.

• mention additional fingerprinting surface in details of font versions #25

⬆️ Added.

• Please add a Table of Contents to the explainer #26

⬆️ Added.

• explainer suggests iterating all the fonts in order to find Consolas #27

⬆️ Resolved through allowing passing name list to query().

[inexorabletash]

@hober @plinss and anyone else - Can we re-open this per the above? We'd love to reboot the discussion here.

[annevk]

I really don't see the comparison to file uploads. With file uploads we don't provide some kind of normalized access to the underlying file that might differ across browsers. Each browser ends up with the same data.

I suppose what applies is that file uploads expose platform differences to websites, but I would take that as something to improve upon, not as something to imitate.

[atanassov]

Hi @inexorabletash, @plinss and I had a chance to go over the updates you linked to - thank you for these and reopening. These are the concerns we have after this review pass:

The expanded fingerprinting issue commit is good, however there is no mitigation suggestions just some info. For example, "in incognito mode, don't expose the fonts" or something similar is what we would generally expect.

It seems you added a choose method, but the mechanism is still of the format "give me all the fonts" and allow user to choose which fonts to expose. What we asked for was - "let the user choose a font and then you get back a font". Exposing all fonts runs into the issue of users just hitting "select all" and move on.

Another concern we have is the exposing the blob function and access to the font raw data. You stated that users of the API will want to provide data to libraries that expect all the fonts. That is the justification for the blob approach. Can you provide examples of such libraries you're talking about? Our assumption was that the goal of such API is to replace those libraries.

[inexorabletash]

For example, "in incognito mode, don't expose the fonts" or something similar is what we would generally expect.

Thanks - I'll add something. In practice, it might be more subtle than that. Browsers allow file upload in incognito, and exposure of specific fonts seems comparable.

It seems you added a choose method, but the mechanism is still of the format "give me all the fonts" and allow user to choose which fonts to expose. What we asked for was - "let the user choose a font and then you get back a font".

Correct, and understood. We consider it critical to support use cases where multiple fonts - including potentially all local fonts - are provided to the site in one user interaction. We tried to craft an API shape that would allow browsers to support this use case, or alternately (perhaps in more privacy-focused modes, or just different UAs) limit the number of fonts exposed, perhaps to just a single font.

Another concern we have is the exposing the blob function and access to the font raw data. You stated that users of the API will want to provide data to libraries that expect all the fonts. That is the justification for the blob approach. Can you provide examples of such libraries you're talking about?

To clarify: libraries expect the full data for a given font, rather than a subset of tables. An library example is the pairing of HarfBuzz and FreeType, used by many native and (more recently) web applications to implement custom text stacks. These take as input full OpenType font files, and do the table parsing themselves. We did early experiments with APIs that produced only some of the font tables, and to interoperate with existing libraries required glue code that recomposed a full container file from the parts.

Our assumption was that the goal of such API is to replace those libraries.

The goal of the API is to provide the data so that it can be consumed by those libraries.

[atanassov]

The issues as we see them so far:

1. there are a number of unresolved issues which have been raised during the course of this review (e.g. #19, #20, #62, etc.)
2. the fingerprinting risk is quite large here. There's always a tradeoff to be made regarding fingerprinting surface area and new functionality - however in our view the high risk is not commensurate with the benefit in this case.
3. the API seems to be on a trajectory to ship regardless of our feedback and the other negative feedback surfaced on this issue.

In conclusion: we think we should be more deliberate as stewards of the web platform in terms of how we represent fonts. We don't think this is the right approach to solve these use cases in the context of the wider web.