Allow more options for when to download the common web fonts. #10
Conversation
And describe the possible history leak in more detail.
README.md
Outdated
| * caching on first use, which in a few cases might expose that a user visited | ||
| one of a sensitive set of sites to an attacker, | ||
| * not allowing this set of fonts at all, which either leads to slow and | ||
| expensive page loads or a need to change site or user behavior, and |
There was a problem hiding this comment.
Not allowing them how? This is essentially the status quo in Safari, right? I think this is describing things as worse than they are.
There was a problem hiding this comment.
The Safari behavior appears to make the CSSWG unhappy, because certain minority linguistic communities aren't served well by it. I can definitely make it clearer that the only group to worry about is those who aren't served well by system fonts, for example as described in w3c/csswg-drafts#4497 (comment).
README.md
Outdated
| is large enough to make the font "common", and the attacker has logged-in users, | ||
| they might be able to probe each user exactly once in order to distinguish users | ||
| who've visited the sensitive set without polluting their sample with users who | ||
| have previously been attacked. |
There was a problem hiding this comment.
I think this is missing the angle that users can also segment or be segmented in ways that are not necessarily clear to a global observer. E.g., they might only be able to visit one site with such a font in their region of the world or some such.
There was a problem hiding this comment.
I rewrote this to try to be more precise. Is 57a5c11 better?
Co-Authored-By: Anne van Kesteren <[email protected]>
|
While I very much appreciate the effort to represent these concerns accurately, I'm not sure this proposal is really the right place for it. The Web Shared Libraries conversation seeks a mechanism to share arbitrary popular resources across sites. Such a mechanism would naturally support web fonts as a resource type, and we probably don't want to build an orthogonal font-specific mechanism (i.e. I agree with the current text in this PR that the solutions should align). So rather than partially addressing the privacy and performance trade-offs in this proposal, I might suggest that we fold those into the Web Shared Libraries discussion, and focus this proposal on font restriction, with a discussion of why it might be problematic to ship without something like WSL. |
|
And in particular - I would love to see this proposal attempt to analyze and quantify the harm we expect from system font restriction, which could better-motivate WSL. |
|
@bholley I'm hesitant to have this defer all the discussion to a Google Doc instead of an actual proposal in a repository. I've asked in that doc to have it move to a repository, and then I'm happy to point there instead of duplicating discussion here. I suspect that fonts are an easier problem to solve than libraries in general, so we might be able to move on fonts first, but I could be wrong. The Privacy Sandbox team within Chrome will be collecting data on the harm from system font restriction, and when they're done, they should be able to put it here. |
And describe the possible history leak in more detail.
@bholley @annevk, can you let me know if this is an accurate description of the problem in #7, and whether the extra flexibility here makes you like the proposal better? Do you think it's important that all browsers align on when fonts are cached? I think that particular difference can't introduce pressure to align with the most popular browser, although I could be wrong.