- From: Jason Franklin <jfrankli@cs.cmu.edu>
- Date: Sun, 11 Dec 2011 13:13:03 -0800
- To: Devdatta Akhawe <dev.akhawe@gmail.com>
- Cc: "sird@rckc.at" <sird@rckc.at>, Daniel Veditz <dveditz@mozilla.com>, public-web-security@w3.org
I'd like to clarify the discussion surrounding the SOP restriction on reports. I'm strongly in favor of removing the restriction and I've yet to hear a coherent argument in favor of keeping the restriction. Since the entity developing the policy is trusted, there is no threat to the confidentiality of report data because by definition the policy will specify where reports should and should not be sent. If the policy creator wants reports sent to another entity, perhaps a report collection or analysis service provider, they should be able to specify this and it makes no sense for the browser to override what the trusted policy creator specifies. If anyone can think of a reasonable adversary model and scenario where cross-origin reports could cause a security property to be violated, I am interested to hear it. More broadly, I suspect that maintaining the SOP restriction on reports will slow or perhaps prevent the wide-spread adoption of CSPs for the following reasons: 1. Costs of report collection and analysis: Organizations may need to provision hardware, software, and humans to process the stream. 2. One of the critical challenges for CSP violation reports is determining how to interpret and respond to reports. For many companies, this will likely require third-party experts. 3. There are substantial benefits to aggregation and sharing of reports to build a global view of threats. Thanks, Jason Franklin Stanford University On Fri, Dec 9, 2011 at 9:45 PM, Devdatta Akhawe <dev.akhawe@gmail.com> wrote: > I am starting a new thread about the data that a report should > generate based on your feedback. This is great feedback that I am sure > the list would love to learn from. > > But, for this thread, would the ability to send the report cross > origin matter at all? > > I feel like the need for more possibly-secret data means you wouldn't > want the ability to send cross-origin reports. > > > -devdatta > > On 9 December 2011 20:50, sird@rckc.at <sird@rckc.at> wrote: >> For instance, what was the URL that triggered the mixed content warning. >> What we get now is "violated directive default-src 'unsafe-inline' >> 'unsafe-eval'". >> >> Something like.. >> >> tagName=iframe&url=http://www.youtube.com/html5/xx11111 >> >> Would help us know it was a youtube video. >> >> For XSS, perhaps someone forgot to allow the Google's JSAPI: >> >> tagName=script&url=http://www.google.com/jsapi >> >> And while that would be enough for the Mixed Content use case, for other use >> cases we've tried to use it (Like GMail+XSS for example), we might even need >> a stack trace. >> >> I remember someone (probably Adam?) was proposing triggering a DOM event (on >> top of the report-uri). If that contains more information it would be enough >> at least for us. >> >> Greetings!! >> >> -- Eduardo >> >> >> >> >> On Fri, Dec 9, 2011 at 6:50 PM, Daniel Veditz <dveditz@mozilla.com> wrote: >>> >>> > We added CSP to Google+ to detect instances of Mixed Content, and with >>> > the current report data its just marginally useful. >>> > >>> > I agree with Jason. >>> >>> What improvements would you like to see in the report data? I don't see >>> how the ability to send "marginally useful" data somewhere new solves your >>> problem. >>> >>> -Dan Veditz >> >>
Received on Sunday, 11 December 2011 21:13:51 UTC