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/52e03101-c60d-45f5-af43-ddf41bbc277dn%40chromium.org.
