Intent to Deprecate and Unship: prefixed Content Security Policy headers.

[Mike West]

Primary eng (and PM) emails

mk...@chromium.org

Spec

http://www.w3.org/TR/CSP/

Summary

Blink has solid support for CSP 1.0 through the unprefixed 'Content-Security-Policy*' headers. I'd like to formally deprecate the prefixed 'X-WebKit-CSP*' headers.

Motivation

We're starting to see some large-scale implementations of CSP that are serving the prefixed header (Facebook and GitHub, for instance). In order to ensure that this prefixed header doesn't inadvertently become a de facto standard, we should deprecate the prefixed headers quickly.

Compatibility Risk

None. Quite the opposite, as the prefixed header potentially impedes compatibility in the long run>

OWP launch tracking bug?

http://crbug.com/231211

Row on feature dashboard?

Yup.

Requesting simultaneous permission to unship?

Yes, kinda. I'd like to start sending a deprecation message to the console when we encounter a prefixed header, with the intent of dropping support for the headers in a future release.

-mike

[Alex Komoroske]

On Mon, Apr 15, 2013 at 10:53 PM, Mike West <mk...@chromium.org> wrote:

Primary eng (and PM) emails

mk...@chromium.org

Spec

http://www.w3.org/TR/CSP/

Summary

Blink has solid support for CSP 1.0 through the unprefixed 'Content-Security-Policy*' headers. I'd like to formally deprecate the prefixed 'X-WebKit-CSP*' headers.

Motivation

We're starting to see some large-scale implementations of CSP that are serving the prefixed header (Facebook and GitHub, for instance). In order to ensure that this prefixed header doesn't inadvertently become a de facto standard, we should deprecate the prefixed headers quickly.

Compatibility Risk

None. Quite the opposite, as the prefixed header potentially impedes compatibility in the long run>

I agree about the long-term, but there still could be short-term compatibility risk in deprecating.

How long have we shipped the prefixed version?

Who else ships the unprefixed version?

Do we have a sense of how many sites use the prefixed version and not the unprefixed version?

What will happen on sites that send the prefixed but not the unprefixed version if we deprecate? 

[Mike West]

Hi Alex!

On Tue, Apr 16, 2013 at 5:10 PM, Alex Komoroske <komo...@chromium.org> wrote:

On Mon, Apr 15, 2013 at 10:53 PM, Mike West <mk...@chromium.org> wrote:

Compatibility Risk

None. Quite the opposite, as the prefixed header potentially impedes compatibility in the long run>

I agree about the long-term, but there still could be short-term compatibility risk in deprecating.

How long have we shipped the prefixed version?

Since Chrome 14 or so, in various stages of completeness.

 

Who else ships the unprefixed version?

Everyone else who uses WebKit/Blink. Safari 6, for example.

Safari 5.x and Android's "Browser" ship the prefixed header as well, but they're unfortunately buggy enough to be fairly unusable.

Firefox ships a differently prefixed version (`X-Content-Security-Policy`), and should be rolling out the cannonical header soon(ish).

 

Do we have a sense of how many sites use the prefixed version and not the unprefixed version?

It's about a 4:1 ratio according to our FeatureObserver measurements. We just shipped the unprefixed version in Chrome 25, so I'd expect folks to be in the process of transitioning.

 

What will happen on sites that send the prefixed but not the unprefixed version if we deprecate? 

Initially, I'd suggest that we send a deprecation warning to the console, but honor the header. In a future release, depending on usage numbers, etc, I'd like to disable the prefixed header entirely.

I'd also suggest that we not support any new CSP 1.1 features on the prefixed header (currently these are locked behind a runtime flag while the standards process moves ahead), as a bit of a carrot to help migrate folks to the canonical header. That's probably a topic for an "Intent to Ship" email sometime down the line.

-mike

[Masataka Yakura]

On Wednesday, April 17, 2013 12:20:08 AM UTC+9, Mike West wrote:

Hi Alex!

On Tue, Apr 16, 2013 at 5:10 PM, Alex Komoroske <komo...@chromium.org> wrote:

On Mon, Apr 15, 2013 at 10:53 PM, Mike West <mk...@chromium.org> wrote:

Compatibility Risk

None. Quite the opposite, as the prefixed header potentially impedes compatibility in the long run>

I agree about the long-term, but there still could be short-term compatibility risk in deprecating.

How long have we shipped the prefixed version?

Since Chrome 14 or so, in various stages of completeness.

 

Who else ships the unprefixed version?

Everyone else who uses WebKit/Blink. Safari 6, for example.

Safari 5.x and Android's "Browser" ship the prefixed header as well, but they're unfortunately buggy enough to be fairly unusable.

Firefox ships a differently prefixed version (`X-Content-Security-Policy`), and should be rolling out the cannonical header soon(ish).

Fx21 (coming in May) will have the canonical header.

https://developer.mozilla.org/en-US/docs/Firefox_21_for_developers#Networking

(They still have a few bugs for full support of CSP 1.0 http://bugzil.la/837682 )

I think IE10 has partial support for CSP under the X-Content-Security-Policy header.

[Mike West]

Hi Masataka-san!

On Tue, Apr 16, 2013 at 5:39 PM, Masataka Yakura <myaku...@gmail.com> wrote:

On Wednesday, April 17, 2013 12:20:08 AM UTC+9, Mike West wrote:

Hi Alex!

On Tue, Apr 16, 2013 at 5:10 PM, Alex Komoroske <komo...@chromium.org> wrote:

On Mon, Apr 15, 2013 at 10:53 PM, Mike West <mk...@chromium.org> wrote:

Compatibility Risk

None. Quite the opposite, as the prefixed header potentially impedes compatibility in the long run>

I agree about the long-term, but there still could be short-term compatibility risk in deprecating.

How long have we shipped the prefixed version?

Since Chrome 14 or so, in various stages of completeness.

 

Who else ships the unprefixed version?

Everyone else who uses WebKit/Blink. Safari 6, for example.

Safari 5.x and Android's "Browser" ship the prefixed header as well, but they're unfortunately buggy enough to be fairly unusable.

Firefox ships a differently prefixed version (`X-Content-Security-Policy`), and should be rolling out the cannonical header soon(ish).

Fx21 (coming in May) will have the canonical header.

https://developer.mozilla.org/en-US/docs/Firefox_21_for_developers#Networking

(They still have a few bugs for full support of CSP 1.0 http://bugzil.la/837682 )

+Ian Melvin, who's working on this in Mozilla.

According to https://bugzilla.mozilla.org/show_bug.cgi?id=783049#c51 it'll be behind a flag in Firefox 21. I'm not entirely sure which of those is more current. (Hi Ian!)

 

I think IE10 has partial support for CSP under the X-Content-Security-Policy header.

Right, I forgot them (sorry!): IE10 supports a single CSP directive (`sandbox`) under the prefixed header.

[Masataka Yakura]

On Wednesday, April 17, 2013 12:48:50 AM UTC+9, Mike West wrote:

Hi Masataka-san!

On Tue, Apr 16, 2013 at 5:39 PM, Masataka Yakura <myaku...@gmail.com> wrote:

On Wednesday, April 17, 2013 12:20:08 AM UTC+9, Mike West wrote:

Hi Alex!

On Tue, Apr 16, 2013 at 5:10 PM, Alex Komoroske <komo...@chromium.org> wrote:

On Mon, Apr 15, 2013 at 10:53 PM, Mike West <mk...@chromium.org> wrote:

Compatibility Risk

None. Quite the opposite, as the prefixed header potentially impedes compatibility in the long run>

I agree about the long-term, but there still could be short-term compatibility risk in deprecating.

How long have we shipped the prefixed version?

Since Chrome 14 or so, in various stages of completeness.

 

Who else ships the unprefixed version?

Everyone else who uses WebKit/Blink. Safari 6, for example.

Safari 5.x and Android's "Browser" ship the prefixed header as well, but they're unfortunately buggy enough to be fairly unusable.

Firefox ships a differently prefixed version (`X-Content-Security-Policy`), and should be rolling out the cannonical header soon(ish).

Fx21 (coming in May) will have the canonical header.

https://developer.mozilla.org/en-US/docs/Firefox_21_for_developers#Networking

(They still have a few bugs for full support of CSP 1.0 http://bugzil.la/837682 )

+Ian Melvin, who's working on this in Mozilla.

According to https://bugzilla.mozilla.org/show_bug.cgi?id=783049#c51 it'll be behind a flag in Firefox 21. I'm not entirely sure which of those is more current. (Hi Ian!)

Oh.

You're right. https://bugzilla.mozilla.org/show_bug.cgi?id=746978#c80 says so too and I don't see the security.csp.speccompliant flag in about:config on my Fx21 beta. My bad.

[Ian Melven]

>> +Ian Melvin, who's working on this in Mozilla.
>> According to https://bugzilla.mozilla.org/show_bug.cgi?id=783049#c51 it'll be behind a flag in Firefox 21. I'm not entirely sure which of those is more current. (Hi Ian!)

> Oh.
> You're right. https://bugzilla.mozilla.org/show_bug.cgi?id=746978#c80 says so too and I don't see the security.csp.speccompliant flag in about:config on my Fx21 beta. My bad.

yes, that's right - https://bugzilla.mozilla.org/show_bug.cgi?id=842657 is the bug for setting that pref,
right now i'm waiting on reviews for https://bugzilla.mozilla.org/show_bug.cgi?id=763879 and after that
we should be able to flip the pref and turn on the unprefixed header for desktop Firefox at least.

we have plans to deprecate the X- header as well in the future, but no set timeline currently.

thanks,
ian

[Adam Barth]

On Mon, Apr 15, 2013 at 10:53 PM, Mike West <mk...@chromium.org> wrote:

Based on the discussion, this LGTM.  We should wait a couple releases before dropping support for the prefixed version of the header.

Adam

[conca...@gmail.com]

Doesn't dropping support open sites using it to security risks. I have no problem with warnings but I would expect at least a year before dropping support. Not everyone operates on Chromes release model.

[Adam Barth]

On Fri, May 24, 2013 at 10:04 AM, <conca...@gmail.com> wrote:

Doesn't dropping support open sites using it to security risks.

Yes, but Content-Security-Policy is necessarily a second line of defense.

 

I have no problem with warnings but I would expect at least a year before dropping support. Not everyone operates on Chromes release model.

The roads of the road are that vendor-prefixed APIs are subject to change.  If folks have year-long release cycles, they shouldn't depend on vendor-prefixed APIs.

Adam

[John Lenz]

Oh please. If there were such rules of the road you would start with deprecation warnings and dates. Or always have them behind flags.  But the truth is you need folks to use them but you are willing to throw them under the bus for some  Web standard ideal and an artificial deadline. I know I won't win an argument with someone with this mindset as we have differing views on what is owed to Web content developers.

I do recommend that you start warning on all vendor prefixes with removal dates (a year off) even if you extend them to allow standards bodies the decades (it seems) to agree on the obviously needed features that force people to use them.   Then I couldn't argue that folks don't know what they are getting into.

[Adam Barth]

On Fri, May 24, 2013 at 10:36 AM, John Lenz <conca...@gmail.com> wrote:

Oh please. If there were such rules of the road you would start with deprecation warnings and dates. Or always have them behind flags.

For new APIs, we're going to keep them behind flags until we think they're stable to avoid exactly this kind of pain.  Unfortunately, we have a backlog of existing vendor-prefixed APIs that we inherited from WebKit that we're trying to work through judiciously.

But the truth is you need folks to use them but you are willing to throw them under the bus for some  Web standard ideal and an artificial deadline.

I don't think we want to throw anyone under a bus.  In this case specifically, dropping support for the prefixed API isn't going to break any web content because X-WebKit-CSP is a purely subtractive feature.  You're right that it will increase the security risk for some websites, but those websites are already bearing that security risk in non-WebKit-based browsers.

For folks who are able to update their websites, they need only switch from using the X-WebKit-CSP header to the standard Content-Security-Policy header, which works in Firefox and other browsers as well.

I know I won't win an argument with someone with this mindset as we have differing views on what is owed to Web content developers.

I think we both value compatibility.  I suspect the difference is mostly in the timescales we're thinking about.  Removing support for vendor prefixes causes short-term pain but will hopefully lead to better compatibility and interoperability in the long term.

I do recommend that you start warning on all vendor prefixes with removal dates (a year off) even if you extend them to allow standards bodies the decades (it seems) to agree on the obviously needed features that force people to use them.   Then I couldn't argue that folks don't know what they are getting into.

We're trying to be careful about which vendor prefixes we're removing because we don't want to cause too much pain for web developers.  The pattern we're following is to feature measure the usage of the feature using opt-in anonymous usage statistics.  Once we see that usage has dropped low enough, we add a deprecation message and continue to measure usage.  At some point, we remove support for the vendor prefix.

You seem to be advocating for a year-long deprecation period, but I'm not sure having a fixed time period really helps very much.  I guess I'm skeptical that we'll be able to stick to a particular deadline.  Instead, whether we can remove the vendor prefix is governed by how frequently the vendor prefix is used.  If the usage is low enough, we can remove it at that point in time, if it's not, they we can't, regardless of any deadline.

In the specific case of X-WebKit-CSP, we can drop support for the prefix earlier than we could for other features because removing support for the header won't cause a compatibility issue.

Adam

[John Lenz]

You missed the point of the deprecated message with the deadline. The point is not about actually meeting any particular date. It is about communication and setting expectations.   By starting with a removal date, you state it will be removed and isn't a extension that may never be standardized and you plan to support forever (which from where I sit has been the effective policy in the past).   My choice of a year was chosen because I've never see a standard body act fast but is near enough to not be see as a far off future, otherwise it has no meaning. If you can standardized in 2 weeks, and expect to remove it in 3 by all means use a date 3 weeks out.  "removal is expected near ...".

I understand the problem with removing legacy prefixes, so my recommendation is don't.  The cost of maintaining an alias in low and there was no expectation that they would be removed.  That is water under the bridge. Make sure moving forward that this doesn't repeat by communicating clearly in the browser itself from the start.

[Adam Barth]

On Fri, May 24, 2013 at 11:28 AM, John Lenz <conca...@gmail.com> wrote:

You missed the point of the deprecated message with the deadline. The point is not about actually meeting any particular date. It is about communication and setting expectations.   By starting with a removal date, you state it will be removed and isn't a extension that may never be standardized and you plan to support forever (which from where I sit has been the effective policy in the past).   My choice of a year was chosen because I've never see a standard body act fast but is near enough to not be see as a far off future, otherwise it has no meaning. If you can standardized in 2 weeks, and expect to remove it in 3 by all means use a date 3 weeks out.  "removal is expected near ...".

Are you speaking generally or about X-WebKit-CSP specifically?  In the case of CSP, the W3C published a Candidate Recommendation for the feature back in November:

http://www.w3.org/TR/CSP/

We started shipping the unprefixed Content-Security-Policy header shortly thereafter.  The X-WebKit-CSP header currently prints a deprecation notice:

"The 'X-WebKit-CSP' headers are deprecated; please consider using the canonical 'Content-Security-Policy' header instead." 

I understand the problem with removing legacy prefixes, so my recommendation is don't.  The cost of maintaining an alias in low and there was no expectation that they would be removed.  That is water under the bridge. Make sure moving forward that this doesn't repeat by communicating clearly in the browser itself from the start.

It's true that the implementation cost for us is low, but the real cost is that vendor prefixes harm the larger web ecosystem, as Henri Sivonen wrote in http://hsivonen.iki.fi/vendor-prefixes/.  We could ignore that problem, but instead we're trying to help heal some of that harm by removing support for prefixes where the compatibility cost is manageable.

[John Lenz]

Post facto warnings don't help (I didn't mean deprecation warnings previously but simply a removal warning). They need to be there from the start.  I am aware of the arguments against vendor prefixes and agree that vendor prefixes fragment the web but I disagree that removing the prefixes and breaking compatibility is the right thing to do unless you have clearly state this intent when the content was developed.

CSP is an example of this but this isn't specifically about CSP. It is about policy.

The sad fact is that vendor prefixes mean "extension" not "temporary trial"  and until there is only one browser vendor (which no one wants) there will always be vendor specific extensions and folks take advantage of these when they can. If you don't them to you need to tell them.

[Christian Biesinger]

I'm not sure it's correct that most people assume that vendor prefixes
are extensions vs temporary -- in the case of CSS, lots of people add
both the prefixed and the unprefixed version of the property.

And it's also not really correct that "there will always be
vendor-specific extensions". Both Mozilla and Chrome are moving away
from that and have committed not to add any new ones.

-christian

[Mike West]

The `X-WebKit-CSP` prefixed headers have now been deprecated as of the Chrome 28 release. I'd _like_ to remove support right now, which I think would mean that Chrome 33 would support only the 'Content-Security-Policy' and 'Content-Security-Policy-Report-Only' headers.

According to UseCounter data, we're seeing a ~350:1 ratio between unprefixed and prefixed enforce-mode header usage (I expect Facebook is a large chunk of that number), and a ~60:1 ratio between unprefixed and prefixed report-only header usage. Prefixed headers appear on 0.05% of page loads.

The only other (major) browser I know of which supports the 'X-WebKit-CSP' will support the unprefixed header in its upcoming releases (Safari 6.1 and 7).

I would suggest that we first drop support for the prefixed headers, but leave deprecation messages in place for another few releases to help developers transition to the supported, unprefixed headers.

-mike

--
Mike West <mk...@google.com>

Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Graham Law, Christine Elizabeth Flores

[Eric Seidel]

Sounds good.  Do we have UMA numbers to confirm?  I assume this is well under the 0.03% we've successfully removed features at?

https://groups.google.com/a/chromium.org/d/msg/blink-dev/bs3NIiqnc8Q/l9hyhrZLkE8J

[Mike West]

Note the second paragraph: for more exact detail, 'X-WebKit-CSP' was ~0.0404% at the end of last week. 'X-WebKit-CSP-Report-Only' was ~0.007%.

CSP is a bit different than other features in that it can't _break_ pages. It has the effect of removing a secondary line of defense for sites, but doesn't add any risk that the sites aren't already facing in other browsers. I'd suggest that means we can assign a lower bar for removal, and more weight to the risk of perpetuating the prefixed header as a de facto standard.

-mike

--
Mike West <mk...@google.com>

Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Graham Law, Christine Elizabeth Flores

[Eric Seidel]

Lgtm

[Jochen Eisinger]

lgtm

[Adam Barth]

Lgtm