Bugzilla

Ah, I was testing using `file://` urls when I saw the behavior difference. When I use a web server and suppress the `Content-Type:` header then the Chrome and Firefox behavior match for the tags I tested from the MIME sniffing spec (e.g. `<html>`). In sum:

1. there's a bug in our sniffing compared to the spec: we over-detect "HTML" (comment 5). Could be left-over historical behavior ("found any HTML tag near the beginning" or whatever we used). Given the content in this case it's not an _unreasonable_ detection -- it is, in fact, intended as HTML content!
2. By adding a single tag from the MIME sniffing spec this testcase will work just fine on other browsers (example: `<html><img src=x onerror=alert(8);>`).

As a consequence of 2. this doesn't need to be a hidden security bug. The dangers of arbitrary user uploaded are well-known and the defenses that websites should take are the same regardless. Websites aren't going to parse the files and say "The MIME sniffing spec says this one isn't really HTML so I'll skip my defenses this time", they'll just apply the defenses regardless. potential defenses include:
* add the `X-Content-Type-Options: nosniff` header
* make the file harmless by making sure it has the expected `Content-Type:`, such as  `text/plain`
* make the file harmless by forcing a download (binary content type, or `Content-Disposition:` header)
* put user uploads on segregated origins, as done on this site for testcase attachments, or `*.github.io`, `*.googleusercontent.com`, etc

Ah, I was testing using `file://` urls when I saw the behavior difference. When I use a web server and suppress the `Content-Type:` header then the Chrome and Firefox behavior match for the tags I tested from the MIME sniffing spec (e.g. `<html>`). In sum:

1. there's a bug in our sniffing compared to the spec: we over-detect "HTML" (comment 5). Could be left-over historical behavior ("found any HTML tag near the beginning" or whatever we used). Given the content in this case it's not an _unreasonable_ detection -- it is, in fact, intended as HTML content! But it does not match the spec or what Chrome and Safari do.
2. By adding a single tag from the MIME sniffing spec this testcase will work just fine on other browsers (example: `<html><img src=x onerror=alert(8);>`).

As a consequence of 2. this doesn't need to be a hidden security bug. The dangers of arbitrary user uploaded are well-known and the defenses that websites should take are the same regardless. Websites aren't going to parse the files and say "The MIME sniffing spec says this one isn't really HTML so I'll skip my defenses this time", they'll just apply the defenses regardless. potential defenses include:
* add the `X-Content-Type-Options: nosniff` header
* make the file harmless by making sure it has the expected `Content-Type:`, such as  `text/plain`
* make the file harmless by forcing a download (binary content type, or `Content-Disposition:` header)
* put user uploads on segregated origins, as done on this site for testcase attachments, or `*.github.io`, `*.googleusercontent.com`, etc