Added a trace option for whitewashing trace args against a known-PII-less list.

base/trace_event/trace_event_impl_constants.cc

Index: base/trace_event/trace_event_impl_constants.cc
diff --git a/base/trace_event/trace_event_impl_constants.cc b/base/trace_event/trace_event_impl_constants.cc
index ffeacff38316c006eb0d70fb157838c3b7afb91d..f48d612a447653fb3a8659137c3b7a99f18f451e 100644
--- a/base/trace_event/trace_event_impl_constants.cc
+++ b/base/trace_event/trace_event_impl_constants.cc
@@ -23,6 +23,13 @@ const TraceLog::InternalTraceOptions
     TraceLog::kInternalEchoToConsole = 1 << 3;
 const TraceLog::InternalTraceOptions
     TraceLog::kInternalRecordAsMuchAsPossible = 1 << 4;
+const TraceLog::InternalTraceOptions TraceLog::kInternalEnableArgsWhitelist =
+    1 << 5;
+
+const char* const TraceEvent::kEventArgsWhitelist[][2] = {

[Sami, 2015/04/09 14:46:45]

Maybe it's just me but it feels like this list should be part of the trace
config/filter?

[oystein (OOO til 10th of July), 2015/04/09 18:00:29]

The whitelist is essentially args we've manually vetted to not contain any PII,
I'm not sure if this can/should vary between traces?

[Sami, 2015/04/10 11:08:36]

I was just thinking that base/ seems like an odd place to hardcode this since if
effectively relies on global knowledge, but I don't feel too strongly about it.

+    {"toplevel", "*"},
+    {"__metadata", "thread_name"},
+    {NULL, NULL}};
 
 }  // namespace trace_event
 }  // namespace base