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: Brandon Sterne <bste...@mozilla.com>
Date: Wed, 08 Apr 2009 13:49:17 -0700
Local: Wed, Apr 8 2009 4:49 pm
Subject: Re: Content Security Policy - final call for comments
On 4/8/09 12:07 PM, Gervase Markham wrote:
> On 07/04/09 18:02, Brandon Sterne wrote: Defining a new header seems like a non-starter to me. We are going to >> 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. > There are two sorts of possible breakage - syntax and functional. I be hard-pressed to get one new header standardized, so throwing one away seems very wasteful. >> 3. We arguably want to have a pref for users to turn off CSP (for If sites are relying on CSP for XSS protection, then perhaps they would >> 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. > Why is that useful information? want to serve only "trusted content" to non-CSP users. > I'm actually against making it easy for servers to "detect" if CSP is In reality, as CSP becomes more mature and well-understood, sites will > 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. rely on it for XSS mitigation. It's inevitable that if we put a reliable product out there sites will rely upon it. CSP won't cause input sanitization, etc. to be removed from Security Best Practices, but it will be a standard part of the browser security model, I imagine. >> I looked at each of the HTTP Header Field Definitions and my preference But our header is only sent as a response header, so would not be useful >> 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. > I'd much rather have a "\d+;" at the start of the header. Missing for sending version info with client requests. We're somewhat averse to adding a request header that would only carry the version info, so that's why we're looking for an existing request header that can carry this info. -Brandon 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.
| |||||||||||||