W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] Video with MIME type application/octet-stream

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 31 Aug 2010 22:08:49 -0700
Message-ID: <AANLkTi=HuZSEqeoToGzy4vjKYBRhJDpKtDjALoG96A2x@mail.gmail.com>
On Tue, Aug 31, 2010 at 9:27 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On 8/31/10, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
>> If you can't come up with any actual problems with what IE is doing,
>> then why is anything else even being considered? ?There's a very
>> clear-cut problem with relying on MIME types: MIME types are often
>> wrong and hard for authors to configure, and this is not going to
>> change anytime soon.
>
> Aggressive sniffing can and has resulted in some pretty nasty security bugs.
>
> E.g. an attacker crafts an input that a website identifies as video
> and permits the upload but which a browser sniffs out to be a java jar
> which can then access the source URL with the permissions of the user.

Indeed.  However, that would be an issue with the browser sniffing for
jars, not an issue with the browser sniffing for video.

> The sniffing rules, in some contexts and some browsers can also end up
> causing surprising failures... e.g. I've seen older versions of some
> sniffing heavy browsers automatically switch into UCS-2LE encoding at
> wrong and surprising times. Perhaps this is irrelevant in a video
> specific discussion of sniffing? but it is a hazard with sniffing in
> general. ?Moreover, it'll never be consistent from implementation to
> implementation, which seems to me to be pretty antithetical to
> standardization in general.

Why will sniffing never be consistent?  We need only step up as a
community and spec things that implementors are willing to implement.
Inoperability suffers when we insist on specing things that
implementors refuse to implement.

Adam
Received on Tuesday, 31 August 2010 22:08:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:00 UTC