Define EnabledComponentUpdates group policy for the component updater.

components/policy/resources/policy_templates.json

Index: components/policy/resources/policy_templates.json
diff --git a/components/policy/resources/policy_templates.json b/components/policy/resources/policy_templates.json
index 1a3c36c9f5f642f0589c8ffb48c6cbc22bf8f82c..a8a61bb4b6495be193af1330920b7021372122a0 100644
--- a/components/policy/resources/policy_templates.json
+++ b/components/policy/resources/policy_templates.json
@@ -137,7 +137,7 @@
 #   persistent IDs for all fields (but not for groups!) are needed. These are
 #   specified by the 'id' keys of each policy. NEVER CHANGE EXISTING IDs,
 #   because doing so would break the deployed wire format!
-#   For your editing convenience: highest ID currently used: 341
+#   For your editing convenience: highest ID currently used: 342
 #
 # Placeholders:
 #   The following placeholder strings are automatically substituted:
@@ -8846,6 +8846,32 @@
       },
       'example_value': 'com.android.chrome.SupervisedUserProvider'
     },
+    {
+      'name': 'ComponentUpdates',
+      'type': 'group',
+      'caption': '''Configure component update options.''',
+      'desc': '''These policies affect the behavior of the component updater in <ph name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph>.''',
+      'policies': [
+        {
+          'name': 'EnabledComponentUpdates',

[Thiemo Nagel, 2016/08/19 10:38:29]

Please move "Enabled" to the end of the name to be consistent with the dominant
style.  Also it seems that the name doesn't properly capture the functionality
of the policy.  I'd suggest instead: BinaryComponentUpdatesEnabled

[Sorin Jianu, 2016/08/19 20:08:47]

Changed the name to match the style. 
We struggled with naming. The idea is that only a set of components are affected
by this policy and we could not find a qualifier that unambiguously describes
the scope of policy. Therefore, we prefer to leave the qualifier out and comment
more on the intention below. Would this work?

+          'type': 'main',
+          'schema': { 'type': 'boolean' },
+          'supported_on': ['chrome.*:54-', 'chrome_os:54-'],
+          'features': {
+            'dynamic_refresh': False,
+            'per_profile': False,
+          },
+          'example_value': True,
+          'id': 342,
+          'caption': '''Enables component updates in <ph name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph>.''',
+          'tags': [],
+          'desc': '''Enables component updates for all components in <ph name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph> when not set or set to True.
+
+          If set to False, then updates for binary components are disabled. Binary components include plugins and components containing executable code.
+          The updates for some components can't be disabled. These components are considered non-binary and they usually contain only data and no code.''',

[Thiemo Nagel, 2016/08/19 10:38:29]

"some components" sounds as if we were trying to hide something.  Could you
please qualify these more precisely or include at least a couple of examples? 
Also "usually" seems suspicious and imho requires more explanation.

[waffles, 2016/08/19 16:42:03]

I recommend that we instead drop every occurrence of "binary" here - whether a
component is binary or text is simply an artifact of its encoding, and isn't
really meaningful about what the component is/does and therefore whether we can
disable it or not. For example, we intend to continue shipping safe-browsing
data as a binary protocol buffer, even if this policy is true.

I don't think we have a future-proof one-word description of what components can
and can't be disabled, so I would rather leave all qualifiers out of the policy
name (just "ComponentUpdatesEnabled"), and write the description along the lines
of the following:

"If set to False, updates to components are disabled. However, some components
are exempt from this policy: updates to any component that does not contain
executable code or does not significantly alter the behavior of the browser will
not be disabled. Examples of such components include the certificate revocation
lists and safe browsing data."

There's still a weasel-word in here ("significantly" - what is significant?)
which gives us some flexibility in using our judgment about what components
should be affected by this policy (even if they contain executable code), but it
removes the false binary/text distinction.

[Sorin Jianu, 2016/08/19 20:08:47]

Done.

+        },
+      ],
+    },
   ],
   'messages': {
     # Messages that are not associated to any policies.