Proposed XSS-Protection HTTP response header -- feedback thread

Mike West was looking for feedback on the proposed XSS-Protection header (
https://mikewest.github.io/artur-yes/).  My thoughts:

  - XSS-Protection applies something like a default strict-csp policy.  We
should define a policy that is going to stand the test of time.  What is
described doesn't exactly mesh with
https://csp.withgoogle.com/docs/strict-csp.html, e.g.: What about
unsafe-eval?

  - I have always expected that our default recommended policy will get
more strict in the future.  In particular, as we see significant deployment
of CSP, we'll likely start to see the post-XSS world (
http://lcamtuf.coredump.cx/postxss/) type attacks become problematic.  In
that case we'll need to start tightening up protections against things like
CSS-based overlay (UI spoofing).  It would seem to be very difficult to
start ratcheting up security in the XSS-Protection header without breaking
things that applied XSS-Protection when the policy was lax.

  - While the precedence rules are defined in very specific detail, it may
be good to document the 10,000ft view on how precedence is supposed to work
w.r.t. X-XSS-Protection & CSP headers.

  - What's the behavior if this header is supplied in the document itself
via a META tag?  For XSS filtering functionality I think this shouldn't be
supported.  (XSS filtering operates under the assumption that injection
into the document is possible.)  For CSP -- maybe?

Dave