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/f0441a29-c30a-4601-9c17-3c96421c1dafn%40chromium.org.
