- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 03 Sep 2010 23:48:14 -0400
On 9/3/10 3:48 PM, Aryeh Gregor wrote: >> Why are you assuming that? > > Because blocking an entire MIME type seems like it would be massive > overkill . . . but if that's a real use-case, well, okay. It still > can't be *too* hard to check the first few bytes of the contents. > They must do it anyway if they implement this for images, right? Yes. But note that for some video formats checking the first few bytes is not sufficient. In fact, some video container formats can have arbitrary length prefixes before the actual video data starts. Of course if sniffers are just restricted to the first few bytes that might be ok. > Okay, you're being too theoretical for me. Let's say we have > fingerprints for all the major video types, of the form "check if the > first X bytes match this very simple pattern". Let's say the spec > says that whenever processing the response to an HTTP request, > browsers must act as though they executed the sniffing algorithm and, > if it sniffs as a video type, they must treat it the same as if the > Content-Type matched the sniffed type. OK, so context-independent? Note that not a single browser implements this today. > Also suppose that the fingerprints include byte sequences that cannot occur in normal text > encodings Is this a reasonable supposition? What are these byte sequences for the container formats at hand? (Say WebM's restricted Matroska container, whatever container format is supported for H.264 by IE and Chrome, and Ogg; we'll ignore the generic Matroska weirdness for now.) > and that they're long enough that random false positives > are extremely unlikely. What's the problem with this specific > proposal? Might be a good idea to ask the IE team, the Chrome team, and the Safari team why they're not sniffing in toplevel browsing contexts... I believe there's been at least one answer from a Chrome developer on that already, though. >> Er... Where did I propose this? I proposed speccing that there MUST NOT be >> any sniffing, with browsers that sniff therefore being nonconformant. I >> didn't propose allowing ad-hoc sniffing. > > Right. But the spec never allowed sniffing, and two browsers do it > anyway. Sure, but it's early days in implementation. Note, also, that I believe it's 3 browsers, not 2. > Ian has spoken to those browsers' implementers, and the > browsers have not changed, despite knowing that they aren't following > the spec. Some of these changes take time (e.g. having to rejigger quicktime to allow you to no sniff while using it). So is it that they have not changed, or that they have no plans to change, ever? > Do you have any particular reason to believe that they'll > change? Such changes have happened in the past (e.g. for stylesheets, and for toplevel browsing contexts). Why is this case different? >> Only if "consistent" includes "consistent across all contexts".... (which no >> one is proposing to either specify or implement). > > Could you comment specifically on the behavior I outlined above? The behavior you outlined above is "consistent" in this sense, yes. -Boris
Received on Friday, 3 September 2010 20:48:14 UTC