W3C home > Mailing lists > Public > public-web-security@w3.org > December 2011

Re: Proposed directive for CSP.next: "no-user-js"

From: David Dahl <ddahl@mozilla.com>
Date: Wed, 14 Dec 2011 14:41:58 -0800 (PST)
To: Brandon Sterne <bsterne@mozilla.com>
Cc: public-web-security@w3.org, Michal Zalewski <lcamtuf@coredump.cx>, Devdatta Akhawe <dev.akhawe@gmail.com>
Message-ID: <412834996.38027.1323902518400.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
As much as this takes away from the "hackability" of web pages, I am sure we can reach a smart compromise where we balance security with functionality, perhaps with a pref that can be overridden (in the case of a Firefox implementation)? 

I do understand the need for something like this. I recently commented on w3c's public-identity that it would be very useful to have an "enhanced security mode" for browsers that can lock down the DOMWindow/Networking/Script for security and privacy applications. See: http://lists.w3.org/Archives/Public/public-identity/2011Dec/0068.html



----- Original Message -----
> From: "Brandon Sterne" <bsterne@mozilla.com>
> To: "Devdatta Akhawe" <dev.akhawe@gmail.com>
> Cc: public-web-security@w3.org, "Michal Zalewski" <lcamtuf@coredump.cx>
> Sent: Wednesday, December 14, 2011 4:28:11 PM
> Subject: Re: Proposed directive for CSP.next: "no-user-js"
> > Is this in scope for CSP? CSP is per-resouce, and this seems to be a
> > per-site thing. Maybe another header (similar to how STS turns on a
> > site-wide switch).
> >
> > =dev
> This is an instinct that we need to fight. We can't afford to keep
> creating a new security header every time we want to address a new
> threat model. We want CSP to be an extensible framework for security,
> so it's at least fair to suggest that it could grow to address this
> particular threat.
> I also don't see why this is inherently a site-wide option, at least
> why it's any more of a site-wide option than, say, the "don't allow
> XSS" portion of your policy.
> -Brandon
Received on Wednesday, 14 December 2011 22:42:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:28 UTC