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 docsDesign Doc: https://bit.ly/2HWBOLi <https://chromestatus.com/admin/features/launch/6234451761692672/Design%20Doc:%20https://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 <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFonts> TAG review https://github.com/w3ctag/design-reviews/issues/400 TAG review status Pending RisksInteroperability 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 <https://boxy-svg.com/app> 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 <https://chromestatus.com/feature/5640395337760768>. - 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 <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> ? 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 <https://chromestatus.com/>. -- Ajay Rahatekar | Technical Program Manager | ajayrahate...@google.com | 650-797-1279 <(650)%20650-797-1279> -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHB%2BDAixuJx20aCUMPGQsq_13Xo8v-%2BfQnKd15R11-M7CWMXRA%40mail.gmail.com.
