Delay opaque responses until response body is in

[annevk]

We already delay responses when integrity is specified. We should do the same for opaque responses as otherwise there's a timing attack possible to more accurately figure out the size of the response due to fetch() resolving when the response headers are in and other APIs resolving when the response body is in.

This will impact service workers' ability to stream opaque images and more importantly opaque media quickly to the document. I don't really see a way around that though.

I realized this was a problem in w3c/resource-timing#64.

Other attacks due to opaque responses: whatwg/storage#31.

[jakearchibald]

Doesn't a CORS/XHR request fail after headers?

[annevk]

http://papers.mathyvanhoef.com/blackhat2016.pdf argues that the defense I describe is infeasible (section 4.1.1), but I'm not sure that is correct.

The way the attack works is the combination of fetch() resolving early (responseStart is gotten through performance.now()), and resource timing revealing responseEnd.

@jakearchibald yes, but requiring two distinct fetches makes this significantly harder I think and the server might react differently too as the request looks different.

[jakearchibald]

So you need a service worker for this attack? That's the only way you'd get header and body timing for the same request (via fetch).

Seems like we should be removing body load detection time rather than header time. Delaying fetch in the proposed way will massively reduce performance of service worker sites.

[annevk]

So you need a service worker for this attack?

No, fetch() coupled with the resource timing API is sufficient.

Seems like we should be removing body load detection time rather than header time.

No, since then you could still do it pretty accurately with two requests I think. One from <object> or some such and one from fetch(). And the requests would look identical (unlike the "cors" scenario).

[jakearchibald]

Hm, ok, so it does require two requests. I'd rather we fixed this by removing/randomising no-cors load events. Resource timing definitely shouldn't be providing accurate data for this.

Images are probably a lost cause, but they should be failing early if the resource doesn't have a supported image header.

[igrigorik]

Hm, ok, so it does require two requests. I'd rather we fixed this by removing/randomising no-cors load events. Resource timing definitely shouldn't be providing accurate data for this.

See w3c/resource-timing#64 (comment)

[annevk]

Per the resource timing thread the way this is going to be solved is not through mitigations that cripple existing APIs. Since even if we cripple them, the problem remains. We will likely introduce some new features that make it easier to deal with this. Discussion of which is going in the resource timing thread.