W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2012

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

From: sec_ext <sec_ext@fb.com>
Date: Wed, 29 Feb 2012 22:53:34 +0000
To: "Ware, Ryan R" <ryan.r.ware@intel.com>, Adam Barth <w3c@adambarth.com>
CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <CB73EBA3.32B2%sec_ext@fb.com>
Does this mean the blocked-uri will now be sent by Chrome when a CSP
violation occurs? I know it was originally stripped due to some privacy
concerns.

Thanks, Link

On 2/28/12 5:57 PM, "Ware, Ryan R" <ryan.r.ware@intel.com> wrote:

>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 Thursday, 1 March 2012 07:16:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 1 March 2012 07:16:58 GMT