- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Fri, 17 Jul 2009 18:34:08 -0400
On Fri, Jul 17, 2009 at 6:21 PM, Brandon Sterne<bsterne at mozilla.com> wrote: > No, that feature is not part of the current design, though nothing is > set in stone. ?Couldn't you achieve the same effect (verifying your > policy isn't blocking wanted things) by simply testing the pages in a > CSP-supporting browser and watching for violations (in the client or on > the report-uri server)? Only if I visit every single page in the whole complicated app that users might visit. With all their settings. Which might or might not be practical. On Wikipedia, for instance, users are allowed to specify custom scripts to load, kind of like server-side Greasemonkey. That will certainly break if we prohibit external script loads, but we can't really assess the extent of the problem in the current spec without actually enabling the feature and (possibly) breaking everything. (How we'd handle this at all, I'm not sure. We might need to allow registered users to opt out, or use a more lenient policy. But that's a separate issue.) More generally, it would be a pain to do a full audit of the code and all extensions to find all instances of inline script, and all the other assorted possible violations that might be occurring. We could do it with a test browser, yes, but we'd only catch the most common cases that way. The code running on Wikipedia is somewhere over 700,000 LOC, it wouldn't be trivial at all to manually find all the places where violations could possibly be generated. I think the ability to have violations reported without actually preventing them would be very useful to ease deployment in existing apps.
Received on Friday, 17 July 2009 15:34:08 UTC