- From: Zack Weinberg <zackw@panix.com>
- Date: Fri, 3 Apr 2015 13:22:17 -0400
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: "www-style@w3.org" <www-style@w3.org>
On Fri, Apr 3, 2015 at 11:57 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Fri, Apr 3, 2015 at 5:53 PM, Zack Weinberg <zackw@panix.com> wrote: >> All the font formats that browsers actually support are unambiguously >> identifiable by their in-band metadata ("magic numbers" and the like) >> and it is therefore my opinion that, like images, font formats SHOULD >> be identified using that metadata, *not* any out-of-band declaration >> (in other words, browsers SHOULD continue to ignore the MIME type for >> fonts). > > Sure, and I have done this when we introduced @font-face (and failed > to register font/ :-/), but that's not really the question. E.g. we > don't check MIME types for <script> either, but with > X-Content-Type-Options: nosniff we do. So the question is what is the > list of MIME types we want to whitelist for font use when that header > is specified. It is my considered opinion that nosniff mode should have *no effect* on the interpretation of any resource loaded via a @font-face rule: such resources should *always* be identified using their in-band metadata, and *only* their in-band metadata, and only those resources which are identified as fonts in a supported format should be processed. Conversely, *whether or not* nosniff mode is applied, and *regardless* of what the server says the Content-Type is, a resource whose in-band metadata unambiguously identifies it as a font should *never* be processed in a context that requires something else (e.g. image, style sheet, document). This is also my opinion for any other data format which can be unambiguously identified from its in-band metadata, which (it is my possibly-mistaken understanding) turns out to be everything *but* HTML, Javascript, and CSS. zw
Received on Friday, 3 April 2015 17:22:39 UTC