Gervase Markham wrote on 12/12/2008 11:22 AM: > Bil Corry wrote: >> Let's back up. The CSP method you support (correct me if I'm wrong) >> is for the server to send a CSP header to all clients. And if the >> client understands the header, it'll kick on some extra protections >> not currently afforded to the site. And that's great for CSPv1. But >> lets take it to the extreme, say there is now five different CSP >> versions, and none of them are compatible with each other. > > Stop right there. How does this potential future problem dissuade people > from deploying CSP now (which is what you were worried about)?
It doesn't. For this, I am worried about future, non-compatible revisions. But your point is taken that it may be unlikely to happen. >> Beyond that, it has other benefits, perhaps the biggest one is being >> able to measure how many clients are using CSP. How will you measure >> the success of CSP if you have no way of knowing if 1% of browsers >> are using it, or 99%? > > This is a feature. The only reason you'd want to do this is to see if > you could rely on it. The reason site owners want to know how many people are using it is to see if it's worth the effort to implement and maintain it. Take Cookie2 for example. Only Opera supports it, so most sites only use Cookie. > Anyway, you could get approximate stats by mapping from browser versions. Browsers without built-in CSP support might have a plug-in available, and browsers with built-in CSP support might have it turned off. But yes, once most browsers have built-in support, you could approximate stats based on user-agent. In the end, sites that want to know which browsers support CSP will simply test for it (just like cookies and JavaScript); I see the client header as a convenience vs. having to test for it and it offers some other limited benefits, but if it violates the CSP paradigm, then certainly skip the suggestion. - Bil _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
