Re: [csswg-drafts] [selectors] Solve :visited once and for all

A few thoughts here:

1. While this discussion seems to have been triggered by the paper cited in w3c/css-houdini-drafts#791, it's not clear to me that that paper brings anything particularly new to the discussion about which approach is best for addressing visited link privacy issues introduced through CSS.  I think there are two parts to this:  **(a)** I think the high-bandwidth attack that it introduces is fixable as I described in https://github.com/w3c/css-houdini-drafts/issues/791#issuecomment-412604601, and based on discussions we'd had about how we would implement the CSS Paint API in Gecko, I think we would likely have had that fix by default for performance reasons and it wouldn't have needed to be something special for visitedness.  (It was also my understanding about how invalidation was intended to interact with the Paint API.)  **(b)** Second, I think the other CSS-related attacks are variants of attacks that focus on performance of repainting in ways that cause differences resulting from link state to delay `requestAnimationFrame` cycles, allowing one bit of information per possibly-delayed cycle.  I think these attacks are probably fixable using the combination of [what roc suggested in 2013 in Mozilla bug 557579](https://bugzilla.mozilla.org/show_bug.cgi?id=557579#c14) and what @AmeliaBR suggested above in https://github.com/w3c/csswg-drafts/issues/3012#issuecomment-412376605, i.e., by taking an approach that does both repainting whenever it might have happened as a result of an `href` change or equivalent.  I think we haven't focused on fixing these because they didn't appear (I think) to be substantially higher bandwidth than things like cache timing attacks or other attacks at the network level of the platform, but if we had a coherent strategy for mitigating visited leaks throughout the platform (not just in CSS) then I think it would be worth spending more effort on.

2. Despite (1), I think it's worth considering the approach Tab suggests above in https://github.com/w3c/csswg-drafts/issues/3012#issue-349828569 (and which I've previously heard suggested by other Googlers) because of the complexity the existing approach to dealing with preventing link history leaks through CSS imposes on adding features to the Web.  That complexity has multiple problems:  both the time we spend on it, and what happens when we get things wrong.  But if we go down this path, I think we should consider the tradeoff against the value that visited links provide to users (and the possibility we could *improve* that value, for example by counting links that differ only with certain query parameters as equivalent).

3. I'd note that there is still no proposed remedy within the existing model to the one-bit-per-user-interaction leaks involved in building a game or other user interface where elements are hidden or not depending on whether links were visited.  (This was the final bullet point in Jesse Ruderman's [original report of CSS visited history sniffing in 2000](https://bugzilla.mozilla.org/show_bug.cgi?id=57351).)  That is clearly an advantage of switching to the alternative model suggested here, though it's not clear to me how important it is given the low rate of information leakage.  (For example, if we worry about that... should we also worry about blocking exfiltration of data about the user's mouse movements, finger touches, or scrolling rate while reading text, from which one could infer a good bit about the user's reaction to the text?  In other words, where is the limit of what the browser is responsible for blocking?)

4. I think if we're going to spend efforts making the CSS side more secure here, we should also get commitments from maintainers of other parts of the platform to fix issues in other areas, i.e., commit to making this a solid part of the platform's security model.

5. I'm not going to speculate on legal issues.

-- 
GitHub Notification of comment by dbaron
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3012#issuecomment-412698036 using your GitHub account

Received on Monday, 13 August 2018 23:18:44 UTC