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: Thu, 6 Nov 2014 14:36:43 -0800
Message-ID: <CAFewVt72e6_TAfxJ8U281atfKDPHjZ+XEx1_yr18D1WC_TR+AA@mail.gmail.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
Cc: Joel Weinberger <jww@chromium.org>, 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>
Devdatta Akhawe <dev.akhawe@gmail.com> wrote:
>>
>> I agree that that would be good, and that's exactly what would have happened
>> if Frederik hadn't pointed out this issue before SRI were standardized. But,
>> since we know about the issue now, I think it is reasonable to consider
>> changes to the syntax that avoid the problem now, so that we don't end up
>> with a bad syntax later.
>
> I guess I see the header (in CSP or separate SRI header) mechanism as
> something that can be easily added on later. Is there a particular
> part of the current syntax that makes you think it won't be possible
> to evolve the direction you envision?

If SRI were already standardized with the current syntax, then I think
that we could retrofit a sub-optimal solution on after the fact. But,
since SRI isn't standardized yet, we should not limit ourselves to
designs based on the attribute syntax, but instead try to find one
consistent syntax that composes well with CSP.

In particular, I would consider having more than one syntax (CSP, SRI
header, or attribute syntax) to be something to avoid, because having
more than one way of doing SRI adds complexity and contributes to
"paradox of choice" problems. For example, a framework that tries to
help with SRI should not have to manage two or more syntaxes.

Do you have a pointer to an explanation about why it is important for
SRI to not be part of CSP? I think understanding why SRI isn't part of
CSP would be useful.

Cheers,
Brian
Received on Thursday, 6 November 2014 22:37:09 UTC

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