W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2012

Re: Trigger a DOM event/error when a CSP violation happens.

From: Dan Veditz <dveditz@mozilla.com>
Date: Fri, 26 Oct 2012 15:53:20 -0700
Message-ID: <508B1460.1090601@mozilla.com>
To: Adam Barth <w3c@adambarth.com>
CC: Eduardo' Vela <evn@google.com>, public-webappsec@w3.org
> On Wed, Oct 24, 2012 at 11:18 PM, Eduardo' Vela <evn@google.com> wrote:
>> We have found a lot of challenges triaging reports to the point we are
>> considering disabling CSP since it's useless as we can't effectively debug
>> it, this is very important for large scale applications.

Are you trying to debug a broken application, or figure out where 
injected content is coming from?

I'm sympathetic to your need and it may be worth experimenting with, but 
I would not want user-applied CSP to report to the page. At least not 
detectably as a "CSP" error; if we want to fire normal existing onerror= 
handlers for images that don't load that may be fine.

I'm not sure what to do about extension-supplied CSP. Again, I would not 
want it reporting to the page, but it would be handy if there were a way 
to report it to the extension. I'm sure extensions can root around in 
the web console messages and find it, but a more direct API might be good.

Such APIs would be out of scope for this WG so I'd just like to state 
the privacy principal that user-agent supplied policies do not report 
violations to the originating server or page content. I'm not against 
firing events at the page for violations of the page's own policy.

-Dan Veditz
Received on Friday, 26 October 2012 22:53:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 26 October 2012 22:53:49 GMT