I LGTM'd in the tool but it didn't show up here, but y'all have my +1. Thanks for getting this done.
On Thursday, April 28, 2022 at 5:01:51 PM UTC-7 Joshua Bell wrote: > FYI, non-normative note added. I also followed up on the questions in the > Moz standards position thread, added a few more notes to the spec as well. > > On Wed, Apr 27, 2022 at 9:01 AM Alex Russell <slightly...@chromium.org> > wrote: > >> A non-normative note in the spec sounds good. Wouldn't want to block >> shipping on it. >> >> On Wednesday, April 27, 2022 at 2:05:53 AM UTC-7 Yoav Weiss wrote: >> >>> If we're going with exposing byte-by-byte representation of the fonts on >>> the user's filesystem, we should make that slightly more explicit. Maybe >>> add a note to >>> https://wicg.github.io/local-font-access/#font-representation-data-bytes >>> clarifying that point? >>> >>> I *think* that lack of normalization should resolve the issues Anne was >>> concerned about in https://github.com/WICG/local-font-access/issues/20, >>> where different normalization algorithms result in compatibility issues. I >>> also *think* it should resolve Tess' concerns RE user assumptions of the >>> fonts being Open-Type. Can you clarify those points with them? >>> >>> On Monday, April 25, 2022 at 6:12:00 PM UTC+2 Alex Russell wrote: >>> >>>> Normalisation isn't usually a goal for users that want the actual bytes >>>> of the local font in order to do the rendering themselves and can be an >>>> active non-goal given the ways that folks want to do custom grouping, >>>> enumeration, and rendering. Partners have consistently asked us not to >>>> remove information and I've never heard of a request for normalisation >>>> from >>>> a partner. >>>> >>>> This is in line with not adding OTS sanitisation for these files (we >>>> don't need to when the OS rendering pipeline isn't at potential risk), and >>>> highlights the way that the current design is isomorphic with local file >>>> access. >>>> >>>> I've LGTM'd it in the tool as a result. >>>> >>>> Thanks to everyone at Google for continuing to push this forward. >>>> >>>> Best Regards, >>>> >>>> Alex >>>> >>>> On Thursday, April 21, 2022 at 9:46:15 AM UTC-7 Joshua Bell wrote: >>>> >>>>> On Wed, Apr 20, 2022 at 4:21 AM Yoav Weiss <yoavwe...@chromium.org> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> 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? >>>>>> >>>>> >>>>> That is correct. The spec text is currently agnostic about what >>>>> happens. It could be made more forceful, e.g. that UAs are not required >>>>> to >>>>> normalize data, and that consumers of the API should code defensively. >>>>> >>>>> Folks that chimed in on the issues represented the spread of thoughts, >>>>> from not wanting to assume anything about fonts (which would preclude >>>>> future innovation) to considering a lack of normalization a flaw, even >>>>> for >>>>> image uploads. I haven't had a chance to respond in detail. >>>>> "Normalization" >>>>> could imply many things, from rearranging elements within general >>>>> container >>>>> formats (e.g. JFIF marker segments for images, SNFT tables for fonts, MP4 >>>>> data streams and captioning for audio/video) to dropping elements (e.g. >>>>> EXIF metadata in images, COLRv1 or Variable support in fonts, text >>>>> captions >>>>> from video) attempting to transcode (e.g. lossily converting an SVG image >>>>> to a PNG, or SVG font to OTF). The consumers of the API, on behalf of >>>>> users, expressly do not want to lose fidelity of the fonts, so that >>>>> designers creating content have access to tools as powerful as native. >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> 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/2de5d053-5e21-433c-856d-19e73fec37c2n%40chromium.org.
