Disable metrics collection

[xsmile]

Idea

Inox apparently does not report any metrics to Google but they are collected nevertheless. This is the default behavior of chromium and it cannot be changed without altering the source.

For example calls to the UMAHISTOGRAM* macros or UserMetricsAction are all over the place and allow tracking of a wide variety of internal or user initiated processes.

The results can be visualized at chrome://histograms and chrome://user-actions.

Disabling the collections of metrics should increase privacy. In case the browser decides to send metrics back to Google, they will be empty. Besides, I can only imagine that it would result in an improved resource usage.

Details

Disabling the user metrics can be done by returning instantly in RecordComputedAction and eventually in AddActionCallback at base/metrics/user_metrics.cc. chrome://user-actions stays empty that way.

Disabling the histograms on the other hand is a bit more complicated. Most of them are enabled with UMAHISTOGRAM* macros in base/metrics/histogram_macros.h, however they are just a small subset of all calls. Replacing them with empty macros results in a lower histogram utilization but the rest is still active. Apart from that histograms are referenced in many different ways which makes it difficult to disable them as a whole. They seem to have one thing in common though: base/metrics/histogram{,_base}.cc. Instead it is possible to create a single dummy histogram with a static name and let all histograms reference it. Additionally methods to update histogram data can be disabled. This way hardly any resources are wasted.

However it is possible that such data may be usesful to the user for profiling purposes.

[Eloston]

However it is possible that such data may be usesful to the user for profiling purposes.

A command-line flag could be used to enable metrics collection (example). Though I'm not sure if the command-line is guarenteed to be parsed before the first histogram is loaded.

It would also be pretty neat if a chrome://flags option is added to enable or disable histogram collection. These flags are added to the parsed command-line options at a later time, so the same function call to check command-line flags can be used.

EDIT: An example of adding a chrome://flag can be found in the same patch I linked already.

[xsmile]

@Eloston: Histograms are identified by their name, e.g. AsyncDNS.ConfigChange. This patch basically does two things. It lets all histograms reference the name Dummy preventing the creation of others and it disables methods to increase histogram counters. Checking for the switch and keeping the original histogram name or changing it to Dummy shouldn't be a problem but I don't like the idea of checking it each time histogram data is changed. I couldn't find a good place to integrate such a command-line flag yet. Sorry for the late answer.

[Eloston]

If Histogram::Factory is initialized after chrome flags are loaded into the parsed command line flags, then the switch can be checked in the constructor of Histogram::Factory (by getting the command-line parser for the current process and checking the switch). This boolean value can be passed into a new constructor parameter of Histogram objects.

If Histogram::Factory is initialized before the chrome flags are loaded, then I can think of two lesser solutions:

• Check the switch every time a Histogram is created.
• Check the switch in ChromeBrowserMainParts::PreCreateThreads in chrome/browser/chrome_browser_main.cc (after flags are parsed), and then notify Histogram::Factory somehow.

Note that command-line flags passed directly into Chromium are available at the entrypoint of the process IIRC. loaded into the command-line flags parser at the entrypoint of the process essentially, IIRC.

EDIT: Clarifications.

[xsmile]

The flag works but I'm not really happy with the current solution for sparse_histogram.cc and user_metrics.cc and would rather keep metrics disabled permanently without the possibility to activate them.

[Eloston]

Hmm I see what you mean but I think what you have now is good enough. Nice work.

BTW, to be clear in my last post, the "chrome flags" I was referring to are options in chrome://flags. The "command-line flags passed directly into Chromium" are regular arguments passed into the entrypoint of the process.

[xsmile]

Added the feature flag. You are right, it is much more convenient.

[xsmile]

The latest changes are in the feature-metrics branch.