RAPPOR implementation

chrome/browser/prefs/pref_metrics_service.cc

Index: chrome/browser/prefs/pref_metrics_service.cc
diff --git a/chrome/browser/prefs/pref_metrics_service.cc b/chrome/browser/prefs/pref_metrics_service.cc
index 8b6f389f961c1d5cf0a3c24a9865c05651e721a3..0030632f86c31d636f137b11ff0d0501f56d7a79 100644
--- a/chrome/browser/prefs/pref_metrics_service.cc
+++ b/chrome/browser/prefs/pref_metrics_service.cc
@@ -22,6 +22,7 @@
 #include "chrome/common/chrome_switches.h"
 #include "chrome/common/pref_names.h"
 #include "components/browser_context_keyed_service/browser_context_dependency_manager.h"
+#include "components/rappor/rappor_service.h"
 #include "crypto/hmac.h"
 #include "net/base/registry_controlled_domains/registry_controlled_domain.h"
 
@@ -29,6 +30,15 @@ namespace {
 
 const int kSessionStartupPrefValueMax = SessionStartupPref::kPrefValueMax;
 
+const rappor::RapporParameters kHomePageRapporParameters = {
+    "Settings.HomePage", 16 /* Bloom filter size bytes */,

[Ilya Sherman, 2014/01/10 11:00:32]

Optional nit: One arg per line might be a little clearer.

[Steven Holte, 2014/01/14 00:47:54]

Done.

+    4 /* Bloom filter hash count */,
+    rappor::PROBABILITY_75 /* Fake data probability */,
+    rappor::PROBABILITY_50 /* Fake one probability */,
+    rappor::PROBABILITY_75 /* One coin probability */,
+    rappor::PROBABILITY_50 /* Zero coin probability */

[Ilya Sherman, 2014/01/10 11:00:32]

This is a lot of manual configuration.  Do all of these knobs really need to be
exposed, or can we just provide reasonable defaults for clients to use?

[Steven Holte, 2014/01/14 00:47:54]

We should have defaults for this eventually, but we don't have guidelines for
setting these yet.  I think that's something that will be easy to add as we add
additional metrics.

[Alexei Svitkine (slow), 2014/01/22 22:13:28]

This is one area that still concerns me. If the API is open to allow users to
specify their own values for these parameters, then I'm afraid that this may
compromise the guarnatees that the system is supposed to provide.

Specifically, could one come up with a set of values that would defeat the
design of the system that makes it privacy preserving? If so, then that's a bad
whole that I think we shouldn't expose by the API. Also, it's not just
mal-intent that I'm worried here - simply exposing this much complexity to
people adding metrics allows people to pick bad values by virtue of not
understanding the implications, etc.

I would strongly suggest defining "known-good" parameters in the component
itself and just having a set of enum values that's exposed through the API,
where each enum value maps to a set of parameters.

Separately, I'd also like to see some guidance provided from Ulfar for what
"acceptable" parameter ranges are and having strong validation to enforce this.

+};
+
 }  // namespace
 
 PrefMetricsService::PrefMetricsService(Profile* profile)
@@ -78,6 +88,8 @@ void PrefMetricsService::RecordLaunchPrefs() {
           "Settings.HomePageEngineType",
           TemplateURLPrepopulateData::GetEngineType(homepage_url),
           SEARCH_ENGINE_MAX);
+      g_browser_process->rappor_service()->RecordUrl(
+          kHomePageRapporParameters, homepage_url);
     }
   }