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?
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.
(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.
(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™?
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. :)
> 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.
Created attachment 171912 [details] Patch
Comment on attachment 171912 [details] Patch Attachment 171912 [details] did not pass win-ews (win): Output: http://queues.webkit.org/results/14688072
Comment on attachment 171912 [details] Patch Attachment 171912 [details] did not pass cr-android-ews (chromium-android): Output: http://queues.webkit.org/results/14675080
Created attachment 172023 [details] Patch
Comment on attachment 172023 [details] Patch Attachment 172023 [details] did not pass cr-android-ews (chromium-android): Output: http://queues.webkit.org/results/14687787
Created attachment 172038 [details] Patch
Comment on attachment 172038 [details] Patch Clearing flags on attachment: 172038 Committed r133325: <http://trac.webkit.org/changeset/133325>
All reviewed patches have been landed. Closing bug.