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
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 6 2009, 6:56 am
Newsgroups: mozilla.dev.security
From: Gervase Markham <g...@mozilla.org>
Date: Mon, 06 Apr 2009 11:56:00 +0100
Subject: Re: Content Security Policy - final call for comments
Hi Brandon,

Thanks for your continued hard work on this.

Are we expecting to see some or all of this in Firefox 3.5, or Firefox-next?

On 02/04/09 22:12, Brandon Sterne wrote:

> If you have feedback that you would like to share regarding Content
> Security Policy, please do so ASAP as the window for making changes to
> the model will soon be closing.

Here are some comments on https://wiki.mozilla.org/Security/CSP/Spec. In
general, I think it's excellent :-)

- When might we see the "Refinements" section with the JS/eval changes?
Or is that the other document?

- "When both a X-Content-Security-Policy HTTP header and meta tag are
present, the intersection of the two policies is enforced; essentially,
the browser enforces the most *relaxed* policy satisfying both the
policies specified in the meta tag and header."

Surely you mean "strict", not "relaxed"? The example seems to show that
the resulting policy is more strict than either of the two source policies.

- What happens if a Report-URI encounters a redirect? We should say
specifically in the spec what we do, and I think we should honour it.
This would allow us to do "all reports must be sent to the same host
that served the protected content" while still allowing people to set it
up so that the logging server was a separate machine.

- Would it not be more flexible, with negligible change in
implementation complexity, to make report-uri multi-valued? We have to
support multiple values anyway.

- "but a declared (unexpanded) policy always has the "allow" directive."
I think you need to make it more clear that "allow" is mandatory. But
what was the logic behind making it so? Why not assume "allow *", which
is what browsers do in the absence of CSP anyway?

- The formal syntax uses "<host-expr-list>" but it's undefined in that
formal section. Is that intentional?

- Should there be a space or other separator in the middle of
"<allow-directive><directive-list>"?

- The Violation Report Sample has:
"<blocked-uri>some_image.png</blocked-uri>". Given that the directive
blocked was a "self" directive, I would expect some_image.png to be on
another host, and therefore for a full URI to be provided. (This is
vital for trying to find out who is behind the content injection.) What
have I missed?

And the other document
http://people.mozilla.org/~bsterne/content-security-policy/details.html:

- "policy-uri documents must be served with the MIME type
text/content-security-policy to be valid" This probably needs an "x-"
until we've registered it, which we should do before deployment. It's
not a complex process, I hear.

- "Hostname, including an optional leading wildcard, e.g. *.mozilla.org"
Does that include foo.bar.baz.mozilla.org? If so, we should say so
explicitly (in both docs).

Again, great work :-)

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.