Re: Removing the same(ish) origin restriction on report-uri

On Tue, Feb 28, 2012 at 4:09 PM, Adam Barth <w3c@adambarth.com> wrote:
>
> On Mon, Feb 27, 2012 at 7:27 PM, Ware, Ryan R <ryan.r.ware@intel.com>
> wrote:
> > On Tue, Feb 28, 2012 at 10:01 AM, Adam Barth <w3c@adambarth.com> wrote:
> >>
> >> I went through all the feedback on CSP violation reports today and
> >> made a bunch of edits based on our previous discussions.  I wanted to
> >> re-confirm one of those edits with the list:
> >>
> >> http://dvcs.w3.org/hg/content-security-policy/rev/275074d083aa
> >>
> >> In that edit, I've removed the restriction that the report-uri needs
> >> to have the same scheme, port, and registry-controlled domain as the
> >> document-uri.  Originally, we had this restriction because the
> >> violation reports contained sensitive information, such as
> >> request-headers.  Since then, we've changed the form of the violation
> >> reports a bit so that there isn't nearly as much sensitive information
> >> in the reports (which means we can remove the "ugly" dependency on the
> >> public suffix list).
> >
> >
> > Can we get an explicit list of which portions of the reports might still
> > contain sensitive information to better judge if the change is
> > appropriate?
>
> document-uri
> -> The address of the protected document, with any <fragment> component
> removed
>
> referrer
> -> The referrer attribute of the protected document
>
> blocked-uri
> -> URI of the resource that was prevented from loading due to the
> policy violation, with any <fragment> component removed
>
> violated-directive
> -> The policy directive that was violated
>
> original-policy
> -> The original policy as received by the user-agent.
>
> None of these contain particularly sensitive information, as far as I can
> tell.

Thanks Adam.  Given that list I'd concur with your assessment.

Ryan

> >> This edit seems consistent with our April 2011 discussions on this
> >> topic, but since that was a while ago, I wanted to re-confirm with the
> >> list.
> >>
> >> Thanks!
> >> Adam
> >>
> >

Received on Wednesday, 29 February 2012 01:57:47 UTC