- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Tue, 27 Nov 2012 13:50:28 -0800
- To: Mike West <mkwst@google.com>
- Cc: "Eduardo' Vela" <evn@google.com>, Daniel Veditz <dveditz@mozilla.com>, public-webappsec@w3.org, Adam Barth <w3c@adambarth.com>
> Regarding opt-in vs opt-out, I proposed opt-in because I had a good idea > about the syntax that seemed clear and understandable. I'd agree that the > general case doesn't seem to be problematic, though, so I'd be interested in > alternatives. Do you have a suggestion for how opt-out might look? > I am not even sure opt-out is needed: you can just not set a handler if you don't want the events. Only case where opt-out might be needed seems to be "code running is untrusted, and I want to monitor it using CSP, but don't tell the code about it" Not sure if thats a useful use-case, or whether not raising an event can actually prevent the code from learning the policy. There might be other channels to learn the policy ("did it load?") But I am not sure if I am missing some threat. --dev > -- > 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 Tue, Nov 27, 2012 at 10:34 PM, Devdatta Akhawe <dev.akhawe@gmail.com> > wrote: >> >> 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:51:16 UTC