On Wed, Apr 13, 2022 at 6:46 PM 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. > 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? > > 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/CAL5BFfUdXwAxJH%3DL_%3DuAoPaKuVewkgOTRR%3DFHQu3SYyA1a1zeg%40mail.gmail.com.
