RE: video/@src vs application/octet-stream

While I don't necessary want to start the "why sniffing is evil" discussion here, I have to challenge the basic premise below.

>media formats are, in general, unambiguously sniffable, 
>and do not contain active content that would pose a security risk. 
>
Sorry, but this is NOT the case!

There are a number of known attacks (not just POC's) that relying on format sniffing and specially constructed "hybrid" files that claim to be one (safe) thing but are really something else that is considered unsafe.  


So regardless of where you fall on sniffing - it has been/is used as an attack vector.  As such, we should think long and hard about not only allowing it BUT making it mandatory.  Seems like a MUCH GREATER opportunity for attack than "plugins" ;).

Leonard

-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Maciej Stachowiak
Sent: Monday, July 19, 2010 2:53 PM
To: julian.reschke@gmx.de
Cc: Boris Zbarsky; public-html@w3.org
Subject: Re: video/@src vs application/octet-stream


On Jul 19, 2010, at 11:20 AM, Julian Reschke wrote:

> On 19.07.2010 20:09, Maciej Stachowiak wrote:
>> ...
>> For Safari/WebKit, we wanted to make it possible for the<video>  element to play content that was previously embedded via the QuickTime plugin or other plugins we support. Unfortunately, a fair proportion of such content is being served with the wrong MIME type, most typically application/octet-stream but sometimes also text/plain. We thought it might create too high a barrier, if authors had to reconfigure their Web servers before they could switch from the QuickTime plugin to<video>.
>> ...
> 
> Thanks for the feedback.
> 
> So, does this make Safari non-compliant? It appears so, as draft-abarth-mime-sniff doesn't mention sniffing for video, and the spec text about video/@src doesn't seem to make an exception.

>From testing, it looks like our implementation will successfully play an MPEG-4 video embedded in the <video> element, when served as the following types:

application/octet-stream
text/plain
image/jpeg
application/ogg

I believe our behavior is to completely ignore the MIME type and only rely on sniffing for <video>, much as the spec suggests and as UAs actually do for <img>. It is possible our sniffing could be restricted to a narrower set of types, but I'd have to ask the <video> experts on the team about that and we may need to run an experiment.


Also, note that this sniffing only applies in the context of the <video> element. If you navigate directly to a video served with one of the above types as the main URL, then in no case will we attempt to play the video (the behaviors are download; display garbled text; broken image icon; download, respectively).

I think it is reasonable for <video> to ignore MIME type just as <img> does; media formats are, in general, unambiguously sniffable, and do not contain active content that would pose a security risk. It is also plausible to have narrower sniffing rules, or none at all. We haven't done testing to determine the minimum level of sniffing that works well.

Note: if a file in media format we support is incorrectly served with the MIME type of another, incompatible format that we also support, then it would be challenging to get that file to fail instead of playing correctly, since we rely on an underlying media framework to do the playback and format detection.

Regards,
Maciej

Received on Monday, 19 July 2010 20:35:24 UTC