The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 |
Newsgroups: mozilla.dev.security
From: Gervase Markham <g...@mozilla.org>
Date: Wed, 08 Jul 2009 17:21:20 +0100
Local: Wed, Jul 8 2009 12:21 pm
Subject: Re: Content Security Policy Spec questions and feedback
On 08/07/09 09:02, Daniel Veditz wrote:
> The UA approach may be a botch, but it was an attempt at something like So the versioning in the UA is to guard against a policy syntax change. > 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. 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. > The other approach is to version the response, a few extra bytes only But this scary scenario fails to take into account the frankly tiny > 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. 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 Exactly. > 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. > What if we change the rules? Suppose we add a "head" keyword to the So we have an "inline metadata" bug in the spec, in that we are putting > 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. 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 > Would "frame-parents" make any more sense? Ties in to the window.parent Good idea. > property rather than introducing a new name for the concept Gerv You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||