Intent to Implement: Font Enumeration

[Chase Phillips]

Contact emails c...@chromium.org,jsb...@chromium.org Explainer https://github.com/inexorabletash/font-enumeration Design docs/spec TBD TAG review https://github.com/w3ctag/design-reviews/issues/399 Summary Today, no API exists to provide a list of local fonts to web applications. The proposed font enumeration API gives web applications the ability to enumerate local fonts along with a small amount of metadata about each font. Motivation Font enumeration is a missing capability that has prevented modern web apps from making full use of the web platform. Web apps that want to work with local fonts require the user to upload them to a server first. In some cases, web apps ask users to install a separate local program that provides additional capabilities like font enumeration and offers local fonts as a WebFont in order to work around this missing API. The font enumeration API will let a web app get access to a list of local fonts and some metadata without requiring these workarounds. Risks

Interoperability 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. If this feature were removed from the platform, sites would lose the ability to enumerate local fonts but otherwise are expected to continue to function. Web / Framework developers: Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: Strongly positive (https://crbug.com/535764#c2) Very positive support from web applications that interact with local fonts, such as Figma. Ergonomics This feature will frequently be used in tandem with the Font Table Access API, which is another newly proposed API. We expect font enumeration to be useful even without table access, which is why they are being proposed separately. 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 to add a font picker (either UX-driven or algorithmic) and API usage will see more traction once popular UI libraries build font pickers on top of it. Security The API provides access to table 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/inexorabletash/font-enumeration/blob/master/security-privacy.md

Debuggability No special considerations. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes All Blink platforms make use of local fonts, so this feature is useful on all platforms. Is this feature fully tested by web-platform-tests? No TBD Link to entry on the Chrome Platform Status https://www.chromestatus.com/feature/6234451761692672

[Daniel Bratell]

So this seems like it could be very useful and the main reason it's not been implemented long ago is security/privacy. The idea seems to be to protect this feature behind some kind of warning dialog which may be good enough, unless the user can be made to approve more than they should.

How would it work for a site that has both user tracking and creation tools? For instance, Google has both the ad network and Google Docs, would approving the use of local fonts to Google Docs also make the user easily trackable?

Installed fonts is, and has been, probably the strongest user identifier there is so someone that wants to track users would be stupid not to use them.

/Daniel

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPAf0porRkMGBo1VuCVSQZQJwHgAUb2q4D1WrJg5oXm%3DyhrjEg%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Ashley Gullen]

FYI web pages can already have one way to guess the list of locally installed fonts using canvas2d. You can use fillText() with different fonts, and then getImageData() to identify if something different was drawn, or if it used a default font (indicating it wasn't installed). You need a big list of font candidates to try and some CPU time, but you could in theory already use this to get a subset of all the locally installed fonts for fingerprinting purposes, without any prompt to the user. Here's a proof of concept:  https://www.scirra.com/labs/getfontlist.html

We actually use something like this in production to show a list of (a subset of) local fonts in a font picker.

For fingerprinting purposes I think the only difference with the API is you get the full list, rather than a subset, which increases its accuracy.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.z6w9xyy9rbppqq%40cicero2.linkoping.osa.

[Daniel Bratell]

Fingerprint protection seems to be on a slippery slope right now. Several fingerprint sensitive changes recently have used the argument that similar information is available elsewhere which somehow makes it ok, but the result is just that it becomes harder and harder to protect users against tracking.

I think that we should be very careful when accepting that argument for adding more information leakage.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73gDn3X0BtL2YMwfDSXMV9TYEreXMsfK%2B69aBS7Oy9Fy5Q%40mail.gmail.com.

[Ashley Gullen]

Well, I was thinking more that if this API has a prompt, maybe there could be a prompt added to the canvas case as well to block fingerprinting that way. E.g. if you try to render the same text 10 times with a different font each time, maybe it could throw up a prompt? It's hard to see how that would fit in to the drawing APIs though.

[Emil A Eklund]

On Thu, Aug 22, 2019 at 4:28 PM Ashley Gullen <ash...@scirra.com> wrote:
> Well, I was thinking more that if this API has a prompt, maybe there could be a prompt added to the canvas case as well to block fingerprinting that way. E.g. if you try to render the same text 10 times with a different font each time, maybe it could throw up a prompt? It's hard to see how that would fit in to the drawing APIs though.

It's not limited to canvas. One can do the same with getClientRects
and a regular element.

[Chase Phillips]

Thanks for your feedback so far, Daniel, Ashely, and Emil.

On Thu, Aug 22, 2019 at 4:52 AM Daniel Bratell <bra...@opera.com> wrote:

How would it work for a site that has both user tracking and creation tools? For instance, Google has both the ad network and Google Docs, would approving the use of local fonts to Google Docs also make the user easily trackable?

Hi Daniel, the requested permission is origin-scoped.

For other powerful APIs, we've ensured the APIs are only available from the top-level context through a feature policy.

We can commit to that restriction here so only the document whose URL is being displayed will be granted the permission by default.  I'll update the explainer.

Chase

[Chase Phillips]

I should also mention that one of our goals restricts this API to secure contexts.  By combining that goal, granting permission only in top-level frames by default, and using feature policy to delegate, this will in part ensure that we're consistent with the rest of the platform.

For specifics about how we might time or usage-limit access, we defer that to improvements to the Permissions API.

Chase

[Noam Helfman]

Another privacy use case to consider is that some users (mostly in big organizations) have custom web fonts installed and listing them could provide highly identifying information about the user company. 

[Alex Russell]

Hey Noam,

That's a good point and something we'll get added to the explainer. The API is designed to provide UAs the ability to filter the provided list, particularly in a "low trust" or "low engagement" mode. Like most of these APIs, UA's can also auto-deny the ability to request the permission -- hence the asynchronous permission request.

For organisations that are worried about this, I expect this (and other sensitive APIs) could be limited to certain sites under Admin policy (although that's out of scope for the public API and explainer).

Regards

[Boris Zbarsky]

Last I checked, Safari doesn't even allow web pages to _use_ local fonts outside a small whitelist, to reduce fingerprinting surface.  I suspect they would not be on board with this new API, again outside the small whitelist.

In general, the fingerprinting angle here probably needs some thought.

-Boris

[masatak...@gmail.com]

On Monday, August 26, 2019 at 11:58:36 PM UTC+9, Boris Zbarsky wrote:

Last I checked, Safari doesn't even allow web pages to _use_ local fonts outside a small whitelist, to reduce fingerprinting surface.  I suspect they would not be on board with this new API, again outside the small whitelist.

fyi: https://github.com/w3c/csswg-drafts/issues/4055#issuecomment-505281057

 

In general, the fingerprinting angle here probably needs some thought.

-Boris

On 8/21/19 2:48 PM, Chase Phillips wrote:

Contact emails c...@chromium.org,jsb...@chromium.org Explainer https://github.com/inexorabletash/font-enumeration Design docs/spec TBD TAG review https://github.com/w3ctag/design-reviews/issues/399 Summary Today, no API exists to provide a list of local fonts to web applications. The proposed font enumeration API gives web applications the ability to enumerate local fonts along with a small amount of metadata about each font. Motivation Font enumeration is a missing capability that has prevented modern web apps from making full use of the web platform. Web apps that want to work with local fonts require the user to upload them to a server first. In some cases, web apps ask users to install a separate local program that provides additional capabilities like font enumeration and offers local fonts as a WebFont in order to work around this missing API. The font enumeration API will let a web app get access to a list of local fonts and some metadata without requiring these workarounds. Risks

Interoperability 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. If this feature were removed from the platform, sites would lose the ability to enumerate local fonts but otherwise are expected to continue to function. Web / Framework developers: Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: Strongly positive (https://crbug.com/535764#c2) Very positive support from web applications that interact with local fonts, such as Figma. Ergonomics This feature will frequently be used in tandem with the Font Table Access API, which is another newly proposed API. We expect font enumeration to be useful even without table access, which is why they are being proposed separately. 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 to add a font picker (either UX-driven or algorithmic) and API usage will see more traction once popular UI libraries build font pickers on top of it. Security The API provides access to table 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/inexorabletash/font-enumeration/blob/master/security-privacy.md

Debuggability No special considerations. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes All Blink platforms make use of local fonts, so this feature is useful on all platforms. Is this feature fully tested by web-platform-tests? No TBD Link to entry on the Chrome Platform Status https://www.chromestatus.com/feature/6234451761692672

--
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 blin...@chromium.org.

[Daniel Vogelheim]

Hi, just wanted to make sure this will go through privacy + security review once it's ready.

This does look like it's all on the right track, and I suspect with a user permission we have adequate protection against the fingerprinting risks. It's hard to be sure without having all the pieces in place, though.

One (minor) nitpick on the priv + sec questionnaire: For "incognito mode", this considers as an alternative an anonymous, fixed set of fonts. That reduces fingerprinting at the expense of creating an Incognito-distinguisher, which might not be a good bet. It's likely better to also ask for permission there.

[Alex Russell]

On Wed, Aug 28, 2019 at 7:52 AM Daniel Vogelheim <voge...@chromium.org> wrote:

On Fri, Aug 23, 2019 at 4:44 AM Chase Phillips <c...@chromium.org> wrote:

On Thu, Aug 22, 2019 at 7:31 PM Chase Phillips <c...@chromium.org> wrote:

Thanks for your feedback so far, Daniel, Ashely, and Emil.

On Thu, Aug 22, 2019 at 4:52 AM Daniel Bratell <bra...@opera.com> wrote:

How would it work for a site that has both user tracking and creation tools? For instance, Google has both the ad network and Google Docs, would approving the use of local fonts to Google Docs also make the user easily trackable?

Hi Daniel, the requested permission is origin-scoped.

For other powerful APIs, we've ensured the APIs are only available from the top-level context through a feature policy.

We can commit to that restriction here so only the document whose URL is being displayed will be granted the permission by default.  I'll update the explainer.

I should also mention that one of our goals restricts this API to secure contexts.  By combining that goal, granting permission only in top-level frames by default, and using feature policy to delegate, this will in part ensure that we're consistent with the rest of the platform.

For specifics about how we might time or usage-limit access, we defer that to improvements to the Permissions API.

Hi, just wanted to make sure this will go through privacy + security review once it's ready.

Every API we ship does.

 

This does look like it's all on the right track, and I suspect with a user permission we have adequate protection against the fingerprinting risks. It's hard to be sure without having all the pieces in place, though.

It's worth noting that this dovetails nicely with recent Chrome announcements about work to reduce active fingerprinting. Sites could already gain much (if not 100%) of this information with a bit of JS, and closing those avenues off without crippling apps requires explicit capabilities, which we now provide in a more transparent way with this API.

 

One (minor) nitpick on the priv + sec questionnaire: For "incognito mode", this considers as an alternative an anonymous, fixed set of fonts. That reduces fingerprinting at the expense of creating an Incognito-distinguisher, which might not be a good bet. It's likely better to also ask for permission there.

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPNDNHjJHT2QcN7%3DE6ebCmSMFcnV2b%2BxLRAOETay-eUSxg%40mail.gmail.com.

[Chase Phillips]

(resending to list)

On Fri, Aug 23, 2019 at 9:51 AM 'Alex Russell' via blink-dev <blin...@chromium.org> wrote:

That's a good point and something we'll get added to the explainer. The API is designed to provide UAs the ability to filter the provided list, particularly in a "low trust" or "low engagement" mode. Like most of these APIs, UA's can also auto-deny the ability to request the permission -- hence the asynchronous permission request.

Thanks, noted under "Privacy and Security Considerations".

On Mon, Aug 26, 2019 at 7:58 AM Boris Zbarsky <bzba...@mit.edu> wrote:

Last I checked, Safari doesn't even allow web pages to _use_ local fonts outside a small whitelist, to reduce fingerprinting surface.  I suspect they would not be on board with this new API, again outside the small whitelist.

Thanks for your feedback.  The API gives a lot of flexibility to browser implementations to choose how they want to expose this functionality.  Originally, the explainer mentioned under privacy and security considerations that browsers may choose to only provide a set of default fonts for their implementation.  I updated the explainer's goals to make this clear there, too. (https://github.com/inexorabletash/font-enumeration/pull/11)

On Wed, Aug 28, 2019 at 7:52 AM Daniel Vogelheim <voge...@chromium.org> wrote:

One (minor) nitpick on the priv + sec questionnaire: For "incognito mode", this considers as an alternative an anonymous, fixed set of fonts. That reduces fingerprinting at the expense of creating an Incognito-distinguisher, which might not be a good bet. It's likely better to also ask for permission there.

Agreed.  I've updated the priv+sec questionnaire with this note.  Thanks! (https://github.com/inexorabletash/font-enumeration/pull/12)

Chase