+rsleevi@, mmenke@ who have a better understanding of the underlying network stack socket pool allocation and potential mitigations than I do.

I'm not sure why the discussion of 'window' here - we don't consider that to be a security boundary from the network stack?

I also don't think we've considered request timing as a valid scope. Mike, has that changed? I ask, because fundamentally, networking timing will leak (for example, if OS buffers are full), so I don't think we can draw a security boundary against what we cannot defend.

Mike: See also Issue 828315

A man-in-the-middle could also get this information, at least for non-H2 / non-QUIC requests, no?  And H2/QUIC also potentially mitigate this attack, to some extent, I believe.

I think I was able to reproduce this but it is possible that the reproduce was just due to chance.

I don't think anyone is arguing this can't be reproduced, just that it doesn't seem to fit in our threat model.

mmenke@ I don't disagree, I was just doing the standard sheriffing things =) 
Sorry for the confusion

Fair points. I agree that the same attacks are already possible but needing to be mitm makes attacks somewhat impractical.

Also the impact is not very clear since it's application specific. For example many search handlers (gmail, yahoo) only work on word boundaries so you could only test for the existence of words in the victim's inbox. However, I also found a local file disclosure bug based on XS-Search so this vulnerability class can have a high impact in some rare cases.

I'm on the edge myself if it's worthwhile to address this in the Browser. As you said, we won't be able to address all of such leaks. However, I lean to the side that we should try to fix this specific instance since it's very easy to exploit and works quite reliably compared to filling kernel buffers for example.
Search handlers over private data that can be triggered via query parameters are a common pattern after all and there's currently no good way for web developers to protect their application against leaks like this. In the long term I think proposals like the Cross-Origin-Isolate Header (https://groups.google.com/a/chromium.org/forum/#!topic/isolation-policy/zueJF9ad20g) will be the better way to address this. But for the short term, it could be a reasonable mitigation to prevent a single window from exhausting the whole connection pool.

I'm not sure that it's really a reasonable mitigation, in that there is not a mapping of requests to connections in browsers. Consider HTTP/2 as an example, in which multiple requests can be dispatched over a single connection, or in the case of HTTP/1.1 connection reuse.

I don't think there's anything the browser can - or should - do here, as the boundary is not at the window level. This is especially true when one considers service workers as part of the equation (which may have many windows or no windows at all).

Attempting to segment connection pools even at the origin layer seems like it would be a significant interoperability issue, in that we are aware of many servers that have limits per-host.

As to difficulty, exercising the buffers is not substantially more difficult, and as noted, there are other ways in which you can exercise the Fetch spec, TLS, or the HTTP protocol for XS-Search like attacks. A mitigation seems like it needs to be done at the application layer.

This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

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

Erm...Why is sheriffbot lying about issues being regressions?

Re #13: I think because the label SecurityImpactHead instead of SecurityImpactStable + FoundIn68.

If this is outside threat model and no work needs to be done, please WontFix.

Mike: If you're good with that model, I'll WontFix. It's not part of the threat model we //net owners have been considering in-scope, but if OWP-Sec feels different, we're open to exploring. I suppose we do need to formalize a bit more on that, and I know you've been working with Artur on that.

rsleevi: 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

aaj, sroettger, asymmetric, and I are meeting Monday, June 11 (and hopefully mkwst@), to review the the Severity further and discuss either WontFixing or exploring possible mitigations.

So aaj@ was out, but we met to discuss this and Issue 828315. The takeaway was that between these two, effectively eliminating this primitive for attack was likely going to require giving the destination origin more control about when and how it's scripted and accessed.

I believe C-O-R-P ( https://github.com/whatwg/fetch/issues/687 ) was the relevant feature set, but ensuring that openers cannot script or redirect seemed to be a viable mitigation strategy.

Just checking if there's any objections, otherwise, will WontFix both this and Issue 828315. Going to meet with mkwst@ later today to see if he screams in horror :)

This bug has been closed for more than 14 weeks. Removing security view restrictions.

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