[selectors] Solve :visited once and for all

[tabatkins]

In w3c/css-houdini-drafts#791 @deian explains a new channel for high-bandwidth leaking of :visited state by observing repaints with the Houdini Paint API. There doesn't appear to be a reasonable way to shut this down under the current regime of partial-censoring of :visited - the current fix for Chrome is to just disallow the paint() function from being used at all on any <a> element or its descendants.

We really need to finally define a sensible model of :visible-state visibility, based on what information would have already leaked to the page via standard, unpluggable channels; then we can finally drop all the silliness around :visited and just treat it as a plain, ordinary pseudo-class that allows all properties to be used in the standard fashion.

1. At minimum, same-origin visitedness is always visible to the page, as the server can track its own cross-links, assuming standard tracking mechanisms exists (cookies, sufficiently high-entropy user identification, etc). So all same-origin links should report :visited.

2. Cross-origin inbound links are always visible to the page if the Referer header was sent in the request.

3. Cross-origin outbound links are always visible to the page if the user visited that link from this origin, as there are a multitude of ways to track outbound links (JS auditing, <a ping>, link shorteners, etc).

4. Any others?

---

If a link matches one of the conditions above, and is visited, it's allowed to match :visited; otherwise it never matches :visited. So, what's the cost/benefit of each of the conditions above?

1 is easy to apply and non-controversial. It also probably represents at least half of the benefit of :visited styling for the user - they can tell when they've already visited a given page on a site.

But I don't think it's a whole lot more than half - there is a lot of benefit to knowing what links you've visited from a given page, regardless of origin. (Think of clicking thru each of a list of outbound links, such as in a forum post, or in Google search.) So I think 3 is most of the rest of the benefit, but probably the most controversial in terms of theoretical privacy (even if it's nil in practical privacy for the vast majority of users). I think it's reasonable for browsers to nix this condition if the user is blocking script, as that's the primary tracking mechanism.

I think 2 is of relatively minor benefit, but it lies inbetween 1 and 3 in terms of privacy leaking. Some UAs do offer the ability to block Referer, and of course they would then block this visitedness channel, but otherwise it's common and not a big deal. It's just that most cross-origin pages won't have a link back to the page you visited from; the exception is things like weird cross-site web puzzles, or old-school webrings.

Are there any other conditions that would allow us to safely expose :visited state unreservedly?

[GreLI]

What about visitedness in local files (having file:///url)? I've saw some concerns about someone can save malicious web-page/SVG-image and leak data with embedded scripts.

[tabatkins]

Browsers already block Referer when the starting page is a local file, so that blocks 2, and browsers already have some magic for assigning local files an origin (I think each file is just in a unique origin?) so that blocks 1. 3 is still available, but only if you open the local file and then click links in it, which yeah, is already observable by a hostile local file.

[astearns]

Just so I'm clear on the trade off here - I'm reading this as breaking backwards compatibility for some subset of :visited matching in order to allow custom paint on links and more expressive styling for :visited. Is that correct?

[emilio]

https://bugzilla.mozilla.org/show_bug.cgi?id=1398414, https://bugs.webkit.org/show_bug.cgi?id=37443 and https://bugs.chromium.org/p/chromium/issues/detail?id=713521 are already-existing issues filed on browsers with very similar ideas, fwiw.

[tabatkins]

@astearns Yes on the cost, but the benefit is more than just more expressive styling; the current :visited hacks aren't totally secure, and still offer some ways to exfiltrate visitedness. This would be finally closing those holes, limited though they may be. It also simplifies styling code, at the cost of more complex visitedness tracking.

[deian]

To add to #3012 (comment) we found several new timing attacks, so the Paint API is not really at fault here. I think your suggestion @tabatkins is great! (With something like this, we'd even be able to expose a getHistory JavaScript API without impacting privacy [not that we should].)

[AmeliaBR]

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

The paper 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 w3c/fxtf-drafts#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

[AmeliaBR]

Going back to Tab's post:

I agree that those 3 cases cover the main situations where :visited is both useful and of little privacy concern.

The first case should also be of minor implementation cost: you only need to filter out the visited list by the current page origin when matching the pseudoclass.

The other cases would require more implementation overhead, because the history list would need to track referrers for every page. So that might be best left up to browser discretion.

An alternative option would be for the browser to safelist certain origins (e.g., your favourite search engine) on which :visited could apply to cross-origin links without privacy masking. But again, that would need to be at browser discretion, and hopefully with plenty of transparency to the user about the impact of marking an origin as "safe" in this context.

All that said: For authors, having a fully functional, no-silliness, :visited pseudoclass for same-origin links would help do things like showing "unread" badges on article lists without hacking around with white text on white backgrounds.

[yoavweiss]

Excited to see this issue finally being tackled! This has been a recurring hurdle when talking about exposing paint timing information, as well as other timing APIs.

Regarding 2, it seems like it should somehow be bound to cookie state and request credentials mode (reliable tracking using Referer also requires having some user ID, as their IP could be shared with other users). Like @tabatkins said, I'm not sure supporting it will add many use-cases, and it will certainly add complexity.

@astearns - some of the use-cases for :visited will indeed be lost. I think the main one is the "cool links of the week" case, where users will no longer be able to know which of those links they already visited when seeing them fly by on their favorite social network.
While regrettable, I think it's a small price to pay to fix this issue once and for all.

[MatsPalmgren]

3. [...] as there are a multitude of ways to track outbound links (JS auditing, , link shorteners, etc).

While it is true that tracking users on the server side is technically possible as you suggest, please note that it is now illegal to do so on EU citizens without their explicit consent (thanks to GDPR). So I don't think your argument that "the server can track this anyway" holds because most sites don't have that consent.

[htstudios]

The sensible thing to do is deprecated :visited for the general profile and hide it under a user flag that can be enabled for stand-alone web-based software (such as web tech based mobile apps), or manually by the user (globally or per domain).

-> By default no :visited
-> If you enable it, full :visited support without any magic that attempts to hack-fix the issue

[yoavweiss]

@MatsPalmgren knowing which links the user visited from a site's origin can also be tracked in JS on the client-side, without tracking the user specifically. The :visited changes @tabatkins proposed seem similar to that. (but I'm not a lawyer, so not sure where would either fall as far as GDPR goes).