Also, any learnings/feedback from the Origin Trial? On Wednesday, April 13, 2022 at 3:35:02 PM UTC+2 Yoav Weiss wrote:
> 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/eadd7e0c-2f80-4141-9d50-0755c60cb01fn%40chromium.org.
