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

We are trying to find out what is the meaning of the millions of CSP
reports we have.

We have manually looked into some of them and they are usually
addons/extensions (when they aren't, they are things like copy-pasting an
image into a wysiwyg field).

The current report, is completely useless for us as it triggers too often,
so we need to find a way to make it more useful. Triggering DOM events /
errors is a nice way because the websites that care can add instrumentation
if they want to and doesn't have any evident privacy implications.

What we might consider doing is to run a "fake CSP" script, which traverses
all DOM nodes every couple miliseconds and recreates the job of CSP so that
we can know what is triggering it.

However, this is probably something CSP should have by itself.. and
wouldn't add the latency problems reimplementing CSP in JS adds.


On Fri, Oct 26, 2012 at 3:53 PM, Dan Veditz <dveditz@mozilla.com> wrote:

> 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
>