Account Options

  1. Sign in
The old Google Groups will be going away soon.
Switch to the new Google Groups.
Google Groups Home
« Groups Home
mozilla.dev.security
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Content Security Policy - final call for comments
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
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Gervase Markham  
View profile  
 More options Apr 8 2009, 3:07 pm
Newsgroups: mozilla.dev.security
From: Gervase Markham <g...@mozilla.org>
Date: Wed, 08 Apr 2009 20:07:40 +0100
Local: Wed, Apr 8 2009 3:07 pm
Subject: Re: Content Security Policy - final call for comments
Print | View thread | Show original | Report this message | Find messages by this author
On 07/04/09 18:02, Brandon Sterne wrote:

> 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
can't see us needing to throw away the syntax and, if we did, we'd just
define a new header. So no issues there. And functional breakage comes
into your second category anyway.

> 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).

But the old browsers also won't support the new APIs/whatever. If we add
a <3dcanvas> element to Firefox and control it with 3dcanvas-src, then
old browsers won't understand the element, and so ignore it. And so if
the browser didn't understand 3dcanvas-src either, that's no big deal.

CSP should specify that unknown directives are ignored. That's a fairly
common way to deal with this problem (CSS, HTML etc.).

The only problem would be if an existing browser feature acquires
specific restrictions when it used to be covered by "all". In that case,
users of old browsers would get less protection - but they had that
anyway, because their CSP implementation doesn't support the extra
restriction.

> 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.

Why is that useful information?

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 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.

I'd much rather have a "\d+;" at the start of the header. Missing
implies version 1.

Gerv


 
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.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google