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

What about triggering a DOM event by default, and
(possibly) allowing opt-outs?

Am I missing a threat?

--dev

On 22 November 2012 11:43, Mike West <mkwst@google.com> wrote:
> You can add more than one endpoint to the report-uri directive, so yes, this
> suggestion would support that use case as (for instance) `report-uri 'self'
> /report-collection-url.cgi`.
>
> --
> Mike West <mkwst@google.com>, Developer Advocate
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>
>
> On Thu, Nov 22, 2012 at 7:11 PM, Eduardo' Vela <evn@google.com> wrote:
>>
>> Could it be possible to get both? A report-uri and the DOM errors?
>>
>> That way we can deploy one policy on a large set of apps and if we need to
>> debug one in particular we just ask that one to monitor the script.
>>
>> On Nov 22, 2012 4:36 AM, "Mike West" <mkwst@google.com> wrote:
>>>
>>> I've talked to a few developers about deploying CSP, and the request for
>>> some form of violation DOM event has popped up several times. It's something
>>> I'd like to implement if we can find a good way of making it work.
>>>
>>> What do you think about making such a feature an opt-in portion of the
>>> policy by adding a `'self'` keyword to the `report-uri` directive? If the
>>> keyword is set, violation events would be fired at the
>>> `document.securityPolicy` object; if not, no violation events would fire for
>>> that policy.
>>>
>>> That mechanism might actually also give vendors a mechanism of directing
>>> violations of extensions' policies to the extension rather than the page by
>>> interpreting 'self' in some reasonable way.
>>>
>>> --
>>> Mike West <mkwst@google.com>, Developer Advocate
>>> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
>>> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>>>
>>>
>>> On Sat, Oct 27, 2012 at 12:53 AM, 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
>>>>
>>>
>

Received on Tuesday, 27 November 2012 21:35:01 UTC