On 10/22/09 6:09 PM, Adam Barth wrote: > I agree, but if you think sites should be explicit, doesn't that mean > they should explicitly opt-in to changing the normal (i.e., non-CSP) > behavior?
They have already opted in by adding the CSP header. Once they've opted-in to our web-as-we-wish-it-were they have to opt-out of the restrictions that are too onerous for their site. > It seems very reasonable to mitigate history stealing and ClickJacking > without using CSP to mitigate XSS. It seems reasonable to mitigate both of those without using CSP at all. History stealing is going to come from attacker.com where they aren't going to add headers anyway. The proposed CSP frame-ancestors could just as easily go into an extended X-Frame-Options (and be a better fit). And it's really only a partial clickjacking defense anyway so maybe that aspect should go into whatever defense feature prevents the rest of clickjacking. NoScript's "ClearClick" seems to do a pretty good job (after a rough start) and gets to the heart of the issue without requiring site changes. > I think we're all agreed on this point. Our current disagreements appear to > be: > > 1) Whether frame-src should be in the resources module or in the same > module as frame-ancestor. > 2) Whether sites should have to opt-in or opt-out to disabling inline > script and/or eval-like APIs. I don't think this is the right venue for deciding the latter, the audience here just doesn't have enough of the right people. We feel extraordinarily strongly that sites should have to explicitly say they want to run inline-script, like signing a waiver that you're going against medical advice. The only thing that is likely to deter us is releasing a test implementation and then crashing and burning while trying to implement a reasonable test site like AMO or MDC or the experiences of other web developers doing the same. The eval stuff I feel a lot less strongly about the default, but feel there's value in consistency of having site authors loosen restrictions rather than have some tighten and some loosen. -Dan _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
