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.
--
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.
Script Tags | dlng:'Hebr' slng:'Hebr', 'Latn' |
Script Tags | dlng:'Thai' slng:'Thai', 'Latn' |
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.
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.
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.)