- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 3 May 2012 09:08:48 -0700
- To: Tom Ritter <tom@ritter.vg>
- Cc: public-webappsec@w3.org
I'm not sure I understand. Can you explain what you mean a bit more? Thanks, Adam On Thu, May 3, 2012 at 9:05 AM, Tom Ritter <tom@ritter.vg> wrote: > Is there a way currently to say "http on the standard port implies > https on its standard port" for the source list? If not, I think > that'd be nice. > > -tom > > > On 3 May 2012 01:05, Adam Barth <w3c@adambarth.com> wrote: >> At the face-to-face today, we talked through the proposed directives >> on the wiki page: >> >> http://www.w3.org/Security/wiki/Content_Security_Policy >> >> The sense I got from the room was that there was significant interest >> in the following set of directives, so I moved them to the "Proposals >> for Version 1.1" section of the wiki: >> >> * sandbox. This directive was in CSP 1.0, but it's looking like we're >> going to move it to CSP 1.1 so that we can move CSP 1.0 along the W3C >> process faster. >> >> * The ability to convey a CSP policy in a <meta> tag. This used to be >> in the CSP 1.0 spec, but was punted because it needed some further >> polishing. We talked it over at the face-to-face and generated some >> good ideas for how to improve on the previous design. I'll post more >> details once I write them up in a coherent way. >> >> * A DOM API for reading the policy, likely something akin to >> <https://mikewest.org/2012/05/content-security-policy-feature-detection>. >> >> * script-nonce. This directive lets sites further lock down scripts >> by requiring that <script> elements need to both satisfy the >> script-src directive AND have an attribute containing a nonce declared >> by the script-nonce directive. >> >> * frame-ancestor and/or frame-options. We should coordinate with the >> IETF websec working group on Frame-Options to see whether it makes >> more sense for that to be a CSP directive rather than >> yet-another-security-policy-in-an-HTTP-header. >> >> * form-action. This directive lets site restrict which URLs can be >> used as the actions of forms. In Postcards from the post-XSS world >> <http://lcamtuf.coredump.cx/postxss/>, lcamtuf previews for us the >> kinds of XSS attacks sites will need to deal with after deploying CSP. >> The form-action directive helps with some of these and fits nicely in >> with the CSP 1.0 directives, so it seems like a win. >> >> * plugin-types. This directive lets sites provide a whitelist of >> plugin MIME types they allow. For example, a site could whitelist >> Flash, thereby excluding Google Gears. Some folks wanted to be able >> to specify which MIME types were acceptable from which origins, but we >> couldn't come up with an elegant syntax. >> >> * More granular source like (e.g., by directory). Rather than >> whitelisting an entire origin, sites might wish to whitelist only >> certain directories within those origins. For example, >> script-src https://example.com/js; style-src https://example.com/css >> There's some question about whether how we want these sorts of >> policies to be interpreted by a CSP 1.0 compliant user agent. We >> might need to tweak the CSP parser slightly to make this work well. >> >> Please note that this is just a very rough sketch of which directives >> we're going to work on for CSP 1.1. Please feel encouraged to send >> ideas for new directives to the list and to add them to the wiki. If >> you hate these directives or love other directives, please also feel >> encouraged to make your feelings known. :) >> >> Thanks! >> Adam >>
Received on Thursday, 3 May 2012 16:09:51 UTC