lgtm. I'll keep this open for a week in case anyone has any concerns.

Isn't this going to trigger a CSP exception? That's going to report errors.

Confirmed. The catch doesn't prevent the violation from being triggered and reported. It seems unacceptable to have every page you load trigger an violation and a false positive http report.

My test environment doesn't trigger an error and I'm not sure what you mean by false positive http report.
The test makes no http request. How are you testing?

Make sure report-uri is set.

Interesting. I didn't know about report-uri. Not everyone will use reporting, but the potential http request is concerning.
Testing in FF nightly didn't seem send a POST though. Have you tried it?

Checking into this with Adam Barth...

Adam is going to bring this up with the right folks at the spec level. Until then, there's not much
we can do to get around the potential report-uri. He seems to think in most cases, users won't
opt-in to reporting...and I tend to agree. Users are going to opt-in to this test, only when there's
the likelihood they'll be in a CSP environment. At that point, being able to run your app is more
important than a potential http request :)

Being able to silence violation reporting with a try/catch sounds like a security issue itself.

He seems to think in most cases, users won't opt-in to reporting

Reporting is pretty critical to deploying CSP in production.

Developers need to be able to check if those will be able to work properly then adjust accordingly.

So you're trying to do what exactly?

Checking for CSP by triggering CSP violation is just what people will be thinking they are trying to avoid by using this. This detect is just broken.

Nit: This doesn't actually check to see whether the site has a content security policy set; it's testing the availability of eval. I'd suggest renaming the test.

I agree with Josh, by the way. I expect larger sites (Twitter, for example) to migrate to CSP by first enabling reporting, and then enabling CSP once they get the initial flood of reports under control. Checking whether eval functions correctly doesn't seem like a good substitute for asking the browser whether CSP is enabled.

I'll poke Adam about this today. I'd like to see an actual API to make the current policy visible in JavaScript. It's a use-case I don't think they've thought about (I hadn't thought about it until today), but one I think we should encourage them to support.

@josh AFAICT, try/catch doesn't silence reporting.

I think we're all in agreement that a feature detect needs to be added to the spec. This patch would only be temporary.

now this discussion is happening at the standards level:

https://mikewest.org/2012/05/content-security-policy-feature-detection
http://www.w3.org/Security/wiki/Content_Security_Policy#Proposals_for_Version_1.1

going to pull it and add a note that we'll deprecate this test for the real API if/when it comes.

Sorry. reread the thread and agree that we can't merge this commit due to it triggering CSP violations. I reverted bringing this test in in f30f011

CSP testing is in limbo until we have firstclass support for it. I'm keep this ticket and #564 closed until a real mechanism is available that doesnt trigger reporting.

It seems there is a mechanism for this already (see section 3.4.2 of the spec)
At least in Chrome 30 it is implemented and working. Not sure about other browsers, though.