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. On Wed, Apr 13, 2022 at 9:46 AM Joshua Bell <jsb...@google.com> wrote: > On Wed, Apr 13, 2022 at 6:36 AM Yoav Weiss <yoavwe...@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. > > >> 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? >>> >> > 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. > > >> >>> >>>> 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/CAD649j5sfxu1%3D1hN42h_wcQTab2PV--TJofDNn25d_RAe6Ku%2BA%40mail.gmail.com.
