- From: Adam Barth <w3c@adambarth.com>
- Date: Mon, 27 Feb 2012 23:09:01 -0800
- To: "Ware, Ryan R" <ryan.r.ware@intel.com>
- Cc: public-webappsec@w3.org
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. Adam >> 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 Tuesday, 28 February 2012 07:10:06 UTC