I wonder if we could avoid having to explicitly blacklist content types that should not be exposed cross-origin (and potentially missing a sensitive content type today, or forgetting to add coverage for a new one in the future).  Maybe instead we could whitelist content types that are explicitly allowed to be exposed cross-origin?  For example https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy lists some examples of resources which may be embedded cross-origin - such resources would map to the following content types:

- application/javascript: Javascript
- text/css:               CSS via <link rel="stylesheet" href="...">
- audio/* and video/*:    Media files via <video> and <audio>
- font/*:                 Fonts via @font-face
- image/*:                Images via <img>

This seems relatively simple so far, but I guess the real trouble begins with "plug-ins via <object>, <embed>, <applet>" - I guess content types allowed here are very open-ended.  OTOH, maybe Chrome supports only a limited number of content types (e.g. nothing other than "application/x-shockwave-flash").  For example - in M45 Chrome dropped support for NPAPI (effectively dropping support for Silverlight, Java, Facebook Video and other similar NPAPI based plugins) [source: https://www.java.com/chrome].

Also, backcompatibility considerations might force us to whitelist extra content types.  For example, we might need to allow application/font-* and application/vnd.ms-fontobject (font content types that I've found in http://www.alienfactory.co.uk/articles/mime-types-for-web-fonts-in-bedsheet).

This also ignores people sending back application/jsonp (which in theory is not a valid content type, but there's some mention of it around the web, so it's conceivable there are sites that use it [this is based on xtof@'s comment @ https://crrev.com/c/850551/3/content/common/cross_site_document_classifier.cc@102]).

Some more thoughts on whitelisting...

If we only allow cross-origin responses from a content type whitelist, then I guess it naturally follows that responses without a mime type would be blocked (see also issue 795971).

And in addition to the types whitelisted in #c1, I think we might have to whitelist multipart/* (to avoid waiting for more bytes and parsing multipart responses in the browser process).

Charlie also mentioned text tracks / subtitles - AFAIK these are text/vtt.

mkwst@ - WDYT about expanding XSDB to cover all unknown mime types (see #c1 and #c2 above as well as an attempt to describe this in an "explainer" in https://crrev.com/c/891580)?  Is this something we would consider shipping in M66?  Or is it more of a long-term aspirational goal?

There is some support for moving into a safelist/whitelist approach in https://github.com/whatwg/fetch/issues/721

I think that we should continue thinking about the exact contents of the potential safelist/whitelist, but postpone actual implementation until the basic/blacklist-based CORB ships to stable without any surprises.  Let's evaluate where we are after M67 has been out for a few weeks.

The NextAction date has arrived: 2018-07-30