ISSUE-11: Violation report privacy issues
Violation report privacy
Violation report privacy issues
- State:
- CLOSED
- Product:
- CSP Level 1
- Raised by:
- Brad Hill
- Opened on:
- 2012-01-17
- Description:
- Section 4.11 of Content Security Policy:
To send a violation report, the user agent must use an algorithm equivalent to the following:
1.Prepare a dictionary violation dictionary with the following keys and values:
request HTTP request line of the protected resource whose policy was violated including method, URI and HTTP version
request-headers HTTP request headers sent with the request for the protected resource whose policy was violated
blocked-uri URI of the resource that was prevented from loading due to the policy violation
violated-directive The policy directive that was violated
original-policy The original policy as received by the user-agent. If the policy was received via more than one Content Security Policy response header, this field must contain a comma separated list of original policies
Issue: We might need to change some of these keys because they can leak sensitive information.
- Related Actions Items:
- No related actions
- Related emails:
- No related emails
Related notes:
Many of the original fields of the CSP report have been removed to address security and privacy considerations.
LC commnent from Fred Andrews regarding user consent and implementation considerations:
http://lists.w3.org/Archives/Public/public-webappsec/2012Sep/0013.html
The reporting is a gross invasion of privacy, and simply fails to meet the technical reality that the client is in command and the CSP is advisory. A client may have good reason in normal operation for operating outside the restrictive set of resources needed by the web application. If there is any reporting then it should be to the user at the client to inform them about applications operating outside their declared resource needs. Any feedback reports should be opt-in.
Re-opened due to LC comment by Fred Andrews:
"The reporting is a gross invasion of privacy, and simply fails to meet the technical reality that the client is in command and the CSP is advisory. A client may have good reason in normal operation for operating outside the restrictive set of resources needed by the web application. If there is any reporting then it should be to the user at the client to inform them about applications operating outside their declared resource needs. Any feedback reports should be opt-in."
Nothing that this report provides cannot either be known by the sender of the request or reported using standard DOM / script interfacesa available to resources without the use of CSP. (In fact, some prototype implementations were created entirely in ECMAScript.)
Responses to this issue can be found in the following threads: (there are often several replies, so it is suggested to view "Contemporary messages sorted by thread".
http://lists.w3.org/Archives/Public/public-webappsec/2012Oct/0021.html
http://lists.w3.org/Archives/Public/public-webappsec/2012Sep/0048.html
http://lists.w3.org/Archives/Public/public-webappsec/2012Oct/0008.html
http://lists.w3.org/Archives/Public/public-webappsec/2012Oct/0029.html
The group's decision to close this issue without changing spec behavior was recorded in the minutes to the following teleconferences:
http://www.w3.org/2011/webappsec/minutes/webappsec-minutes-25-Sep-2012.html
http://www.w3.org/2011/webappsec/minutes/webappsec-minutes-23-Oct-2012.html
Display change log
