> Some really, really great points here. My thoughts on some of them:

> On 06/07/09 01:28, EricLaw wrote:> Server CSP Versioning
> > Can the server define which version of CSP policies it wants to use,
> > allowing the client to ignore?  I know that backward compatibility is
> > the goal, but other successful features (E.g. Cookies) have had tons
> > of problems here as they try to evolve.  The current “Handling parse
> > errors” section imposes a number of requirements that might be onerous
> > in the distant future when we’re on version 5 of the CSP feature.

>  >
>  > User-Agent header
>  > What’s the use-case for adding a new token to the user-agent header?
>  > It’s already getting pretty bloated (at least in IE) and it’s hard to
>  > imagine what a server would do differently when getting this token.

> I also haven't quite got this straight in my head.

> I think it would be useful for the spec to contain a lot more detail on
> what it hopes to achieve with the current versioning system - scenarios
> where it would be useful, scenarios where it won't help, and so on - and
> also why we decided not to put a version number in the CSP response itself.

> > Style-src
> > I don’t know what “style attributes of HTML elements” means.

> It means <div style="some CSS here"></div>

> I guess so :-)

> > W3C folks have been giving us (IE) a hard time about the number (and
> > scattered documentation) of X- header names
> >http://blogs.msdn.com/ieinternals/archive/2009/06/30/Internet-Explore...,
> > and they’ve strongly encouraged us to register our header names (even
> > provisionally) with IANAhttp://www.iana.org/assignments/message-headers/message-header-index....
> > rather than using the X- prefix.

> I'm sure we can do that, particularly if we have buy-in or tacit support
> from multiple browser vendors. We are early in a Firefox development
> cycle, so we do have time.

> > HTTP Header: Final
> > It seems like it might be useful for a CSP Header to declare that it’s
> > the “Final” security policy, to prevent meddling by META Header
> > injection and the like.

> The very existence of "meta" is now under discussion. But I think that
> if we do implement a merging algorithm (which I think we should, albeit
> for multiple headers) a "final" directive might be useful.

> Very good question.

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

> Another good one. Gut reaction: The things CSP is supposed to help with
> are mostly connected with the page being loaded from a particular target
> site. If it's no longer being loaded from that site, many of them go
> away. So I think the answer is that CSP protection is removed. We
> currently restrict HTML loaded from the local disk from accessing other
> files on the local disk, but not in other ways.

> > Therefore, a site could specify “*.example.com” to match
> > “www.example.com”and “example.com”.

> Hmm. For people not thinking, this would obey the Rule of Least
> Surprise, but for people thinking, it would not obey that rule. <sigh>

> > Doesn’t make sense to me, because “self” is defined to include the
> > scheme.  This suggests that we need a "selfhost" directive, which
> > includes the hostname only.

> Or we make the same word serve two purposes, doing the "obvious" thing.

> > Parse Errors: Server detection
> > Parse errors are defined as only being reported on the client.  This
> > is probably reasonable, but leads to the possibility that some UA will
> > fail to parse some CSP directive and the server operator will not know
> > about it.

> Will this be a problem in practice, given that presumably the server
> owner tests their site with a variety of UAs? We don't ping server
> owners to say "your HTML is unparseable", after all. That would rather
> increase the amount of traffic on the Internet! ;-)

> This is a problem with a "tighten when the header is used, and then use
> directives to loosen" approach. Content Restrictions had the opposite
> approach - it started with loose (i.e. the situation as it is without CR
> support) and tightened using directives. This avoided this problem. Of
> course, both directions have pros and cons.

> We need to avoid breaking Greasemonkey/GreasemonkIE.

> > Scope Creep: exempt HEAD
> > We’ve had some folks suggest that CSP-like schemes would be more
> > easily deployed if they could allow arbitrary script/css to be
> > embedded inline/referenced in the HEAD tag.

> Yes; CR originally had a way to allow this. I think it would make
> converting sites quite a bit easier.

> > In particular, this could be used by non-JS responses to explicitly
> > prevent them from being used by SCRIPT tags, and to prevent HTML files
> > from being scraped by liberal CSS parsers.  This is an anti-CSRF ASR.

> I think using CSP should also mean that the scripts which are permitted
> have to be served with the correct content type. As others have said,
> this prevents people using E4X and some user content elsewhere in the
> same domain to inject script which is actually an HTML page.

> Yes, we need to think more about how CSP applies to non-HTML and
> non-HTTP resources.

> > It seems natural that a subdownload should be able to say e.g. Content-
> > Security-Policy: callers<originlist>  which would cause the UA network
> > stack to refuse to process (e.g. Set-Cookie) or return the content (to
> > a script tag, object tag, image tag, XHR request etc) unless the
> > Origin of the requestor matches the specified Origin list.

> People have wanted the web to do this for years to prevent people
> leaching e.g. image bandwidth, but I'm not convinced it would be a great
> thing for the web. It seems to me that this sort of behaviour is a
> regrettable side effect of an open web, but one we should just live with.

> Presumably you've sent that feedback in the relevant direction?

> I know nothing about ASP.NET controls. Are these pre-built blocks of
> HTML that can be included in a page when it's built with ASP?