On Tue, Nov 4, 2014 at 7:10 PM, Brian Smith <brian@briansmith.org> wrote: > In particular, I could see having a SRI header like this: > > SRI: https://example.com/a.js ni://<as-currently-specified>, > https://example.com/b.js ni://<as-currently-specified> > > Imagine a use case like a Twitter timeline, where the same image is > repeated multiple times. This syntax would enable you to specify the hash > only once, instead of every time. Also, this syntax would also work for CSS > and other places where URLs are used outside the HTML element/attribute > syntax. > > Alternatively, I don't really see too much of a problem with making SRI > part of CSP. It actually seems like a more natural part of CSP than some > parts of CSP do (e.g. "referrer"). > Considering the case of the Twitter timeline again: The current attribute-based syntax has the advantage of working automatically for dynamically-generated content. For example, in the Twitter case, presumably Twitter would pull down some JSON containing the tweets, and that JSON would contain the src and integrity attributes for the <img> elements that it would insert into the page. That would work just fine with the current attribute-based syntax. With a header-based approach, a new DOM API would be needed to populate a table mapping URIs to expected integrity values. OTOH, such an API may be needed anyway for any solution for solving the poor interaction between CSP and SRI. Cheers, Brian
Received on Wednesday, 5 November 2014 03:58:00 UTC