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

> @anforowicz if you want to switch to a safelist-based approach, you wouldn't want to confirm something is HTML (which is not allowed anyway), but rather you'd want to confirm something is an image (which is allowed).

I guess there might have been a misunderstanding of what each of us means by a "safelist-based approach" - possibly I didn't look carefully enough at @jakearchibald's [earlier comment](https://github.com/whatwg/fetch/issues/721#issuecomment-388091805) with a more detailed proposal of what is meant by "safelist-based approach".

I think there are 2 options of introducing a "safelist-based approach":

- Option #1: *add* a safelist-based decision to the current CORB algorithm:
    - HTML/XML/JSON and `text/plain`: current behavior of html/json/xml confirmation sniffing (unless nosniff or 206)
    - image/audio/javascript/other-safelisted-type: allow
    - any other type: always block without any sniffing

- Option #2: *replace* the current CORB algorithm with a safelist-based decision:
    - image/audio/javascript/other-safelisted-type: allow
    - any other type: sniff to check if the response is an image/audio/javascript/other-safelisted-type and only block if it is not

I think @annevk and @jakearchibald are proposing Option #2.  I think that Option #1 might be easier to implement (with a well-defined, small set of formats to sniff for).

> I was thinking of splitting up this issue earlier. Create a new issue for how to go about switching to a safelist. And keep this issue for extending the current approach. That might help.

I am not opposed, although I do note that we've accumulated quite a bit of safelist discussion here already...

-- 
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-390263197