RAPPOR implementation

chrome/browser/metrics/metrics_log.cc

Index: chrome/browser/metrics/metrics_log.cc
diff --git a/chrome/browser/metrics/metrics_log.cc b/chrome/browser/metrics/metrics_log.cc
index b95c0e1249babbfac117b25a454ec327c5b82185..017e273e7de230cf7338df58d61248c1aaca4af1 100644
--- a/chrome/browser/metrics/metrics_log.cc
+++ b/chrome/browser/metrics/metrics_log.cc
@@ -29,6 +29,7 @@
 #include "chrome/browser/autocomplete/autocomplete_result.h"
 #include "chrome/browser/browser_process.h"
 #include "chrome/browser/google/google_util.h"
+#include "chrome/browser/metrics/rappord.h"
 #include "chrome/browser/omnibox/omnibox_log.h"
 #include "chrome/browser/plugins/plugin_prefs.h"
 #include "chrome/browser/profiles/profile_manager.h"
@@ -784,6 +785,10 @@ void MetricsLog::RecordEnvironmentProto(
   GetFieldTrialIds(&field_trial_ids);
   WriteFieldTrials(field_trial_ids, system_profile);
 
+  std::string bloom_filter_bits;
+  GetBloomFilterBits(&bloom_filter_bits);
+  WriteBloomFilterBits(bloom_filter_bits, system_profile);
+
 #if defined(OS_CHROMEOS)
   PerfDataProto perf_data_proto;
   if (perf_provider_.GetPerfData(&perf_data_proto))
@@ -800,6 +805,35 @@ void MetricsLog::RecordEnvironmentProto(
 #endif
 }
 
+void MetricsLog::GetBloomFilterBits(std::string* bloom_filter_bits) {

[Steven Holte, 2013/10/28 21:02:44]

This should probably be split into 4 parts:

A function for adding a collected value to the PPRR, a function for encoding the
PPRRs into the proto buf, a utility for breaking the URLs into bits for the
PPRR, and the actual collection of homepage.  Any suggestions about where each
of those should live?

[Ilya Sherman, 2013/10/29 00:32:31]

If you're intending to provide something of a parallel architecture to the
histograms architecture, then you'll probably want the code for "adding a
collected value to the PPRR" to live in //base/metrics.  Encoding the collected
values into the protocol buffer makes sense to keep in metrics_log.cc, most
likely in the anonymous namespace.  Breaking URLs into bits should probably be
an internal implementation detail for logging values to the code that lives in
//base/metrics.  The collection of the homepage should be done by whatever
feature code interacts with setting the homepage, though depending on when this
is meant to be recorded, there might need to be a call into that code from the
MetricsLog or from the MetricsService.

+  PrefService* pref_service = GetPrefService();
+
+  typedef RappordBloomFilter<128, 4, -4, 2, -4> rappord_t;
+  rappord_t rap(1, pref_service->GetString(prefs::kMetricsSecretClientID));
+
+  // std::string homepageurl = pref_service->GetString(prefs::kHomePage);
+  std::string homepageurl = "http://www.google.com/foo?bar";
+  std::vector<std::string> strs;
+  GURL gurl(homepageurl);
+
+  strs.push_back(homepageurl);
+  strs.push_back(gurl.spec());
+  strs.push_back(gurl.host());
+  // TODO(holte) break up host more
+  strs.push_back(gurl.query());
+  strs.push_back(gurl.path());
+  // strs.push_back(gurl.ref());
+
+  const rappord_t::bitmap_t bits = rap.get(strs);
+  *bloom_filter_bits = bits.to_string();
+}
+
+void MetricsLog::WriteBloomFilterBits(
+      const std::string& bloom_filter_bits,
+                            SystemProfileProto* system_profile) {
+  system_profile->set_bloom_filter_bits(bloom_filter_bits);
+}
+
 void MetricsLog::RecordProfilerData(
     const tracked_objects::ProcessDataSnapshot& process_data,
     int process_type) {