Intent to Prototype: Font Access
Olivier Yiptong
Contact emails
oyip...@chromium.org, jsb...@chromium.org
Explainer
(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
Manuel Rego Casasnovas
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.)
* 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
- Please try to move these repositories into the WICG or another community group: https://github.com/WICG/admin#contributing-new-proposals
- 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.
- 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.
--
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
| Script Tags | dlng:'Hebr' slng:'Hebr', 'Latn' |
| Script Tags | dlng:'Thai' slng:'Thai', 'Latn' |
Olivier Yiptong
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3acc7fb4-1ec3-48a7-9ab8-e4d65b4c1361%40chromium.org.
Olivier Yiptong
Olivier Yiptong
David Benjamin
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAo21k2LxKoxwjseF0sB8-LJkO9vBDieuHF95hGO-u4r8PH3Fw%40mail.gmail.com.
Olivier Yiptong
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.
- this capability is necessary
- the shape is adequate
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.)