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/b1b45b66-677d-4d02-bc81-94b9d5c7b57en%40chromium.org.
