LGTM3
On Wed, May 11, 2022 at 5:02 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f4786591-4aad-474f-9977-d2e2f796c659n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- TAMURA Kent Software Engineer, Google -- 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/CAGH7WqHf0ZdL72k3nLFDHTOAPid5Ksc22DSbvzJWFVAj5GiPzQ%40mail.gmail.com.
