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

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