Re: Request for Change to CSP Specification

Hi!

Sorry for the confusion, I thought Jason was talking about the limited data
sent in the report-uri, and the SOP thingy (which is not really SOP is
Public Suffix + 1).

To be honest, I don't really care, the Public Suffix + 1 solves most use
cases I can think of, people could just CName the collection service
(something like csp.apple.com and csp.apple.es are the same server)
Eduardo Vela | Security Inge | evn@google.com | +1 (601) 675-8352



On Sun, Dec 11, 2011 at 1:13 PM, Jason Franklin <jfrankli@cs.cmu.edu> wrote:

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