Hello API Owners, Please let us know if there are any outstanding concerns apart from the discussion on the Mozilla position <https://github.com/mozilla/standards-positions/issues/401#issuecomment-1115057239>, that we can address. The team is targeting M103 for shipping this api.
Thanks for all your help and guidance. -Ajay On Wednesday, May 4, 2022 at 8:37:03 AM UTC-7 sligh...@chromium.org wrote: > 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 <sligh...@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 <yoav...@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 <yoav...@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 | >>>>>>>>>>> ajayra...@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/68cd08ef-7739-4ef3-bfd6-145cd5790f4fn%40chromium.org.
