W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2014

Re: [SRI] To trust or not to trust a CDN

From: Brian Smith <brian@briansmith.org>
Date: Tue, 4 Nov 2014 19:57:32 -0800
Message-ID: <CAFewVt5QaRLbFnyXxHVBBsnjjd__A9ob1UxXpnuFzq8d0mSBaQ@mail.gmail.com>
To: Joel Weinberger <jww@chromium.org>
Cc: Hatter Jiang OWS <hatter@openwebsecurity.org>, Ben Toews <btoews@github.com>, Mike West <mkwst@google.com>, Frederik Braun <fbraun@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
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.

Received on Wednesday, 5 November 2014 03:58:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:42 UTC