Use kMetricsReportingEnabled instead of kStatsReporingPref on metrics side

chrome/browser/chromeos/login/wizard_controller.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "chrome/browser/chromeos/login/wizard_controller.h"
 
 #include <signal.h>
 #include <stdlib.h>
 #include <sys/types.h>
 
@@ skipping 591 matching lines @@
 
   if (skip_update_enroll_after_eula_) {
     PerformPostEulaActions();
     ShowAutoEnrollmentCheckScreen();
   } else {
     InitiateOOBEUpdate();
   }
 }
 
 void WizardController::InitiateMetricsReportingChangeCallback(bool enabled) {
-  CrosSettings::Get()->SetBoolean(kStatsReportingPref, enabled);

[Mattias Nissler (ping if slow), 2015/10/20 08:33:32]

Why did you remove this? I think this is required to store the device setting
for consumer devices during OOBE.

[gayane -on leave until 09-2017, 2015/10/20 14:55:39]

Previously here we set kStatsReportingPref as InitiateMetricsReportingChange was
not taking care of that. But now above in OnEulaAccepted()
InitiateMetricsReportingChange function is called which will set
kMetricsReportingEnabled to be usage_statistics_reporting_. 

This function is a callback afterwards which will start crashreporter if needed.

[Mattias Nissler (ping if slow), 2015/10/21 09:53:24]

AFAICT, InitiateMetricsReportingChange only updates local_state. This
insufficient on Chrome OS, where settings affecting all users on the device
should be stored in device_settings, to prevent non-owners to mess with these
settings.

[Alexei Svitkine (slow), 2015/10/21 16:36:53]

Can we just guard against this (non-owners of the device messing with the
setting) from Chrome code and not have the extra device setting?

[gayane -on leave until 09-2017, 2015/10/21 17:02:51]

Is there any way for users to change the settings other than UI?

For UI I disable the checkbox for non-owner. See
BrowserOptionsHandler::IsMetricsReportingOwnerManaged()

[Mattias Nissler (ping if slow), 2015/10/21 19:05:48]

The deal with device settings is that they're carrying a cryptographic signature
to prevent non-owner users on the device from changing them. Storing in
local_state would subverts that, even if there is no regular way to manipulate
the value through the UI. The goal is to contain damage for other users even
when one user's session gets attacked and Chrome gets compromised.

I therefore suggest you keep the device setting as the ground truth on Chrome OS
for all cases. If you want to use the local state pref as a vehicle for
communicating the value to/from UI and/or the metrics subsystem, that's fine -
but make sure we're not making decisions based on that originates from the
local_state file but sync it on startup to what the device setting says.

   if (!enabled)
     return;
 #if defined(GOOGLE_CHROME_BUILD)
   if (!content::BrowserThread::PostBlockingPoolTask(
           FROM_HERE, base::Bind(&InitializeCrashReporter))) {
     LOG(ERROR) << "Failed to start crash reporter initialization.";
   }
 #endif
 }
 
@@ skipping 694 matching lines @@
   }
 
   EnrollmentScreen* screen = EnrollmentScreen::Get(this);
   screen->SetParameters(effective_config, shark_controller_.get(),
                         remora_controller_.get());
   SetStatusAreaVisible(true);
   SetCurrentScreen(screen);
 }
 
 }  // namespace chromeos