On Friday, April 8, 2022 at 8:15:42 PM UTC+2 Ajay Rahatekar wrote:
> 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 > 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 <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 > 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. > 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/c130b923-50c5-4349-ae39-261deafe11dan%40chromium.org.
