Intent to Prototype: Font Access

309 views
Skip to first unread message

Olivier Yiptong

unread,
Mar 9, 2020, 7:50:40 PM3/9/20
to blin...@chromium.org

Contact emails

oyip...@chromium.org, jsb...@chromium.org

 

Explainer

Font Enumeration API

Font Table Access API

(We're planning to revise the API slightly, decoupling from the FontFace object and combining the two docs. Updates pending.)


Summary

The Font Access APIs create the new capabilities on the web to enumerate fonts installed on the system, and obtain table data for each font. This enables web developers to create tools that use and manipulate font table data at a lower level than what is achievable today. 


for await (const metadata of navigator.fonts.query()) {

  console.log(metadata.postScriptName, metadata.fullName, metadata.family);

  const tables = await metadata.getTables([ "glyf", "cmap", "head" ]);

  // ...

}


Motivation

The Font Access APIs provide low-level access to font data. While most web applications so far have had the objective to render content for consumption, some productivity applications and libraries require fine control over how font data are handled.


A design tool is an example where existing web APIs are not sufficient. Designers often have custom fonts installed, and selection of local fonts is something native apps allow. If a document has been authored using a specific font, the web application should be able to express to the user that the document will not be able to be rendered with full fidelity. Additionally, the design tool might need to control how the font is rendered on screen, possibly manipulating the glyphs and spacing using lower level libraries, for example HarfBuz and Freetype compiled to WASM.


To support the above, the web application should be able to list all available fonts on the system, then obtain data from the font tables.


Risks

Interoperability and Compatibility

Earlier iterations of the APIs were presented at TPAC 2019 in Fukuoka. Other browser engine implementers expressed skepticism. However, some web app and library developers have shown keen interest in this because it unlocks their ability to provide a native-caliber authoring experience on the web.


Activation

The implementation should be usable right away. However, since this is exposing font data, I expect developers to use libraries to work with the font table data.


Privacy

Font enumeration is often cited as the vector of a lot of bits of entropy that could be used to fingerprint a user. We'll be using a permission prompt to ensure the user is aware of the access being granted and its potential effects. Furthermore, User Activation will be required before accessing the API.


Security

Font data is considered "untrusted". We currently sanitize font data before passing it into third-party C/C++ libraries in the renderer to prevent parser bugs from turning into sandbox escapes. We will initially sanitize the data returned by these APIs as well, but explore exposing raw table data eventually.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Current targets are Windows, Mac, Linux. Chrome OS will follow after.

The focus is to enable the web developers to cater to their existing users on Desktop.


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/6234451761692672

https://www.chromestatus.com/feature/5082047209013248


Requesting approval to ship?

No.


lith...@gmail.com

unread,
Mar 10, 2020, 6:22:18 PM3/10/20
to blink-dev
Hi!

Where will these APIs be standardized? I clicked on the link to the feature dashboard, and the "Consensus & Standardization" section doesn't mention which standardization body this will progress in.

The feature dashboard pages also say that no browsers have expressed any public signals about this API, which does not agree with the "Other browser engine implementers expressed skepticism" statement in this thread.

Thanks,
Myles

Manuel Rego Casasnovas

unread,
Mar 11, 2020, 10:37:53 AM3/11/20
to Olivier Yiptong, blin...@chromium.org

On 10/03/2020 00:50, Olivier Yiptong wrote:
> Font Enumeration API
> <https://github.com/inexorabletash/font-enumeration/blob/master/README.md>
>
> Font Table Access API
> <https://github.com/inexorabletash/font-table-access/blob/master/README.md>
>
> (We're planning to revise the API slightly, decoupling from the FontFace
> object and combining the two docs. Updates pending.)

Would be nice to have linked the TAG reviews too in the original mail:
* https://github.com/w3ctag/design-reviews/issues/399
* https://github.com/w3ctag/design-reviews/issues/400

There were a bunch of concerns there that would be great to see
addressed at some point (maybe with a new review once both APIs are merged).
And probably more discussion with other browser vendors is needed to get
feedback and agreement around these APIs.

My 2 cents,
Rego

Jeffrey Yasskin

unread,
Mar 13, 2020, 8:18:59 PM3/13/20
to Olivier Yiptong, blink-dev
A couple requests:
  1. Please try to move these repositories into the WICG or another community group: https://github.com/WICG/admin#contributing-new-proposals
  2. Please consider splitting the two specifications instead of joining them. While many of the same sites might use them, they seem to have different risks and so would benefit from separate discussion.
  3. I filed https://github.com/inexorabletash/font-enumeration/issues/17 about the fingerprinting risk of this font-enumeration API shape. I'm super in favor of some way to "add" local fonts to a web page, but like with the Contacts API, making it all-or-nothing seems like the wrong approach.
Thanks,
Jeffrey

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAo21k1sdhCPiUaf-JEx_R5B4KPhsNiR4prB6mzegpYwoRbtxw%40mail.gmail.com.

Frank Tang

unread,
Mar 15, 2020, 1:33:49 AM3/15/20
to Olivier Yiptong, blink-dev, Jungshik Shin
Does this enumeration API expose the Design languages and Supported languages of a font (see https://docs.microsoft.com/en-us/typography/opentype/spec/meta#metadata-tags

For example, if the user has https://docs.microsoft.com/en-us/typography/font-list/aharoni-bold (Aharoni Bold font family) on the system, it will be nice if the API can expose 
Script Tagsdlng:'Hebr'
slng:'Hebr', 'Latn'
to the caller for that font, and for CordiaUPC font family
Script Tagsdlng:'Thai'
slng:'Thai', 'Latn'
for that font

So the caller could figure out that they can use "CordiaUPC font family" for Thai text and ""Aharoni Bold for Hebrew text.
This is the kind of thing that you may need to put into the "7. Internationalization considerations"
of the API. Because without that information, it will be very difficult to use this API for text in different languages. 

Some more info you may want to read


Regards,
Frank



On Mon, Mar 9, 2020 at 4:50 PM Olivier Yiptong <oyip...@chromium.org> wrote:

Olivier Yiptong

unread,
Apr 13, 2020, 6:28:02 PM4/13/20
to lith...@gmail.com, blink-dev

Hi Myles,


It took a while, but we finally now have the standardization work under WICG: https://wicg.github.io/local-font-access/

The Font Enumeration and Font Table access standardization work has been coalesced into a single repository.


Thanks for noting the discrepancy RE: the Chrome Status page. It will get updated soon.


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Olivier Yiptong

unread,
Apr 13, 2020, 6:32:44 PM4/13/20
to Jeffrey Yasskin, blink-dev
Thanks for the feedback, Jeffrey.

We've merged the two specifications because we've changed the overall shape of the proposal: they are no longer associated with `FontFace`.

We think that the risk profile has changed from before and thus warrant the coalescing. Glad to revisit this decision after a round of review of the new shape.

RE: the file picker, we have reason to believe that the enumeration API works better for developers. However, we'll get data on this as we experiment and will support it with evidence.

Olivier Yiptong

unread,
Apr 13, 2020, 6:34:33 PM4/13/20
to Frank Tang, blink-dev, Jungshik Shin
Thank you for the comment. That is definitely a great suggestion.
I'll keep that in mind as the API takes shape, as we definitely need good internationalization support.

David Benjamin

unread,
Apr 14, 2020, 11:11:55 AM4/14/20
to Olivier Yiptong, Jeffrey Yasskin, blink-dev
On Mon, Apr 13, 2020 at 6:32 PM Olivier Yiptong <oyip...@chromium.org> wrote:
RE: the file picker, we have reason to believe that the enumeration API works better for developers. However, we'll get data on this as we experiment and will support it with evidence.

Could you expand on this? What kind of data are you looking to gather? Note experiments shipped to actual users still need to meet privacy requirements.

More importantly, working better for developers isn't the only question here. With the Contacts API, if we simply gave access to the user's full contacts list, that would also probably have worked better for developers. This question boils down to "would developers like more or less flexibility", which has an obvious answer, independent of the API in question. There are more considerations here or we'd run sites at ring 0 and move on.

The test for tightening the API is users' needs, including security and privacy. Developers are high on our Priority of Constituencies, but users are higher. On the privacy side, fonts are one of the single biggest fingerprinting vectors in the platform, so this is a key criteria for this API. Moreover, the risk of user harm is an information leak of a stable fingerprinting vector. That means the permission is effectively irrevocable, short of wiping all site data. (A one-time font enumeration and persistent font enumeration are roughly equivalent privacy-wise.) Any considerations around revocable permissions would need to be met by alternate means, like limiting the risk ahead of time.

A font picker would be a better starting point as it avoids these issues. (Perhaps coupled with some notion of persistence? That way sites could display previously-imported fonts in an in-content picker. Details here would depend on the sites' actual use cases.)
 

Olivier Yiptong

unread,
Apr 14, 2020, 6:08:03 PM4/14/20
to David Benjamin, Jeffrey Yasskin, blink-dev
Could you expand on this? What kind of data are you looking to gather? Note experiments shipped to actual users still need to meet privacy requirements.
 
Yes indeed. We're still meeting privacy requirements. The data we're gathering are qualitative in nature.
We've had strong positive signals from developers that a capability like font access is needed.

We're collaborating with these developers to determine whether or not:
  1. this capability is necessary
  2. the shape is adequate
Given that this is an experimentation and still early in the life of this API, we expect to iterate at least once or more on this.

More importantly, working better for developers isn't the only question here. With the Contacts API, if we simply gave access to the user's full contacts list, that would also probably have worked better for developers. This question boils down to "would developers like more or less flexibility", which has an obvious answer, independent of the API in question. There are more considerations here or we'd run sites at ring 0 and move on.

I agree. The power of the API and potential to expose additional bits of entropy are definitely aspects that we are taking into account.
More of the plan will be surfaced when we have additional data. We plan to mitigate the potential exposure of identifying bits through our permission model.
We plan to formally articulate this permission model at the Origin Trial phase. Given that we're still aiming for Dev Trial, this is out of scope for now.
 
The test for tightening the API is users' needs, including security and privacy. Developers are high on our Priority of Constituencies, but users are higher. On the privacy side, fonts are one of the single biggest fingerprinting vectors in the platform, so this is a key criteria for this API. Moreover, the risk of user harm is an information leak of a stable fingerprinting vector. That means the permission is effectively irrevocable, short of wiping all site data. (A one-time font enumeration and persistent font enumeration are roughly equivalent privacy-wise.) Any considerations around revocable permissions would need to be met by alternate means, like limiting the risk ahead of time.

I do not disagree. We think we have good mitigations for the potential fingerprinting exposure with a good permission model.
The idea is that User Activation will be required and a permission granted before enumeration can be accessed.
 
A font picker would be a better starting point as it avoids these issues. (Perhaps coupled with some notion of persistence? That way sites could display previously-imported fonts in an in-content picker. Details here would depend on the sites' actual use cases.)

We have considered a font picker approach before. We still think that it just does not provide the capabilities that design tools expect.
In some cases, the custom way to choose fonts are a competitive differentiator in design tools.
Reply all
Reply to author
Forward
0 new messages