Context for Security Considerations

[tolmasky]

Related to #6, I was just curious if there was a good place to find context around security considerations in general. I have some thoughts/questions regarding this being a privileged action, but before I do that I wanted to know if there was a good sum up of what the potential dangers actually are. Given OTS, do all security concerns basically boil down to fingerprinting? Or is there some additional things to worry about?

[chasephillips]

Hi again @tolmasky, I'm not aware of a general resource.

I recommend taking a look at the Features restricted to secure contexts site as a starting point to see what other APIs require secure contexts. Each of those APIs will most likely include in their specifications sections on security and privacy concerns indicating their security considerations.

I have some thoughts/questions regarding this being a privileged action, but before I do that I wanted to know if there was a good sum up of what the potential dangers actually are. Given OTS, do all security concerns basically boil down to fingerprinting? Or is there some additional things to worry about?

Fingerprinting, authenticity of the code executing on behalf of the origin, and secure transmission of user data are at least some of the additional security considerations we have in mind.

[tolmasky]

Hi @chasephillips,

I've seen that page before, and its partially where my confusion comes from. I can totally understand caring about the authenticity of the code executing on behalf of the origin with relation to payments and push notifications, but I just don't see the danger with something as basic as font enumeration. Getting a list of fonts just doesn't seem to raise any red flags for needing such a heavy-handed restriction as top-level frames and Secure Contexts (with the aforementioned sole exception perhaps of fingerprinting).

Given that there seem to be no explicit easily enumerable "security dangers" beyond fingerprinting, I would much prefer if this was not a restriction that was placed on this feature, which would greatly reduce some of the cooler applications (embedded editors that make use of font-menus, etc.). If the only problem is fingerprinting, we could think of alternate ways of resolving this, whereas if there exist other known problems, then something this heavy-handed may be more justified.

It would also feel weird to the user that a document editing top-level site might have a font menu with all their fonts, but an embedded editor in their blog editor does not. What's worse, is that we already have an entire variety of really hacky ways of establishing installed fonts (loading two divs with different fonts and comparing the sizes). So all this would really accomplish is falling back to these methods for "polyfills", and given that these already exist, it might be perceived that its not even worth it to "upgrade" to this new API: why would you use a new API that only works some of the time, when you can continue using an old script that works "all the time"?

[chasephillips]

It's great to hear that you're interested in using this API. However, it appears we differ significantly on our approach to security/privacy. I wouldn't try to convince you of the potential dangers from fingerprinting on the web platform, but obviously because we consider fingerprinting as potentially dangerous, we've designed this API with protections in mind like a permission prompt, secure context requirement, and only available on the top-most frame by default:

• Permission prompt -- the browser will show a permission prompt to a user that gives the user the ability to allow or deny a site access to the list of installed local fonts. Users can determine for themselves whether they wish to allow a site to get access to this data. I believe you agree that this feature should only be provided behind a permission prompt.

• Secure context -- for the permission prompt the browser shows the user to mean something, the browser has to establish the identity of the site so the user can trust what the browser displays in the permission prompt. Otherwise a user that would only grant access to a specific verified site could be tricked into granting access to an unverified site claiming to be that verified site. The secure context grants the permission prompt meaning. This means unverified sites can't use the feature, but this is a small cost to pay if it means verified sites can establish a trust relationship with browsers and users. If you're aware of another way to verify a site and to ensure only verified sites can use this API besides a secure context, please let me know.

• Top-most frame by default -- this requirement allows a site to ask for the capability while embedding iframes from other sites that the site wouldn't otherwise want to convey the permission to. In the example you give, an iframe-embedded editor in their blog editor would only not have the list of fonts if the blog editor doesn't convey the local-fonts permission. Resolving that requires the blog editor to change their iframe element's allow attribute to grant that permission, which I presume they would do if they wanted to use an iframe-embedded editor. Can you confirm that would resolve the issue you raise with top-most frames? Are there other use cases that this change restricts?

[tolmasky]

Hi Chase,

I'm not sure how you've reached the assessment on how much we differ on our approach to privacy and security, given that I have so far mainly been asking about your approach and trying to get a clear idea of what the perceived dangers are, and have only listed capabilities that would be set back for context. I started the conversation wishing to know if there were known issues beyond just fingerprinting, which is completely accomplishable today by doing manual font-detection. Unfortunately, it seems that we are actually still at this extremely early (and theoretically simple) part of the conversation, as I still have not gotten a straight answer on whether fingerprinting is the only concern, or if there are others.

I assure you that if there was a clear place where the actual dangers could be outlined, specifically whether there are any beyond fingerprinting, and additionally how fingerprinting is made any worse with this API given, as I already mentioned, there are already manual techniques for detecting fonts how this API exacerbates fingerprinting in any meaningful way, we might find that our security and privacy approaches actually don't differ at all and I may very well be completely swayed to your side.

Regarding your specific points:

1. Permission prompt - no, currently I am not convinced at all about permission prompts and in fact believe that it could potentially be destructive for security. Without a clear understanding of the specific security concerns, I think adding a permission prompt for something as seemingly trivial as font detection (to the user) will IMO simply add on to the confusion of the plethora of prompts users already receive and are increasingly trained to not read and simply click OK to. IMO adding a prompt for this (without understanding the security context) could actually decrease the security of other more important features as we've repeatedly seen that user's get trained to just click away these prompts, and if you for example first throw up a font prompt, followed by a camera prompt, the user might just give more permissions to the site than they want as they just try to fight to get to their content. Prompts are only effective (beyond a mere plausible deniability tool for the browser maker) if they are used sparingly and meaningfully.

2. Secure context - the argument for this rests on the argument for the above. So sure, if I'm convinced we need a permission prompt then I guess I'd be fine requiring a secure context.

3. I think I am fully satisfied with the allow attribute you mention.

I want to attempt once more in good faith to express my position: I do think security is important, I merely think, lacking context beyond fingerprinting, that the current strategy will encourage more misuse. There are already effective methods for font detection today. Most users end up using browser APIs through other frameworks. If a user has the option between a library that works without user prompt, and is backwards compatible to older browsers, vs. one that has the potential to fail if the user clicks "no", then they will have little to no incentive to use this new API. This is a very different situation than something like the camera API where there was no existing usable standards-based implementation already heavily used in the wild. With the camera API, you could be as onerous as you'd like since 1) it was the only way to get access to the camera, and 2) there are obvious security concerns beyond ad tracking.

[chasephillips]

There are multiple threads going at once. To make progress, I propose we break them up and work through them one-by-one. Let's work on the first thread now: what are the potential dangers with this new API?

Unfortunately, it seems that we are actually still at this extremely early (and theoretically simple) part of the conversation, as I still have not gotten a straight answer on whether fingerprinting is the only concern, or if there are others.

I'm sorry, admittedly, I thought I answered this already in https://github.com/inexorabletash/font-enumeration/issues/7#issuecomment-527764794: Fingerprinting, authenticity of the code executing on behalf of the origin, and secure transmission of user data. No, fingerprinting is definitely not the only concern!

OTS helps to eliminate some of the danger, but it's possible that a problem could be triggered with a specially-crafted local font that OTS doesn't handle which exposes local font data into a JS-based font stack and that problem triggers a deeper security problem in the JS-based font stack.

Yes, manual font detection exists in the web platform today. There are multiple techniques to manually detect fonts and success isn't guaranteed... results vary based on approach, the attempted font list, and browser implementation. This new font enumeration API can give a complete list of local fonts. Fingerprinting success depends on how many bits of entropy can be gathered, so if a complete list gives more bits of entropy than manual font detection and does so all of the time, the difference causes the fingerprinting danger to increase. This means that the fingerprinting problem with the font enumeration API should be considered different from fingerprinting with manual font detection techniques.

Some other dangers with the proposed API:

• If the permission prompt text doesn't correctly communicate the danger of granting API use to a site, the user may get confused and improperly allow access when it wasn't intended or deny access when it was intended.

• Adding any permission prompt requires considering user permission prompt fatigue. As users become exposed to more prompts, they may not be able to correctly assess the prompt.

• Users with many local fonts will trigger enumerating a large number of local fonts in the browser which could overload system resource usage. The API is designed to mitigate this using async iterators, but there could be performance concerns if an implementation isn't careful, which could lead to security issues like DOS'ing a browser.

Does this address your first question?

Some of these have been mentioned already in the explainer and security/privacy questionnaire. I'll make a note to add any that aren't there already.

[chasephillips]

Hey Francisco, gentle ping on https://github.com/inexorabletash/font-enumeration/issues/7#issuecomment-539749438 in case it flew by and you didn't catch it. Thanks!

[tolmasky]

Hi @chasephillips, yes I have a longer form response that I haven't had time to finish yet. I'll try to get it posted in the next few days. Thanks!

[chasephillips]

SG, will keep an eye out.

[chasephillips]

Hi Francisco, any updates here? Happy to take a look at anything you have, even if you don't have time for the longer form response.

[tolmasky]

Hey @chasephillips, will attempt to get to this today or tomorrow. Also -- if you are based in the bay happy to meet in person to discuss more or even a phone call.

[tolmasky]

Hi @chasephillips,

I agree that there are a number of issues floating around here. If you will be attending CAB, I can try to make it to this upcoming one and an in-person dicussion might be more productive. That being said, here are few direct responses:

1. In my experience, having worked to implement manual font-detection recently, I have found it to be fairly successful. I agree that it's difficult (or perhaps more accurately, annoying) to implement, but you only have to implement it once. Ironically enough, I believe it is more than successful enough for finger-printing, but leaves something to be desired for legitimate use (which is why I think its unfortunate that we will be putting up obstacles for legitimate use that IMO won't really make a difference for the finger-printing case).

   The main argument here is that using current methods it is trivial to come up with 100 bits of entropy with fonts. Critically, long-tail information (like a custom font that only one user on earth has) is actually not really useful for finger-printing, since its not likely you will be able to store that "bit" (since, by definition, its a font you've never heard of). A known existing set of less than 1000 "common" (but not installed by everyone) fonts is more than sufficient to efficiently track most people you're interested in. My main point here is that if font finger-printing is really a concern, then it is certainly already in use today, and I remain unconvinced that this API will affect it either way.

2. The OTS dangers still seems confusing to me. If we are actually worried about this, I feel like there is the more pressing issue that a "specially crafted" font could "trigger a deeper security problem in the JS-stack" just through usage of @font-face right? The local attack vector, if I understand correctly, involves initially tricking a user to install a bad local font which you then hope gets loaded on some website. It seems like it would be much easier to deploy such an attack by hosting such a font on typekit -- you would potentially attack many more users that way too. But again, perhaps I just don't fully understand this attack vector.

I have a number of thoughts regarding the very helpful security/privacy questionnaire, but it occurs to me that there may be a more pertinent compromise that may explain the differences of where we're coming from. For some context, I was at Apple when the original @font-face proposals were beginning to be agreed upon and implemented, over 10 years ago, and it is highly disappointing to me that to this day these APIs are so fickle to use that the entire spec more or less really serves as a vehicle to make Adobe money through TypeKit since that is the most reasonable way for most developers to not have to deal with the headache of custom fonts. Even worse, 10 years later, there is a backlash against custom fonts (the "native font stack" movement since the swap-in experience is so poor). I would like to not see something similar happen to this API which I believe could actually be critical for the web.

At the end of the day I just find it very unfortunate that to do something as simple as simple as appropriately use Helvetica or Arial depending on which is installed, we have to go through the same super-secure process as an API that gives you access to a completely custom and secret font the user owns. So perhaps a different framing of the issue is that there's kind of two use cases: a "simple" common fonts query that would be sufficient for a vast majority of websites, and an "advanced" completely comprehensive font query. As long as both of these use cases are meant to be served by one API, it's going to lead to frustrating results IMO. But perhaps there is a way to serve the two uses cases differently.

So, for example, if Chrome has a list of "well known public fonts", such as Helvetica, Arial, SF Pro, Helvetica Neue, Roboto, ..., Zapfino, etc., then all of these would be considered safe and calling fonts.enumerate() would return UsersFonts.intersection(WellKnownPublicFonts). This would on day one safely greatly enhance the experience of many web apps -- anyone making an image-editing tool, presentation software, or word processor would provide an almost first-class experience out of the box. Now, if the user eventually wants to use their very private "My Corporate Font" or whatever, then the website could call fonts.enumerate({ all: true }) which would present the permission dialog, and give them access. This would serve the progressive enhancement model: you get pretty good functionality out of the box, its OK that the user has to work a little harder for a unique situation. Essentially MyGraetDrawingApp could have a user configurable setting of whether to use the advanced enumeration or not. Additionally, Chrome's own settings page could allow the user to add additional fonts to their "global safe fonts" list if the user makes their own custom font that they don't care about being private and don't want to have to go through the trouble of enabling on every website.

A few notes:

1. The public font check could use name/checksumming of well known fonts to quickly and accurately determine the set of fonts the API returns by default. That is to say, Chrome knows the checksum of Helvetica on Mac for example, so it won't inadvertantly publicize a font that happens to be named Helvetica.
2. I believe this handles the concerns with DOS as well, as the know font list determines the absolute upper bound of permissionless font enumeration requests.
3. This means the vast majority of sites will probably never even ask for this permission, which is great since user's won't become accostumed to seeing it a bunch (as has happened with the notifications permission).

Again, I'd be happy to discuss in person if you think it would be helpful.