- From: Lukasz Anforowicz <notifications@github.com>
- Date: Thu, 10 May 2018 15:51:24 +0000 (UTC)
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/721/388096162@github.com>
> 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