Thanks for mentioning the article!  I'm not sure how we treat cases where an attacker can leak a victim site's data by timing how much work the site is doing.  palmer@ or tsepez@, do you have a sense for what we do with traditional timing attacks like this?

In this case, it's arguable that any site doing jQuery(location.hash) (i.e., doing a CSS selector query with attacker-controlled input) is perhaps asking for trouble, but I don't know how common that practice is.  I don't see a way around having that query take different amounts of time based on whether the element is present.

It's also nice that the article points out that Site Isolation hides the direct version of the attack, though I can see how timing a navigation away from the victim page would still leak the data.  For a hit, we'll spend a little while waiting for the old process to respond before navigating, and for a miss, the old process will respond quickly.  Maybe skipping beforeunload if the handler isn't present (issue 365039) might hide the difference from the attacker's perspective for cross-site navigations, but I imagine a same-site navigation would still leak the data (since you should be able to observe when it finishes, and the navigation stays in the process doing the work).

For my own two cents, I'd say the victim site shouldn't be giving the attacker so much control over code execution by doing a CSS selector with location.hash.

palmer@: Can you weigh in on how we should approach bugs like this?  The fact that some web operations take longer than others based on the content of the page seems unavoidable (e.g., a CSS selector query taking longer for a hit than a miss).  I'm not sure how the browser could mitigate such leaks.

Is this a WontFix since the site should be validating the untrusted input (location.hash) against a list of known values before feeding it to the CSS selector?

The NextAction date has arrived: 2018-12-17

Well, I'm not sure we have or can have a general approach to this class of bugs. They seem to be all *juuust* different enough. And this particular one is a bit special, relying as it does on the site executing attacker-provided CSS selectors.

I see a few approaches for dealing with this one, at varying degrees of plausibility, for browser developers, site developers, and JS framework developers:

* Sites should not execute arbitrary selectors. Very plausible, but a massive communication effort is necessary. (Equivalent to educating all developers about reflected XSS.) And even if everyone got the message, they'd all be writing selector validators of varying degrees of effectiveness.

* jQuery should perhaps deprecate super-fancy custom selectors. No idea if they're up for that, or if developers typically take up jQuery upgrades. This idea could range from entirely plausible to entirely not plausible. I have no idea. :)

* Sites should set X-Frame-Options, and also browsers should do something to break or let sites break cross-site or cross-origin `window.opener`. Like those headers we've been talking about...

* Coarsening clocks won't work and is not plausible anyway. Similarly, adding noise to clocks won't work and adding enough noise would break their legitimate purpose. (Nobody wants a super-coarse or super-noisy `performance.now`. And `requestAnimationFrame` isn't going anywhere.)

* Running the various demos in several tabs at once locked up my expensive workstation for a moment. (?!) Perhaps general-purpose or targeted interventions for JS performance policing would work here; e.g. "CSS selectors either succeed in N ms or we abort them." Finding some N that allows legitimate functionality and which does not still enable the attacker to distinguish element-found from element-not-found is probably not plausible. Finding some N that stops egregious DoS is probably do-able. +slightlyoff who knows about interventions.

* Does the web really, truly need the ^= selector type (and any other types that let you effectively select an element by content)? I can imagine that people are using it for legitimate things, but... Again, no idea if this is plausible. Do we have use counters for this? +tabatkins, our CSS friend.

Finally, this attack is public, and we normally don't view-restrict publicly-known things. Marking allpublic.

creis - does C7 satisfy us?  Can we close this as wontfix ?

Heh, comment 7 raised a lot of questions, and didn't make a clear case for WontFix.  :)  But here's my takeaway:

* Recommending changes to developers for this specific issue is probably hard (e.g., explaining how even seemingly safe operations on untrusted input may leak data through timing channels). 

* That said, the in-progress work on a Cross-Origin-Window-Policy header to sever window references in https://github.com/whatwg/html/issues/3740 may be sufficient to help here as well.  If sites have data worth protecting against Spectre attacks in other browsers, they may want to use such a header anyway, and it would probably disrupt attacks like this as well since the attacker couldn't continue to navigate the window or frame after it reaches the victim site.

* I suspect that deprecating features of jQuery or CSS aren't likely to happen, but others can feel free to chime in if that's worth considering.

* If there's a browser DoS here, it probably falls within  issue 672370 .  (Apparently that has been archived, though.)

So, I think relying on the Cross-Origin-Window-Policy header and any developer outreach for that is probably sufficient to take care of this attack as well.  Thus, I'll mark this as WontFix.  (palmer@, feel free to chime in if you disagree, or want to keep this open blocked on the header work.)

I don't think we need to keep this open, blocked on the header work. That's adequately tracked in other bugs.

I'd like to hear from tabatkins about use counters, though. My instinct is to suspect that ^= is one of those features added just because we can. If people are not really using it, then deprecating and removing it would be a nice simplification of the platform.