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

@astearns This isn't just about the Paint API.

The [paper](https://cseweb.ucsd.edu/~dstefan/pubs/smith:2018:browser.pdf) describes other attacks, which can be summarized as: create a CSS rendering context which is very slow to re-render (SVG with lots of overlapping polygons, extensive nested 3D transforms), then trigger a relatively neutral style property change if `:visited` applies (either by changing the`:visited` style, or by changing the link `href`), while using a `requestAnimationFrame()` loop to test whether a repaint was triggered.

And yes, there are browser mitigations that could address that, too. Maybe force a repaint every time a link's visited status needs to be re-evaluated, regardless of computed style changes. Or maybe never re-evaluate existing links visited status or `:visited` styles except in response to navigation actions.

But that still doesn't address other problems with `:visited`, like using color or blend modes (see https://github.com/w3c/fxtf-drafts/issues/18) to make `:visited` links more or less visible to the user & therefore trick users into revealing which ones are visited through their interactions.

The Paint API vulnerability was unique because of its high-throughput. But the fundamental problem is that rendering of a web page relies on information that the web page authors should not be able to access.  And adding mitigations for each rendering pathway seems like trying to patch leaks with duct tape when you could just turn off the water at the faucet.

And all that duct tape just makes a sticky tangle of so many language features. E.g., Other open bugs for `:visited` include #2263 #2844 #2884 #2037

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

Received on Sunday, 12 August 2018 22:35:16 UTC