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.
2. New types of content (per your example) or new web APIs may be added
in the future which don't shoehorn nicely into one of our current policy
buckets. If we have to add another policy directive in the future, then
it will violate the policy syntax in older versions which will cause
them to fail closed (according to the current design).
But the old browsers also won't support the new APIs/whatever. If we add
a <3dcanvas> element to Firefox and control it with 3dcanvas-src, then
old browsers won't understand the element, and so ignore it. And so if
the browser didn't understand 3dcanvas-src either, that's no big deal.
CSP should specify that unknown directives are ignored. That's a fairly
common way to deal with this problem (CSS, HTML etc.).
The only problem would be if an existing browser feature acquires
specific restrictions when it used to be covered by "all". In that case,
users of old browsers would get less protection - but they had that
anyway, because their CSP implementation doesn't support the extra
restriction.
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?
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.
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.
Gerv
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
