On 08/07/09 09:02, Daniel Veditz wrote:
The UA approach may be a botch, but it was an attempt at something like a less-verbose Accept-type header (six bytes in the UA, many more as a separate header which would have to be sent with every request, with no servers today actually understanding anything about CSP). Should the policy syntax ever change a server could theoretically send different syntax to a CSP/1 browser and a CSP/2 browser.
So the versioning in the UA is to guard against a policy syntax change. But the syntax is so simple a list of (key/value pairs) that it's very, very hard to imagine a requirement which would mean we *had* to break the syntax. And yet, every request the browser ever sends acquires another six bytes, until the end of time. (This is not a UA token which changes over time as browsers change, like OS, it's one which has to be present for ever.)
I don't think the risk of needing a breaking syntax change is worth it. In that very unlikely event, we should instead plan to deploy a new header, as you say below. There's more downstream bandwidth than upstream, and there's more every year.
The other approach is to version the response, a few extra bytes only when a server supports CSP. Yay, bandwidth win! But then what do we do? How does the server know which version to send? Should it send every version it knows about, and the client process the highest version it knows how to process? That means if we ever have a CSP-2 either clients are sending two complete headers (or three, or more) or they're sending their preferred version and users of clients which only support CSP-1 get zero protection rather than the 99% they actually support.
But this scary scenario fails to take into account the frankly tiny chance that we'll need to make one breaking syntax change, let alone two. Even with the spec as it is. Careful design can reduce the chances even further.
In the case of brand-new directives older clients can simply ignore unknowns and that will work OK in many cases. Either loads of that type aren't supported at all (e.g. downloadable fonts, maybe?) or they can reasonably fall-back to the default allow directive. That might leave users of older clients vulnerable for that type (or only partially protected), but no worse than users of browser that don't support CSP at all.
Exactly.
What if we change the rules? Suppose we add a "head" keyword to the script-src directive. Older clients will think that's a host named "head" and strip all the in-line<head> scripts the site relies on.
So we have an "inline metadata" bug in the spec, in that we are putting domain names and keywords in the same slot. We could either use case to delimit keywords (HEAD, SELF) or we could prefix them with a character not permitted in hostnames (!head, $self).
Even if we'd deployed already, we could fix this without breaking syntax by having a script-head: yes directive. Ugly, sure; I mention it just to show that the chances of us _having_ to break compatibility are tiny.
Would "frame-parents" make any more sense? Ties in to the window.parent property rather than introducing a new name for the concept
Good idea. Gerv _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
