LGTM2 Thanks for pushing forward the discussions, and landing the spec in a good place from an interop perspective.
On Monday, May 9, 2022 at 7:20:53 PM UTC+2 Ajay Rahatekar wrote: > 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/f4786591-4aad-474f-9977-d2e2f796c659n%40chromium.org.
