Allow one-time randomization in field trials to work even if metrics are disabled.

Allow one-time randomization in field trials to work even if metrics are  disabled.

Some field trials (such as an upcoming Instant trial) need to use one-time
randomization, which currently doesn't work if the user isn't opted in to
sending metrics. To make it work, provide a non-empty ID even if metrics are
disabled.

Field trials that used to be disabled because they had an empty ID will now be
enabled (i.e., they'll see a lot more users falling into their trial). I found
only one such trial (chrome/browser/trials/http_throttling_trial.cc). Joi: If
this is going to be a problem, let me know, and we can work something out (say
by reducing the experiment group probability for your trial).

Since we store the generated client ID in prefs, this means that anybody who
was formerly seeing an empty prefs::kMetricsClientID will now unexpectedly see
a valid ID. I found no other users of this pref, so this shouldn't be an issue.

Finally, note that if metrics are disabled, MetricsService::GetClientID() will
continue to return an empty string, so all users of that API (of whom there are
many) remain unaffected.

BUG=none
TEST=Ran unit_tests and many try bots.

[sreeram, 2011-07-13 21:04:33]

Please review.

[jar (doing other things), 2011-07-18 17:33:49]

Please correct me if I misinterpreted the comment and intent.

http://codereview.chromium.org/7360001/diff/6001/chrome/browser/browser_main.cc
File chrome/browser/browser_main.cc (right):

http://codereview.chromium.org/7360001/diff/6001/chrome/browser/browser_main....
chrome/browser/browser_main.cc:276: // randomization. The client ID will not be
empty even if the user has not
This appears problematic from a privacy perspective... if I understand the
comment.

We had a lot of feedback from privacy groups indicating that we absolutely
should NOT tag a user with a unique ID if we are not going to send data via UMA.
 At one point, a special non-Google version of Chromium started to become
popular with its central "feature" being that it trashed this value.

Bottom line: If the user opts out of the UMA upload, we don't want to set a
persistent tag in the profile.  Yes, it is true, that we won't use it.... but it
is considered undesirable.

[sreeram, 2011-07-18 17:38:59]

Ouch. Okay, looks like this CL is a non-starter, then. I'll withdraw it.

On Mon, Jul 18, 2011 at 10:33,  <jar@chromium.org> wrote:
> Please correct me if I misinterpreted the comment and intent.
>
>
>
http://codereview.chromium.org/7360001/diff/6001/chrome/browser/browser_main.cc
> File chrome/browser/browser_main.cc (right):
>
>
http://codereview.chromium.org/7360001/diff/6001/chrome/browser/browser_main....
> chrome/browser/browser_main.cc:276: // randomization. The client ID will
> not be empty even if the user has not
> This appears problematic from a privacy perspective... if I understand
> the comment.
>
> We had a lot of feedback from privacy groups indicating that we
> absolutely should NOT tag a user with a unique ID if we are not going to
> send data via UMA.  At one point, a special non-Google version of
> Chromium started to become popular with its central "feature" being that
> it trashed this value.
>
> Bottom line: If the user opts out of the UMA upload, we don't want to
> set a persistent tag in the profile.  Yes, it is true, that we won't use
> it.... but it is considered undesirable.
>
> http://codereview.chromium.org/7360001/
>