Re: [SRI] providing good defaults when the expected content type is missing?

It also just smells wrong to me to put this into the SRI spec. Content type
checking is hard, but it's certainly not unique here, and I also don't
particularly see why integrity would require it in particular.
--Joel

On Thu Jan 08 2015 at 2:43:26 AM Mike West <mkwst@google.com> wrote:

> I also don't think this is a good idea; if we wish to enforce content type
> checking, let's just bite the bullet and make the `ct` parameter mandatory
> (and disallow opt-out entirely).
>
> -mike
>
> --
> Mike West <mkwst@google.com>, @mikewest
>
> Google Germany GmbH, Dienerstrasse 12, 80331 München,
> Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
> Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
> Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>
> On Tue, Dec 30, 2014 at 7:16 PM, Brad Hill <hillbrad@gmail.com> wrote:
>
>> I'm not sure I'm onboard with this.  The point of allowing different
>> types, or specifying them explicitly as with the link tag, is to allow
>> extensibility.  We may not be aware of all circumstances in which these
>> extensibility points are being used, and we definitely cannot anticipate
>> where they might be used in the future.   Monkey patching these high-level
>> features out of existence with SRI doesn't seem like a good idea.
>>
>> -Brad
>>
>> On Mon Dec 29 2014 at 5:59:12 PM Francois Marier <francois@mozilla.com>
>> wrote:
>>
>>> The spec currently says:
>>>
>>> "The hash function and digest MUST be provided in order to validate a
>>> resource’s integrity. The MIME type SHOULD be provided, as it mitigates
>>> the risk of certain attack vectors."
>>>
>>> I've added a warning in the Firefox devconsole when the content type is
>>> missing, but I was just thinking that in a lot of (most?) cases, we
>>> could provide a good default for developers and let them override it if
>>> they want to.
>>>
>>> Specifically, I'm thinking that when the integrity attribute is on a:
>>>
>>> - <script> tag: default the expected type to "application/javascript"
>>> - <link rel="stylesheet"> tag: default to "text/css"
>>>
>>> I can see two consequences of this:
>>>
>>> 1. It means that a developer who forgets to include the content type
>>> would still get the benefits of an explicit ct parameter.
>>>
>>> 2. It means that to opt out of content-type matching, we would need to
>>> add a new kind of syntax (maybe something like "ct=*").
>>>
>>> Consequence 1 would be nice since SRI would be stronger by default but
>>> maybe #2 would be a problem in practice?
>>>
>>> Are there any other potential problems I'm not thinking of?
>>>
>>> Francois
>>>
>>>
>