Bug 100974 – Measure the usage of the various CSP headers.

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Mike West]

We're currently using measuring usage of the prefixed CSP header via FeatureObserver (which ends up in the 'WebCore.FeatureObserver' histogram). We've now added support for the unprefixed header, and it would be nice to measure that as well so that we can (at some point in the far future) drop support for the prefixed version. It would also be potentially helpful to measure the uptake of report-only headers vs. blocking headers, as that could help guide some of the discussion for 1.1.

Rather than add three new items to the FeatureObserver enum, it might be more clear to move the measurements to a new histogram: "WebCore.ContentSecurityPolicy".

WDYT, Adam?

[Adam Barth]

One of the nice things about FeatureObserver is that it is normalized across all features (and a benchmark "feature").  Using a separate histogram loses that benefit.

It's unlikely that we'll be able to drop X-WebKit-CSP until CSP 1.1 is done, so this might be a bit premature.

[Mike West]

(In reply to comment #1)
> One of the nice things about FeatureObserver is that it is normalized across all features (and a benchmark "feature").  Using a separate histogram loses that benefit.

That's both a benefit and a drawback. I have the feeling that I'm cluttering an already diverse data set by adding another few items to the enum.

That said, I'm happy to add it there if it's the right place. That's why I'm asking. :)

> It's unlikely that we'll be able to drop X-WebKit-CSP until CSP 1.1 is done, so this might be a bit premature.

Quite true; dropping the prefixed header entirely is a long-term goal. Still, starting to measure relative uptake now gives us a baseline for later. It seems worthwhile.

[Mike West]

(In reply to comment #2)
> That's both a benefit and a drawback. I have the feeling that I'm cluttering an already diverse data set by adding another few items to the enum.

Related, I assume reordering the enum to put related items next to each other would be a Bad Thing™?

[Adam Barth]

Ok.  I wouldn't worry too much about cluttering up FeatureObserver.  That's what it is there for.  If we run out of bits, we can add 32 more.  :)

[Adam Barth]

> Related, I assume reordering the enum to put related items next to each other would be a Bad Thing™?

We can do that, but it makes it harder to read the data on the server for a while.  It's probably not worth the hassle at this point.  We'll want to clean it out at some point, and re-ordering might make sense then.

[Mike West]

Created attachment 171912 [details]
Patch

[Build Bot]

Comment on attachment 171912 [details]
Patch

Attachment 171912 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/14688072

[Peter Beverloo (cr-android ews)]

Comment on attachment 171912 [details]
Patch

Attachment 171912 [details] did not pass cr-android-ews (chromium-android):
Output: http://queues.webkit.org/results/14675080

[Mike West]

Created attachment 172023 [details]
Patch

[Peter Beverloo (cr-android ews)]

Comment on attachment 172023 [details]
Patch

Attachment 172023 [details] did not pass cr-android-ews (chromium-android):
Output: http://queues.webkit.org/results/14687787

[Mike West]

Created attachment 172038 [details]
Patch

[WebKit Review Bot]

Comment on attachment 172038 [details]
Patch

Clearing flags on attachment: 172038

Committed r133325: <http://trac.webkit.org/changeset/133325>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.