Decide whether or not to keep content-type in SRI version 1

[fmarier]

Both @devd and @hillbrad have expressed some concerns in #156 with encouraging developers to specify the content type as part of the integrity attribute. @mikewest on the other hand wants to keep it so that we can rely on it in future versions of the spec where caching is included.

[devd]

@mikewest I am a bit confused: since we already require "Access-Control-Allow-Origin *" when it comes to caching, I don't understand why the content-type is necessary to achieve caching; can you explain a bit more ?

[mikewest]

As @hillbrad noted in a previous comment, a GIFAR-style attack is enhanced if we start identifying content based on a hash rather than a URL, as we won't have any server-side headers to rely on for type-checking. Tying an explicit type to the hash is a good way to mitigate that risk.

Folks who craft malicious resources will, of course, send them out with proper CORS headers. They'd love everyone to have access. In short, CORS protects the server, not the client.

[mikewest]

(This doesn't mean that the type needs to be tied directly to the digest in the syntax (it could be a separate attribute? or specified in some way that applies to all the digests for a resource?), but it needs to be explicitly available somehow from the context. Relying on the server to send proper headers doesn't seem like enough.)

[mozfreddyb]

This doesn't mean that the type needs to be tied directly to the digest in the syntax

Do we have to think about applications handing out different media (e.g., lower resolution) depending on the user agent?

[mikewest]

I think we punted that discussion by limiting SRI to <link> and <script>. As I vaguely recall, @yoavweiss was going to help us come up with syntax for responsive images, and we needed to come up with something clever for larger media files.

[yoavweiss]

Yeah, we vaguely discussed introducing an integrity() function to the srcset syntax.
OTOH, I'm not sure that we don't have to define some form of "rolling" SRI for images as well, otherwise defining SRI on them would mean any from of progressive decoding is not permitted, and would have performance implications.

[mikewest]

And there you have it. Merkle trees for everyone in SRI2.

[hillbrad]

Thinking further, I'd like to keep content-type. My example use case is
that I accept a script file from someone to run as an ad. I perform some
behavioral or ML analysis on it as JavaScript and approve it, then add an
SRI tag to prevent it being modified. But the malicious server changes the
content-type and now it is treated as SuperFutureScript and does something
different.

On Wed Feb 18 2015 at 4:20:09 AM Mike West notifications@github.com wrote:

And there you have it. Merkle trees for everyone in SRI2.

—
Reply to this email directly or view it on GitHub
#176 (comment).

[devd]

I am very dubious about the possibility of two files that match on SHA-2 (or greater) but one is the good script and the other is the bad script in a different content type. that said, I am fine with keeping it around as optional; I just don't think it should be mandatory.

[briansmith]

What is the harm in requiring the content type, besides it is a little ugly? The content type is less ugly than the base64 part. The integrity attribute needs to be machine-generated anyway, so it doesn't seem to be saving any effort.

Could we say that if the content-type equals the value of the "type" and charset attributes of the script then it can be omitted?

I'm more concerned about the opposite problem, that there may be more response header fields than Content-Type need to be considered mandatory to include, such as "Service-Worker-Allowed" or whatever Service Worker people came up with. Basically, any response header that affects how the response is to be interpreted should be covered by SRI. I think if this is discussed more, a solution for defaulting Content-Type will fall out of that discussion.

I also think it is fine--probably even better--to use the "type" attribute of the script and/or link elements. Also don't forget the "charset" attribute.

[fmarier]

Does anybody think it should be mandatory or do we agree that if we keep it in V1, it should be optional?

I've implemented it in Firefox as optional but recommended (with a devtools console warning if it's missing).

[briansmith]

What does "optional" mean? If optional means charset=UTF-8 and Content-Type=text/javascript are the defaults, or if optional means that the charset and type attributes of the script tag are used (including default values), then fine. If optional means "ignore the Content-Type header" then I think that's not a good idea.

[fmarier]

Optional (in my implementation) means:

• omitting the content-type doesn't make the integrity metadata invalid
• if the content-type is not specified, the browser's default Accept request header is sent
• if the content-type is not specified, we accept all values of Content-Type in the response headers

[hillbrad]

Dev, it's not two files that collide on their SHA-256, it's that there are
lots of webby formats that are very forgivingly-parsed and so the exact
same file might be valid as multiple content-types with different semantics
in each (e.g. GIFAR).

On Wed Feb 18 2015 at 5:32:30 PM Francois Marier notifications@github.com
wrote:

Optional (in my implementation) means:

• omitting the content-type doesn't make the integrity metadata invalid
• if the content-type is not specified, the browser's default Accept
  request header is sent
• if the content-type is not specified, we accept all values of
  Content-Type in the response headers

—
Reply to this email directly or view it on GitHub
#176 (comment).

[devd]

The call ended up with consensus on making the content-type optional, if I am not wrong.

[fmarier]

The minutes aren't up yet, but the irc log (discussion starting at 20:37:35) does confirm this IMO.

Given that this is how it's currently implemented (at least in Firefox) and specified, I think we can close this issue.