Request for position: Local Font Access
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
On 7 Apr 2022, at 23:34, Joshua Bell via webkit-dev <webkit-dev@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-choo...
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. /Sam
Thank you for taking a look! On Fri, Apr 8, 2022 at 8:07 AM Sam Sneddon <gsnedders@apple.com> wrote:
On 7 Apr 2022, at 23:34, Joshua Bell via webkit-dev < webkit-dev@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-choo...
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.
participants (2)
-
Joshua Bell
-
Sam Sneddon