Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CORB: empty response VS erroring out #727

Closed
anforowicz opened this issue May 21, 2018 · 6 comments
Closed

CORB: empty response VS erroring out #727

anforowicz opened this issue May 21, 2018 · 6 comments

Comments

@anforowicz
Copy link
Contributor

In a few cases people wondered why CORB blocking does't result in a network error:

  • @annevk in a CORB PR: "Are you planning on changing the implementation to use a network error for the cases enumerated in the PR?"
  • @mikewest in a From-Origin comment: "CORB does not fail the load, but instead delivers a filtered response. I don't have a strong feeling about which behavior we ought to end up with, but I do think that diverging would be confusing. I'd prefer for us to align the response that's returned from both From-Origin and CORB if we're going to fold their processing model together. My intuition is that that's simpler to do by treating both as network errors"
  • @youennf in a From-Origin comment: "A network error seems consistent with other fetch error handling."

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...).

@jakearchibald
Copy link
Collaborator

jakearchibald commented May 22, 2018

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?

@mikewest
Copy link
Member

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.

@jakearchibald
Copy link
Collaborator

jakearchibald commented May 22, 2018

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 (#560). Are you ok with that too?

@mikewest
Copy link
Member

Are you ok with that too?

Yup.

@jakearchibald
Copy link
Collaborator

Sold.

@annevk
Copy link
Member

annevk commented May 17, 2022

My plan is to close this issue when #1441 lands. Its replacement which is worked on in #1442 requires a network error.

@annevk annevk closed this as completed in 78f9bdd May 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants