Early drafts of CSP2 contained a `reflected-xss` directive, which is little more than syntactic sugar for the `X-XSS-Protection` header. It offered no additional functionality beyond that header, just a better syntax. I shipped our implementation as part of shipping CSP2 (
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/wToP6b04zVE/imuPatGy3awJ). I should have undone that in 2015 when we dropped the directive from the CR draft. I'd like to undo it now.
# Motivation
We removed the directive from the spec. No other browser is going to ship the directive. We should stop shipping it too, as it complicates our implementation and could confuse developers.
# Compatibility Risk
1. No other browser ships this directive or plans to do so. Removing it will align our behavior with the rest of the web.
2. This feature replicated functionality in `X-XSS-Protection`, which other browsers do support. We never dropped support for that directive, which means that developers who wanted to change the XSS Auditor's behavior in Safari, Opera, IE, or Edge would have needed to send that header as well.
3. The major risk is that a developer who wished to disable the XSS Auditor does so only via this directive, and not via `X-XSS-Protection`, meaning that they get opted back into filtering mode, which might make their application vulnerable to some attack vectors. I think this is quite unlikely on its face due to the lack of browser support for the directive (
https://www.openfuture.org/ is the only page in httparchive that is in this situation), and is further mitigated by the fact that we'll be flipping our default from filter to block in the very near future.
# Alternatives
`X-XSS-Protection`.
# Usage Information
We don't have a metric for this in particular.
# Tracking bug
# Feature Dashboard
# Requesting approval to remove?
Yes.