On 4/8/09 12:07 PM, Gervase Markham wrote: > On 07/04/09 18:02, Brandon Sterne wrote: >> 1. Bugs may be present in the CSP design which require future >> compatibility breakage. These obviously cannot be foreseen and, though >> we desire it, we can't guarantee forward compatibility. > > There are two sorts of possible breakage - syntax and functional. I > can't see us needing to throw away the syntax and, if we did, we'd just > define a new header. So no issues there. And functional breakage comes > into your second category anyway.
Defining a new header seems like a non-starter to me. We are going to be hard-pressed to get one new header standardized, so throwing one away seems very wasteful. >> 3. We arguably want to have a pref for users to turn off CSP (for >> testing or otherwise). It would be useful to have the version number >> available as a means to communicate to the site that, even though the >> client supports CSP by default, CSP has been disabled on this client. > > Why is that useful information? If sites are relying on CSP for XSS protection, then perhaps they would want to serve only "trusted content" to non-CSP users. > I'm actually against making it easy for servers to "detect" if CSP is > supported, because if we make it particularly easy, content authors will > start relying on it as their only defence rather than using it as a > backup. "We don't need to check for XSS holes, we use CSP." That would > be bad. Of course, we can't stop them putting together fragile > User-Agent lists, but sites which do that are broken anyway, as the web > design community has been saying for years. In reality, as CSP becomes more mature and well-understood, sites will rely on it for XSS mitigation. It's inevitable that if we put a reliable product out there sites will rely upon it. CSP won't cause input sanitization, etc. to be removed from Security Best Practices, but it will be a standard part of the browser security model, I imagine. >> I looked at each of the HTTP Header Field Definitions and my preference >> for communicating the CSP version is to add a product token [1] to the >> User-Agent [2] string. This would add only a few bytes to the U-A and >> it saves us the trouble of having to go through IETF processes of >> creating a new request header. > > I'd much rather have a "\d+;" at the start of the header. Missing > implies version 1. But our header is only sent as a response header, so would not be useful for sending version info with client requests. We're somewhat averse to adding a request header that would only carry the version info, so that's why we're looking for an existing request header that can carry this info. -Brandon _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
