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

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

From: Brandon Sterne <bsterne@mozilla.com>
Date: Wed, 14 Dec 2011 14:44:06 -0800 (PST)
To: Michal Zalewski <lcamtuf@coredump.cx>
Cc: public-web-security@w3.org
Message-ID: <1927760899.38084.1323902646069.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
----- Original Message -----
> From: "Michal Zalewski" <lcamtuf@coredump.cx>
> To: "Brandon Sterne" <bsterne@mozilla.com>
> Cc: public-web-security@w3.org
> Sent: Wednesday, December 14, 2011 2:14:05 PM
> Subject: Re: Proposed directive for CSP.next: "no-user-js"
> > [1] Mozilla pissed off a huge number of people by turning off
> > javascript: URLs in the location bar. See the comment thread in
> > https://bugzilla.mozilla.org/show_bug.cgi?id=656433
> But the problem with that was mostly that you couldn't turn it back,
> right? There was an about:config setting, but the script would still
> execute in a null principal after the change; and the scripts executed
> via Ctrl-Shift-J or Ctrl-Shift-K have elevated privileges and don't
> behave the same way as normal javascript: URLs.
> It seems a bit weird to fix this on a per-site basis. Seems like a
> per-user approach with robust defaults is more sensible.
> /mz

I actually agree with you, for the most part, that this is a somewhat "weird" way to address this problem.  This solution attempts to strike a balance, though, between the security of our users and the usability of the developer tools that are being leveraged in the attacks.  One option we considered at Mozilla was to hide the developer tools until a preference was checked.  The downside to this approach is that these tools then lose discoverability.  I can't speak for other browsers, but this is definitely the position of the Dev Tools team at Mozilla, and I know at least one other browser team has similar concerns (read: total opposition) about restricting the functionality.  The no-user-js proposal is an attempt to appease these constituencies while still providing a secure option for affected sites.

Received on Wednesday, 14 December 2011 22:44:37 UTC

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