[webkit-dev] Request for position: Local Font Access

[Joshua Bell]

Thank you for taking a look!

On Fri, Apr 8, 2022 at 8:07 AM Sam Sneddon <gsnedders at apple.com> wrote:

> On 7 Apr 2022, at 23:34, Joshua Bell via webkit-dev <
> webkit-dev at lists.webkit.org> wrote:
> >
> > This is a request for WebKit's position on introducing an API that
> allows sites to request access to local font data, for use with content
> authoring tools that use custom text stacks.
> >
> > Links:
> > * Explainer: https://github.com/WICG/local-font-access/
> > * Spec: https://wicg.github.io/local-font-access/
> > * ChromeStatus: https://chromestatus.com/feature/6234451761692672
>
> I’ll let others respond with regards to the font-data side, but from the
> font selection point of view:
>
> The status quo for the Cocoa ports (macOS, iOS, etc.) is that only
> default-system fonts can be accessed from web content, and we’re concerned
> about undoing that change (it’s well documented that fonts have frequently
> been used as fingerprinting vectors). It is highly likely that any JS
> enumeration of fonts would be similarly limited to avoid increasing
> fingerprinting surface, if we were to implement such an API.
>
> I believe we mentioned previously that we were strongly in favour of not
> allowing JS to enumerate fonts in any way, and would prefer to go in the
> path of a UA provided font selector.
>
> This is touched on in the explainer:
> https://github.com/WICG/local-font-access#add-a-browseros-provided-font-chooser
>
> > The proposed API exposes some more bits about the user via the web that
> could improve fingerprinting efforts. The bits are based on the presence or
> lack of presence of certain fonts in the enumeration-returned list.
> >
> > An alternative to the API that only exposes a single user-selected font
> was considered. This alternative enumeration API would trigger a
> browser/OS-provided font chooser and, from that chooser, the user would
> select a single font. This would reduce the bits exposed to help mitigate
> fingerprinting at the cost of significant new functionality.
> >
> > We've heard interest from partners in a full-fledged enumeration API to
> get access to the list of available fonts on the system, and haven't heard
> interest in a font-chooser approach to the enumeration API. However, we're
> keeping the alternative in mind as we balance the need for new
> functionality with privacy concerns.
>
> We would be interested in hearing what your (Google’s? Chromium’s?
> Chrome’s?) partners have in way of use-cases that can only be fulfilled
> with the ability to enumerate fonts in JS, rather than have the UA mediate
> access to the fingerprinting-sensitive list.
>
>
Although it may not be clear in the explainer, we were careful to design
the proposed API so that a UA could provide a font selection UI instead of
a yes/no permission, allowing the user to select a subset of fonts to share
with the site. (The explainer could use an update to make this better, and
the spec is of course mostly obtuse spec language.)

To the question though: multiple currently-native and also web-based design
tools consider their font selection UI to be a key differentiator for their
experience - e.g. announcing improvements to the font UI as part of product
releases, experimenting with ML-driven font suggestions based on themes,
integrating previews of selected text with the font, and so on. We did work
with partners to prototype and explore a two-stage experience, where the
user would be provided with a UI to select fonts (akin to a "select fonts
to upload to the site"), after which the site would cache the results and
integrated the local fonts into their font picker. We didn't believe this
was a significant improvement to user privacy over a permission choice, and
significantly harmed the user experience.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20220408/9cfda9c2/attachment.htm>