Bug 100974 - Measure the usage of the various CSP headers.
Summary: Measure the usage of the various CSP headers.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Mike West
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-01 11:31 PDT by Mike West
Modified: 2012-11-02 11:55 PDT (History)
4 users (show)

See Also:


Attachments
Patch (3.60 KB, patch)
2012-11-01 12:44 PDT, Mike West
no flags Details | Formatted Diff | Diff
Patch (3.73 KB, patch)
2012-11-02 03:25 PDT, Mike West
no flags Details | Formatted Diff | Diff
Patch (3.80 KB, patch)
2012-11-02 04:52 PDT, Mike West
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mike West 2012-11-01 11:31:35 PDT
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?
Comment 1 Adam Barth 2012-11-01 11:35:47 PDT
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.
Comment 2 Mike West 2012-11-01 11:43:20 PDT
(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.
Comment 3 Mike West 2012-11-01 11:44:15 PDT
(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™?
Comment 4 Adam Barth 2012-11-01 11:45:17 PDT
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.  :)
Comment 5 Adam Barth 2012-11-01 11:46:47 PDT
> 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.
Comment 6 Mike West 2012-11-01 12:44:44 PDT
Created attachment 171912 [details]
Patch
Comment 7 Build Bot 2012-11-01 13:40:50 PDT
Comment on attachment 171912 [details]
Patch

Attachment 171912 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/14688072
Comment 8 Peter Beverloo (cr-android ews) 2012-11-01 14:11:46 PDT
Comment on attachment 171912 [details]
Patch

Attachment 171912 [details] did not pass cr-android-ews (chromium-android):
Output: http://queues.webkit.org/results/14675080
Comment 9 Mike West 2012-11-02 03:25:59 PDT
Created attachment 172023 [details]
Patch
Comment 10 Peter Beverloo (cr-android ews) 2012-11-02 03:46:02 PDT
Comment on attachment 172023 [details]
Patch

Attachment 172023 [details] did not pass cr-android-ews (chromium-android):
Output: http://queues.webkit.org/results/14687787
Comment 11 Mike West 2012-11-02 04:52:12 PDT
Created attachment 172038 [details]
Patch
Comment 12 WebKit Review Bot 2012-11-02 11:55:09 PDT
Comment on attachment 172038 [details]
Patch

Clearing flags on attachment: 172038

Committed r133325: <http://trac.webkit.org/changeset/133325>
Comment 13 WebKit Review Bot 2012-11-02 11:55:14 PDT
All reviewed patches have been landed.  Closing bug.