Intent to Ship: Local Fonts Access API

[Ajay Rahatekar]

Contact emails

ds...@chromium.org, jsb...@chromium.org

Explainer

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

Specification

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

Design docs

Design Doc: https://bit.ly/2HWBOLi

Blog: https://web.dev/local-fonts/

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 the font data as a binary blob, 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/400

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 design their web applications to use web-based fonts as the primary set of font choices, but allow users to opt-in to take advantage of their local fonts for specific design needs.

If this feature were removed from the platform, web applications would lose the ability to enumerate local fonts and retrieve font data but otherwise are expected to continue to function.

Gecko: https://github.com/mozilla/standards-positions/issues/401

WebKit: https://lists.webkit.org/pipermail/webkit-dev/2022-April/032176.html

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

Adopted by: Boxy SVG

Other signals:

Ergonomics

The feature builds both enumeration and data access into the same new API. Separation was 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 for web developers to implement a font picker (either UI-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)

The API is designed to support additional functionality in the future. Several such additions are under consideration:

• Querying for a "system UI" font, for web applications that render text with their own text stack and need access to the full font data, but wish to match the local system appearance. This would be equivalent to the CSS "system-ui" generic font family.

• Querying for only "low entropy" fonts, i.e. fonts that are part of the operating system base installation. 

• Querying font metadata in specific languages. Fonts often contain metadata with language tags, but OS APIs for enumerating fonts typically return only the metadata for the active language.

• Providing additional metadata or events to notify web apps of changes to fonts, to refresh caches.

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

Mitigations to existing passive fingerprinting vectors using local fonts (i.e. via CSS and Canvas) have been considered in non-Chromium-based browsers, and should be considered for Chrome as well, but are outside the scope of this I2S. In light of those existing vectors, we do not believe this new API contributes meaningfully to new fingerprintability, and we assert that future privacy enhancements should be applied equally across all font-based vectors.

WebView Application Risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

This API does not change the behavior of any other existing APIs. 

Debuggability

No special considerations.

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

No

Flag name

font-access

Requires code in //chrome?

False

Tracking bug

https://crbug.com/535764

Estimated milestones

OriginTrial desktop  last       90
OriginTrial desktop first        87

We aim to ship in 102

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6234451761692672

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/3MW3ngOsUOk/m/iE0Bvg-6AwAJ

This intent message was generated by Chrome Platform Status.

--

Ajay Rahatekar | Technical Program Manager | ajayra...@google.com | 650-797-1279

[Yoav Weiss]

https://github.com/WICG/local-font-access/issues/20 and https://github.com/WICG/local-font-access/issues/19 are still open and seem to be increasing the interop risk here. Can you expand on plans to resolve them? 

WebKit: https://lists.webkit.org/pipermail/webkit-dev/2022-April/032176.html

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

Adopted by: Boxy SVG

Other signals:

Ergonomics

The feature builds both enumeration and data access into the same new API. Separation was 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 for web developers to implement a font picker (either UI-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)

The API is designed to support additional functionality in the future. Several such additions are under consideration:

• Querying for a "system UI" font, for web applications that render text with their own text stack and need access to the full font data, but wish to match the local system appearance. This would be equivalent to the CSS "system-ui" generic font family.

• Querying for only "low entropy" fonts, i.e. fonts that are part of the operating system base installation. 

• Querying font metadata in specific languages. Fonts often contain metadata with language tags, but OS APIs for enumerating fonts typically return only the metadata for the active language.

• Providing additional metadata or events to notify web apps of changes to fonts, to refresh caches.

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

Are we planning to monitor potential abuse of the API? (e.g. random sites requesting access-to-fonts permissions)

Mitigations to existing passive fingerprinting vectors using local fonts (i.e. via CSS and Canvas)

Aside, but I don't know that I'd consider those passive.

[Yoav Weiss]

Also, any learnings/feedback from the Origin Trial?

[Joshua Bell]

On Wed, Apr 13, 2022 at 6:36 AM Yoav Weiss <yoav...@chromium.org> wrote:

Also, any learnings/feedback from the Origin Trial?

Not distinct from the dev trial (i.e. developers trying the API behind a flag). There was a feature request for additional metadata which was implemented, then the request was withdrawn so that code was backed out. Other requests are marked as "enhancements" in the issue tracker, e.g. font modification timestamps.

https://github.com/WICG/local-font-access/issues/81 is also related and comes down to: how much do we shield the web app from the contents of font files? At one extreme, the data is normalized into some strict subset, stripping features. At the other, they are treated like files. When we started exploring the API we started in the middle exposing the font data in a more structured way (e.g. tables), but this (1) would lock the API into current font formats/concepts and (2) all sites planning to use the API are using common libraries that consume entire files, which already have robust parsing. So we lean heavily into the "treat them like files" - provide the data and get out of the way of the sites/libraries to use the rich data, similar to uploading images.

The API shape takes an options object, which would allow adding a filter for font file formats in the future, e.g. {accept: ["font/ttf", "font/off", "font/woff", "font/woff2"]}, so that sites could limit what types are provided. I could imagine us adding that and providing a default like the above if new formats become supported by the web but that might "surprise" sites. 

[Joshua Bell]

One thing to call out on the thread since it may not be obvious - per the chromestatus entry (https://chromestatus.com/feature/6234451761692672#details) the API will not ship on Android or WebView at the same time as desktop (W/M/L/CrOs). On those platforms, the API will not appear, so normal feature detection can be done.

We'd considered having the API present, but return an empty list, but thought that could train developers to expect that behavior on mobile platforms, whereas we do plan to support the API there in the future.

[Yoav Weiss]

So, no normalization happens on the font files? Is that reflected in the spec? Did you get any feedback on that approach from the folks that chimed in on the issues?

[Joshua Bell]

That is correct. The spec text is currently agnostic about what happens. It could be made more forceful, e.g. that UAs are not required to normalize data, and that consumers of the API should code defensively. 

Folks that chimed in on the issues represented the spread of thoughts, from not wanting to assume anything about fonts (which would preclude future innovation) to considering a lack of normalization a flaw, even for image uploads. I haven't had a chance to respond in detail. "Normalization" could imply many things, from rearranging elements within general container formats (e.g. JFIF marker segments for images, SNFT tables for fonts, MP4 data streams and captioning for audio/video) to dropping elements (e.g. EXIF metadata in images, COLRv1 or Variable support in fonts, text captions from video) attempting to transcode (e.g. lossily converting an SVG image to a PNG, or SVG font to OTF). The consumers of the API, on behalf of users, expressly do not want to lose fidelity of the fonts, so that designers creating content have access to tools as powerful as native. 

[Alex Russell]

Normalisation isn't usually a goal for users that want the actual bytes of the local font in order to do the rendering themselves and can be an active non-goal given the ways that folks want to do custom grouping, enumeration, and rendering. Partners have consistently asked us not to remove information and I've never heard of a request for normalisation from a partner.

This is in line with not adding OTS sanitisation for these files  (we don't need to when the OS rendering pipeline isn't at potential risk), and highlights the way that the current design is isomorphic with local file access. 

I've LGTM'd it in the tool as a result.

Thanks to everyone at Google for continuing to push this forward.

Best Regards,

Alex

[Yoav Weiss]

If we're going with exposing byte-by-byte representation of the fonts on the user's filesystem, we should make that slightly more explicit. Maybe add a note to https://wicg.github.io/local-font-access/#font-representation-data-bytes clarifying that point?

I *think* that lack of normalization should resolve the issues Anne was concerned about in https://github.com/WICG/local-font-access/issues/20, where different normalization algorithms result in compatibility issues. I also *think* it should resolve Tess' concerns RE user assumptions of the fonts being Open-Type. Can you clarify those points with them?

[Alex Russell]

A non-normative note in the spec sounds good. Wouldn't want to block shipping on it.

[Joshua Bell]

FYI, non-normative note added. I also followed up on the questions in the Moz standards position thread, added a few more notes to the spec as well.

[Alex Russell]

I LGTM'd in the tool but it didn't show up here, but y'all have my +1. Thanks for getting this done.

[Ajay Rahatekar]

Hello API Owners,

Please let us know if there are any outstanding concerns apart from the discussion on the Mozilla position, that we can address. The team is targeting M103 for shipping this api. 

Thanks for all your help and guidance.

-Ajay

[Yoav Weiss]

LGTM2

Thanks for pushing forward the discussions, and landing the spec in a good place from an interop perspective.

[TAMURA, Kent]

LGTM3

--
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/f4786591-4aad-474f-9977-d2e2f796c659n%40chromium.org.

--

TAMURA Kent
Software Engineer, Google