[whatwg] [mimesniff] The X-Content-Type-Options header

[Adam Barth]

On Fri, Nov 16, 2012 at 2:43 PM, Gordon P. Hemsley <gphemsley at gmail.com> wrote:
> On Fri, Nov 16, 2012 at 5:28 PM, Anne van Kesteren <annevk at annevk.nl> wrote:
>> On Fri, Nov 16, 2012 at 2:19 PM, Gordon P. Hemsley <gphemsley at gmail.com> wrote:
>>> In addition, I would like to, if I could, also allow the header to be
>>> specified without the 'X-' prefix (so as 'Content-Type-Options'), for
>>> that reason (and because of best current practice).
>>>
>>> Does anyone have any questions, comments, or objections about this issue?
>>
>> Not sure why you would drop the prefix if it's not supported. Doesn't
>> seem like best practice to me to needlessly break compatibility. ;-)
>>
>> Also, are we sure they are not sniffing still? E.g. how is mislabeled
>> image content treated? I vaguely recall a image/png resource that's
>> actually a GIF, still working even in the presence of this header.
>> <script> probably still executes too, although I guess MIME sniff
>> currently has no say in how <script> loading does not care about the
>> MIME type.
>
> Well, it was my (unverified) understanding that the header wasn't
> widely implemented yet.
>
> Gecko has a bug on file (which notes that it's for parity with Chrome):
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=471020
>
> So my intent was actually to specify exactly what browsers should do,
> rather than what they currently do. (This spec is a mixture of both in
> that department, modeled off of what Chrome does.)
>
> Regarding your anecdote, it's possible that you were using a browser
> that didn't support the header (thus performing the sniffing even when
> told not to). If you weren't, though, I think that's Bad™. If browsers
> ignore the header, then there's no point in having it.
>
> Unless, of course, we only want to limit it to scriptable media types.
> That wasn't what I was originally considering, but it doesn't
> necessarily conflict with the IE team's original intent. (Their
> example is content marked as 'text/plain' being sniffed as
> 'text/html'.)
>
> So, what do the implementors think?

I would prefer if the spec described what implementations actually do
rather than your opinion about what they should do.  To answer your
specific questions:

1) Don't bother dropping the "X-".  Everyone who implements this
feature uses the X- and dropping it is just going to cause unnecessary
interoperability problems.

2) When deciding what to specify about values other than nosniff,
please reverse engineer the existing implementations rather than just
making up how you wish they behave.

3) With regards to <img>, Chromium does not consider the
X-Content-Type-Options header when determining what to do, but IE
does.  It's not clear to me what the spec should say given that there
is lack of interop here and I don't think you have buy-in from either
implementor to change the current behavior.

4) With regards to <script>, Chromium does not consider the
X-Content-Type-Options header when determining what to do.  I'm not
sure whether IE does.  You'll need to do some reverse engineering to
figure it out.

5) With regards to <iframe> and the main frame, both IE and Chromium
do consider the X-Content-Type-Options header.

6) One of the more interesting cases to study is what happens when the
server both supplies an X-Content-Type-Options header and also fails
to supply a Content-Type header.  My recollection is that both IE and
Chromium treat the response as text/plain regardless of its contents.
However, please don't take my recollection as fact.  Instead, you
should reverse engineer the implementations in question.

Adam