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