1) It will mostly cure XSS. I have been telling people for months that mitigation is not a solution.

2) It forces JavaScript off the damn page. This is something HTML should have fixed years ago. In page JavaScript has been a horrible culprit in namespace collisions that can occur from third-party ads that crash your own native code.

I have noticed four problems that may cause this proposition to fail:

1) Advertising business interference
Unfortunately this solution is horribly flawed from a business perspective. Business on the web is extremely reliant upon advertisements whose metrics are tracked by execution of client-side script supplied by those ads. It seems this solution will also eliminate this revenue stream. I expect this to meet some serious criticism.

2) Not a standard
I see no indication that this venture is representative of any sort of standard. Security is a universal problem that demands a universal solution. A Firefox favoring proprietary solution will certainly benefit Firefox as a product and reposition it in the grab for market share, but it will not fix the problem. I strongly recommend that this action be written as an internet draft and submitted to the IETF as an extension of URI/HTTP.

3) No client-side control mechanism
The root of the problem is that malicious software written by a stranger is executing at will at the user-agent. This solution provides a mechanism for the site to inform the browser of the approved script repository where that script only is then executed in accordance with the status quo. That mechanism will likely occur as an HTTP header to provide transparency to the user. Unfortunately this still does not provide any control to the user of which code should or should not execute. If malicious code is living in the blessed repository then nothing is gained and attacks continue without the user’s knowledge. A user must be able to make decisions about what is executing on their own software on their own machine or the problem is merely diminished instead of solved.

4) Relay points
There is no indication that scripts cannot point to a reference outside the blessed sandbox, which opens possibilities of attack from a couple different angles. If script uses the XMLHttpRequest object to point to a location outside the blessed sandbox for additional instructions then nothing is gained by this mechanism. The mere opening of such a connection could be a point of exploitation if the code or data being retrieved is entirely benign. Again, there must be notifications provided to the user before code executes locally without prior discriminatory user consent.

You guys have my full support on this endeavor as drastic steps must be taken to solve this problem. There are more XSS vulnerabilities reported than all other computer security vulnerabilities combined and doubled. If this problem is not solved by any means necessary commerce on the web will fail, and the web itself will fail.

Before becoming aware of this work I posted a solution of migrating script execution to email using a secure mechanism. The proposal is completely sound from both a technology and security perspective, but is so far extremely unpopular for eliminating execution of events. Since this alternate solution is based off a more complex transmission mechanism it may or may not be helpful. I hope that may be able to provide any additional guidance that may not have been previously considered.
http://www.ietf.org/id/draft-cheney-safe-04.txt

Yes. Greasemonkey would be sure to fail too, unless its given privs to inject javascript and content into web pages as it does now.

As part of these changes, pleeeeease preserve the ability to allow add-ons to continue to function correctly by allowing event/content/javascript injection as they can now do. For example, the DejaClick addon has a feature to annotate web recording. It does this by injecting user-recorded popup notes (html or SVG) into web pages as it replaying (via HTML and CSS content injection). Also, there will soon be a feature in DejaClick to allow users to inject snippets of Javascript code before or after a replayed event for special circumstances.

Add-ons developers already went thru a similar fiasco by having to add “contentaccessible=yes” to the content directives of all their chrome.manifest files, so I certainly hope we don’t make the same mistakes with this stuff.

In particular, what does page-level sandboxing solve that sub-page level sandboxing cannot?

But in any case, I’m glad you’re at least open to the possibility. Thanks for listening.

The charter of that WG was never modified to include CSP. We’re keen on working with a standards setting body, and are still in the process of determining where the proposal works best.

I have mixed feelings. I’d really like to get people excited about CSP, site authors and other browser vendors in particular. A user-agent override doesn’t belong in the specification that is a contract between the site and the browser, and while supporting overrides is a valid implementation decision talking about it is a bit of a distraction and may even undercut the message to site authors. It would also, of course, require more work on our part so I’m not unbiased

On reflection, though, overrides might be a required workaround to avoid breaking add-ons that create mash-ups or add elements to content. Argh.

It will be possible for users to disable Content Security Policy protection if for some reason they need to do so. The user can weigh the need to run their own script injection against the risk of unauthorized script injection.

@William: We still have a few blurry edges around plugins. Some plugins can make their own network connections that are completely out of the browsers control. If there’s enough interest in CSP some of the plugin vendors may be interested in extending the NPAPI so they can participate in that model. Some people want to be able to control which types of plugin can load, not just from which sites. So far we’ve resisted that complication but it’s useful feedback. NPN_GetURL() and the like we’re currently planning to vet against the plugin-src whitelist.

Currently NPN_Evaluate is allowed because you allowed the plugin to load, but we can argue that the plugin’s origin should be vetted against the script-src whitelist before being allowed to call NPN_Evaluate(). It’s an open question.