In a few cases people wondered why CORB blocking does't result in a network error:
Based on what @csreis wrote it seems that there are no specific backcompatibility concerns here (and to change Chromium implementation we just need to do the grunt work of making sure that CORB console messages and prefetching/caching behavior are preserved in presence of CORB-induced network errors). Let me reactivate https://crbug.com/827633 (although I am not sure what would be the timeline for working on this bug...).
Here's the problem:
fetch('https://example.com/whatever', { mode: 'no-cors' }).catch(() => {
// This smells like a CORB-blocked resource.
});
The question is, is this an acceptable data leak?
The question is, this is an acceptable data leak?
It seems like the data you can infer from the error is fairly narrow: "This resource had an interesting MIME type." Are there cases where that's revealing more than we'd like?
Also: if we expand the conditions under which we return a network error (e.g. by making that From-Origin's behavior as well), then we further reduce the granularity of the assumptions an attacker can make.
It's mostly interesting if that content changes when the user is logged in or not. But I agree that if there are a lot of cases that return network-error, then the assumption isn't as useful.
Whatever we do here, I'd like to do the same for step 8 of https://whatpr.org/fetch/560.html#main-fetch (https://github.com/whatwg/fetch/pull/560). Are you ok with that too?
Are you ok with that too?
Yup.
Sold.
Most helpful comment
Yup.