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.

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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:07 UTC