SRI: specify verification of CSS-loaded subresources

[fmarier]

Tab and Anne are poking at adding fetch() to some spec somewhere which would allow CSS files to specify various arguments to the fetch algorithm while requesting resources. Detail on the proposal is at https://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0129.html. Once that is specified, we can proceed defining an integrity argument that would allow integrity checks in CSS.

[annevk]

Not sure if this is still on @tabatkins radar.

[tabatkins]

It had slipped my mind! I'll put this on my more urgent todo list.

[tabatkins]

Oh wait, I actually did do part of this. We don't need a fetch() function, because I was able to switch url() from being a special form to being a normal function, so you can now use arguments inside of it. So url("http://example.com" integrity DEADBEEF) is clear to happen now.

[fmarier]

Is this something we want in v1? /cc @metromoxie @mozfreddyb @devd

At this stage, my personal opinion (in the interest of getting to CR) would be to postpone anything that requires implementation changes unless:

1. it's a security problem,
2. it has forward compatibility implications, or
3. it will prevent wide adoption

I can see an argument for #1, but I would argue that what we have is still better than the status quo and that it allows authors to protect the first level of sub-resources quite well. We can tackle "recursive integrity" in v2.

[devd]

I don't think this is needed in v1

[tabatkins]

Leaving url() as it is for now obviously isn't any worse than the status quo (because it is the status quo), so yeah, delaying to v2 is fine.

[joelweinberger]

Agreed with delaying to v2.

[v6ak]

Just an idea: enforcement of SRI on transitive dependencies, maybe as a part of CSP.

In theory, someone might statically verify that the stylesheet does not fetch any external resources without SRI, so the enforcement is not needed.

In practice, it is additional hassle that many developers will not do, so such enforcement could be useful.