W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2012

Advice about unprefixing Content-Security-Policy in WebKit

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 28 Aug 2012 16:49:16 -0700
Message-ID: <CAJE5ia97G+36RntSnJ=MhXHW1xTke9ZWsEjbSGHqtjAk_cS4gw@mail.gmail.com>
To: public-webappsec@w3.org
Cc: Mike West <mkwst@chromium.org>
Hi webappsec,

Once the Content-Security-Policy spec is in CR, I'd like to unprefix
WebKit's implementation.  I wanted to share our implementation plans
with you and get your feedback.  We're open to doing things
differently if you'd prefer.

The main question is what to do with our experimental implementation
of CSP 1.1.  Currently, we have our 1.1 implementation behind a
compile-time flag and limited to Chrome's "Dev" channel.  That's
useful for development, but limits our ability to get feedback from
web site authors.  Our current plan is to expose an implementation of
CSP 1.0 via the Content-Security-Policy header and to expose an
implementation of CSP 1.1 via the X-WebKit-CSP header.  We'll then
track the 1.1 spec as it evolves while keeping the CSP 1.0
implementation stable.

The one wrinkle in this plan is the handling of path restrictions in
source lists.  This is one area where CSP 1.1 changes the semantics of
a CSP 1.0 directive.  I was thinking we might enforce path
restrictions for both Content-Security-Policy and the X-WebKit-CSP.
There are two reasons why this seems like a good idea:

1) We can always loosen these restrictions later without breaking
content (e.g., if CSP 1.1 drops path restrictions).

2) Enforcing these restrictions from the beginning lessens the chance
that we'll break content by adding them later when CSP 1.1 advances to

Received on Tuesday, 28 August 2012 23:50:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:28 UTC