Intent to Experiment: Local Font Access

[Olivier Yiptong]

Contact emails

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

Explainer

https://github.com/WICG/local-font-access

Specification

https://wicg.github.io/local-font-access/

Design docs

Blog: https://web.dev/local-fonts/
Design Doc: https://bit.ly/2HWBOLi

Summary

Gives web applications the ability to enumerate local fonts and some metadata about each. Today, no API exists to provide a list of local fonts to web applications. Also gives web applications access to table data stored within local fonts, allowing those fonts to be rendered within their applications using custom text stacks.

Blink component

Blink>Fonts

TAG review

https://github.com/w3ctag/design-reviews/issues/399

TAG review status

Pending

Risks

Interoperability and Compatibility

This API has been designed to support feature detection to allow applications to gracefully degrade based on the capabilities different user agents offer. We expect developers using this API to use a mix of local and web-provided fonts. If this feature were removed from the platform, sites would lose the ability to enumerate local fonts and retrieve font data but otherwise are expected to continue to function.

Gecko: No signal

WebKit: No signal

Web developers: Strongly positive (https://crbug.com/535764#c2) Very positive support from web applications that interact with local fonts, such as Figma.

Ergonomics

The feature builds both enumeration and data access into the same new API. Separation was strongly considered but rejected. (See the Explainer for more details.) That may limit use.

Activation

Developers will be able to take advantage of this feature immediately since it uses the same available local fonts that other native applications have access to. The API makes it possible to add a font picker (either UX-driven or algorithmic) and API usage will see more traction once popular UI libraries build font pickers on top of it. Content for this API is available immediately since the API uses locally-installed fonts that are already present on the user's system. Usage of this API by an average web developer will require additional text shaping software that would render fonts based on data returned by this API. (eg. a Harfbuzz-in-WASM library)

Security

The API provides access to full font data in local fonts which can expose additional information about a user's installed configuration to a web application. This new API is behind a permission prompt, making this an active fingerprinting target. See the TAG review's security and privacy questionnaire for more info: https://github.com/wicg/local-font-access/blob/master/security-privacy.md We are exploring ways to mitigate the fingerprinting risk by way of changing the user experience through UIs. We don't expect the API shape to be affected.

Goals for experimentation

We will validate the shape of the API with a wider set of developers than from those we worked with in Dev Trial. In particular, we'd like to see if the metadata exposed is sufficient for most use-cases. We will also validate some performance assumptions we made with a wider set of users.

Ongoing technical constraints

No constraints.

Debuggability

No special considerations.

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

No

All Blink platforms make use of local fonts, so this feature is useful on all platforms. Only the desktop (Windows, Mac, Linux, ChromeOS) platforms will be supported at first due to the use-cases we're looking at occur predominantly on the desktop.

Is this feature fully tested by web-platform-tests?

No

Tracking bug

https://crbug.com/535764

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6234451761692672

This intent message was generated by Chrome Platform Status.

[Mike West]

LGTM.

Fonts are exciting(!) from a privacy perspective, insofar as the set of fonts available on a given user's machine is identifying, and a well-known component of fingerprinting strategies in use today. Given that risk, and the difficulty of contextually explaining it to users in a way that allows them to make an informed decision, there's still a good deal of discussion about how this capability should be presented in our permission UX. It seems quite reasonable to me to begin experimenting in earnest with the UX treatment we currently have in order to learn whether the API actually solves the problem it aims to address.

That said, I expect the UX treatment to shift as we learn more about how the API is used. In particular, I expect experimentation with a chooser-based presentation to get a better feel for the tradeoffs that come with that kind of question. With that in mind, I'm looking forward to hearing developer feedback from this OT, and getting more feedback from users about the way the API is presented. 

-mike

[François Doray]

Hi Olivier,

We conducted an experiment to assess the impact of accessing a large number of font families on Chrome speed (without the Local Font Access API). This indicated that sites which access a large number of fonts (usually for fingerprinting) negatively affect input delay. Experiment results.

My understanding is that origins will need to obtain permission from the user to access the Local Font Access API? If so, once the Local Font Access API ships, would it make sense to limit the number of font families that a page can access, when it doesn't have the Local Font Access permission?

Have a nice day,

François

--
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/5946f9db-f6b6-4807-8782-29626b99a03an%40chromium.org.