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 Spec questions and feedback
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 Jul 8 2009, 12:25 pm
Newsgroups: mozilla.dev.security
From: Gervase Markham <g...@mozilla.org>
Date: Wed, 08 Jul 2009 17:25:26 +0100
Local: Wed, Jul 8 2009 12:25 pm
Subject: Re: Content Security Policy Spec questions and feedback
Print | View thread | Show original | Report this message | Find messages by this author
On 07/07/09 19:18, Sid Stamm wrote:

> I personally want to eradicate the META tag
> (http://blog.sidstamm.com/2009/06/csp-with-or-without-meta.html). This
> should be discussed more in depth to decide if we should remove META
> support, if we should support multiple HTTP headers, etc.

My comment:

Why not allow multiple headers, and keep the intersection algorithm?

This way, the hosting company has to provide a special interface for
editing the header rather than the customer just being able to type it
into the page, but it still allows it to make non-negotiable
restrictions. They just serve their restrictions in the first header,
and make sure the customer-provided header comes afterwards.

This means you still need the policy intersection logic, so that part of
complexity isn't removed, but it still allows, at least in some ways,
the use case that you were worried about. A compromise, in other words.

However, I would now add that removing <meta> support (i.e. inline
policy) and sticking with headers makes CSP an HTTP-only technology. Is
that something we are happy with?

> Spec updated to support relative URIs. I don't think CSP should interact
> with the BASE tag at all.

I agree. Even with <meta>, it's just saying "hey, here's a header you
didn't get". So none of your <base> are belong to us.

>> What happens to CSP if I save a CSP-protected document to my local
>> disk? I’d assume it would be ignored (because many restrictions could
>> be broken) but this should be explicit. Also, when saving docs to
>> disk, HTTP headers are lost, so to preserve it, you’d need to
>> explicitly serialize to a META tag, which could get complicated if the
>> document already had a CSP META…
> Under discussion.

Let's say content saved to disk should just lose its CSP. What would be
the disadvantages of that policy?

> Updated spec to allow "https://self:443" syntax. Self flexible and may
> or may not include scheme and port. When absent from the expression,
> scheme or port are inherited.

Good idea.

>> Apparently, ASP.NET controls are tightly bound to use of JavaScript:
>> protocol URIs, and this isn’t likely to be easily changed. For that
>> reason, it might be interesting to have a way to allow only those URIs
>> and not inline script blocks, event handlers, etc?
> Under Discussion.

I think we need to figure out whether permitting this in fact blows all
protection out of the water, or not.

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