Re: Request for Change to CSP Specification

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.

Jason Franklin
Stanford University

On Fri, Dec 9, 2011 at 9:45 PM, Devdatta Akhawe <> 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, <> 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=
>> Would help us know it was a youtube video.
>> For XSS, perhaps someone forgot to allow the Google's JSAPI:
>> tagName=script&url=
>> 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 <> 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