Gervase Markham wrote: >> 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).
That misses my point. Suppose we have such a syntax and add a new $HEAD keyword. The old client knows it is not a hostname and ignores it as an unknown keyword. Then it merrily follows old behavior and strips all the in-line scripts from the <head> section, breaking the site. > 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. The problem is not the syntax but the meaning. The site wants to use a configuration that cannot be expressed in the old syntax. If the client advertises its support level the site might be able to send different CSP headers (or none at all) for the older client. Alternately we put versioning into the CSP response header, either explicitly in the proposed syntax or implicitly by later using Content-Security-Policy-2 after significant changes in meaning. If we're optimistic that we've got the buckets close to right we can ignore versions for now and later change the header name if we have to. That seems to be what you're saying; I'm clearly not as optimistic as you -- occupational hazard. I suppose we're already taking that tack by using an X- header for now, giving us a one-time pass to change the syntax/semantics when we drop the X- before ship. Realistically, though, there won't be enough real-world use by then to have figured out what might need to be different. Separate from the header, we may want to plan for versioning in the policyURI file format, maybe even versioned sections so that even if we do have a semantic change a site could fall back to sending a common CSP: policyURI <foo> to everyone. -Dan _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
