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: Bil Corry <b...@corry.biz>
Date: Wed, 08 Apr 2009 14:45:23 -0500
Local: Wed, Apr 8 2009 3:45 pm
Subject: Re: Content Security Policy - final call for comments
Gervase Markham wrote on 4/8/2009 2:07 PM:
> On 07/04/09 18:02, Brandon Sterne wrote: It seems unlikely that responsible web developers would rely entirely on CSP, especially initially, since not all UAs will support it. And if the developer really does choose to rely entirely on CSP, there isn't much we can do -- any developer with two domains can easily test if the client supports CSP, request header or no header. > I'm actually against making it easy for servers to "detect" if CSP is > supported, because if we make it particularly easy, content authors will > start relying on it as their only defence rather than using it as a > backup. "We don't need to check for XSS holes, we use CSP." That would > be bad. Of course, we can't stop them putting together fragile > User-Agent lists, but sites which do that are broken anyway, as the web > design community has been saying for years. I think the stronger likelihood is that the developer won't use CSP at all -- their site will still work regardless. Providing a CSP header that can be measured to show it's worth the effort to learn and implement will be a much stronger incentive. In summary, given the number of XSS holes out there, if the developer chooses to rely entirely on CSP to protect them, that's far better than not using CSP at all. The biggest threat to CSP is not over-reliance, but rather under-utilization. - Bil 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.
| |||||||||||||