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

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
>>
>>