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/CAD649j6eHWQmUV-_BMKeYsMULXNJm_4cBoAxspetm-eupgi9Yw%40mail.gmail.com.
