Re: [whatwg/fetch] More CORB-protected MIME types (#721)

> If destination is style, and mime type is not text/css, return blocked.

"destination" might not always be available (not sure if the "network service" in Chromium will be aware of it - I think it tries to shy away from any content::ResourceType knowledge) or trustworthy (the renderer can just lie).  Therefore, I'd rather avoid using the "destination" for a decision here.

> [...] keep the image sniffing algorithms [...]

Currently CORB only sniffs for HTML/XML/JSON to confirm that blocking is okay (sniffing for blocked resources).  I think this is a fine approach going forward as well (we can discuss whether similar confirmation sniffing is needed for some other types like PDF or ZIP - I think the answer is "no - not needed" because mislabeling of an image or script as PDF should be hopefully rare).

I don't understand why we'd switch this approach to sniffing for allowed resources:
- This might be problematic if "destination" is not available.
- It is difficult to properly cover a hypothetical `image/future-format` in this kind of sniffing

> fonts are CORS-bound 

Good to know.  This possibly makes things slightly easier.

> However, all of the above are pretty notorious for being served with the wrong MIME type.

Yes :-(

The proposed restriction of safelist-based blocking to `nosniff` responses might help, but I do note that it didn't help in the `application/octetstream` case encountered earlier by Firefox.  There are probably other similar cases like this :-/

-- 
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/721#issuecomment-388096162

Received on Thursday, 10 May 2018 15:51:52 UTC