This looks similar to issue 712246 and issue 713521.

Setting Security_Severity-Low since this looks more like a Privacy issue, than a security issue.

msramek@ -- assigning to you for now to make a call on whether this is materially different than the linked issues and for further triage.

This is entirely different from 712246, which tricks the user into revealing visited status by clicking on images that are hidden or not depending on their browsing history. The attack presented here requires no user interaction and can be performed in bulk.

And as with 835589, I would have thought this would be considered medium severity at least.

https://chromium.googlesource.com/chromium/src/+/master/docs/security/severity-guidelines.md

"Example Bugs: ... A bug that allows an attacker to reliably read or infer browsing history (381808)."

+palmer@ FYI, since you've been looking into timing attacks
+tnagel@ FYI
+rbyers@, +mkwst@, jochen@: This bug serves as more evidence to what is discussed in issue 713521.

We could theoretically fix this by *always* processing the :visited computations, and only at the end, before assigning a color to the element, checking if it was actually visited. But I'd be interested to again gauge the support in the OWP community to make :visited origin-scoped.

Any opinions on the above? Running both :visited and :not(:visited) branches to achieve constant time computation?

I assume that the computation is done once per CSS rule, not once per each occurrence of <a>. So a regular site with a single link style would only incur a small performance loss.

The only websites which this would hurt would be the ones using a different style for each link, which are likely the ones trying to sniff history. And even there, the worst case performance would only worsen by a factor of 2.

A variant of this attack is possible with a complex SVG image inside the link instead of placing CSS transforms on the link itself. The signal is again observable down to 100ms measurement periods, and is even stronger than the CSS variant over higher durations. A demo file is attached (most of the 2 MB size is the embedded SVG image).

Deleted: attack.html 2.1 MB

attack.html 2.1 MB View Download

Note that the Severity Guidelines call out history leaking as Medium:

https://chromium.googlesource.com/chromium/src/+/master/docs/security/severity-guidelines.md#Medium-severity

msramek: Uh oh! This issue still open and hasn't been updated in the last 28 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

+tdresser@ PTAL at comments #3, #5

"I assume that the computation is done once per CSS rule, not once per each occurrence of <a>. So a regular site with a single link style would only incur a small performance loss."

I don't think this is necessarily true. We need to do all the work associated with painting the link. That includes rendering complex filters etc, which need to be done on a per-link basis, right? Those cases should be quite rare though. 

If performance is a big issue, maybe we could even have a heuristic to identify if there's expensive logic associated with displaying a visited link, and draw things normally if there isn't, and draw things twice if there is? 

I know Ojan has claimed in the past that anywhere there's a leak with :visited, there's probably also a leak in other contexts. It feels to me like rAF should be usable to determine if a user is logged into a site embedded in a cross origin iframe (although potentially not in the context of OOPIF).

msramek: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Any reason that Android and Fuchsia would not be affected?

Nope, they should be.

Now that Spectre is in our threat-model, I think we should be planning for a solution for this which completely closes this hole (not just makes it harder). Whether it's directed visitedness (my personal preference), or elimination of :visisted entirely (eg. replacing the use cases with some sort of browser-level UI) I believe it will be possible to make a compelling argument for fundamentally changing the web here within the framework of https://bit.ly/blink-compat.

Of course, it may make sense to do some shorter-term mitigations - but the cost/benefit tradeoff there will depend on the longer term plan.

FWIW, I agree that spectre changes our threat model and negates what I said above about this problem.

My preference is that we at least do an initial exploration browser-level UI and treat directed visitedness as a fallback if that doesn't pan out. In particular, I think browser level UI would open up the door for a whole class of link annotations aside from visited that I'd really like to see us experiment with (e.g. annotating links to pages that use a lot of data).

Issue 904239 has been merged into this issue.

We've considered annotating links with the expected page size a long time ago, but only recently developed the infrastructure (go/cacao) to provide annotation details to Chrome. If adding annotations is high priority for anyone, let me know.

 Issue 891712  has been merged into this issue.

(reward-ineligible as this issue has been published https://www.usenix.org/system/files/conference/woot18/woot18-paper-smith.pdf)