[whatwg/fetch] Response filter escalation (#535)

Step 12 of [Main fetch](https://fetch.spec.whatwg.org/#main-fetch) sets the request's response tainting and (generally) produces a response. The subsequent step 14 reads:

> 14. If response is not a network error and response is not a filtered response, then run these substeps: [...]

This was implemented as a solution for https://github.com/whatwg/fetch/issues/23, but @wanderview and I are wondering if it is correct.

In particular, we're thinking of cases where `response` is a [basic filtered response](https://fetch.spec.whatwg.org/#concept-filtered-response-basic), but `request`'s response tainting is "cors". This could occur, for example, when a Service Worker uses `respondWith`, providing a synthetic response (or a same-origin response). In cases like these, step 14's sub-steps will not be executed. This will produce a response to a cross-origin request that has "basic" filtering.

I'm not sure if this is a problem, given that the applied filter matches the response that is ultimately created, but the mismatch between the initial request's tainting and that final response's filtering (in particular: the relaxing of the filtering rules) seems like a potential information leak. If so, would it make sense to introduce a concept of filter "strength" such that step 14 could be applied in these "filter escalation" scenarios?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/535