On 4/7/09 4:07 AM, Gervase Markham wrote: > I much prefer forwardly-compatible designs to version numbers. I think > the current design is forwardly-compatible, as long as we maintain a > well-signposted public page listing which category all sorts of request > fall into, and add new request types well before they get implemented by > anyone. > > For example, if a <3dvideo> tag, for which you needed red-blue glasses, > made it into a draft HTML5 spec, we would decide and say loudly that > this was included in "media-src" well before anyone actually implemented > it. > > Can you suggest a scenario in which version numbers would help?
I think the case for including a version number goes something like this (and strong advocates, please chime in if I miss something): 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. 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). 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. 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. Thoughts? -Brandon [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.8 [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43 _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
