- From: Brian Smith <brian@briansmith.org>
- Date: Thu, 6 Nov 2014 14:36:43 -0800
- 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