[Policy Experimental] Add policies to allow Cookies and Pop-ups exceptions.

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 45006a30e2ede3db2772a3e13f57fabf2f7a6398..cf88a67555f5fccf08544492834e17a9b8966e43 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: 325
+#   For your editing convenience: highest ID currently used: 328
 #
 # Placeholders:
 #   The following placeholder strings are automatically substituted:
@@ -3144,6 +3144,76 @@
           If this policy is left not set, 'BlockKeygen' will be used and the user will be able to change it.''',
         },
         {
+          'name': 'PrefExceptionsUsageCookies',

[bartfab (slow), 2016/04/07 14:39:29]

Here and for the other policy: This name is very cryptic. How about something
like "AllowCookiesSettingExceptions"?

[huangs, 2016/04/07 21:44:07]

"Pref" (or some synonym; "user"?) is essential because this switch controls the
role of PREF_PROVIDER exceptions.  "Allow" would be nice to use, but this can
get entangled with CONTENT_SETTING_ALLOW.  I put "Cookies" at an inconsistent
place, so it should be moved.  "Settings" is too generic, since exceptions list
is also settings.  I think "Usage" would be descriptive of what this is.

So perhaps "UserCookiesExceptionsUsage"?  I'm going to change throughout, but
still open to suggestions.

[bartfab (slow), 2016/04/08 10:17:30]

You can use "Permit" or "Honor" -> "HonorCookiesSettingExceptions"

[huangs, 2016/04/08 13:39:12]

I like "Permit"; will do that in the next update.  "Not Honor" sounds too
negative (and Worf-esque :).

+          'type': 'int-enum',

[bartfab (slow), 2016/04/07 14:39:29]

Here and for the other policy: Do we expect to ever have more than these two
options? If not, a Boolean will do.

[huangs, 2016/04/07 21:44:07]

This makes it easier to extend in future, e.g., allow exceptions, but not
wildcards.

+          'schema': {
+            'type': 'integer',
+            'enum': [ 1, 2 ],
+          },
+          'items': [
+            {
+              'name': 'AllowCookiesPrefExceptions',

[bartfab (slow), 2016/04/07 14:39:29]

Here and for the other policy: Nit: Content policies use the term "Setting," not
"Pref."

[huangs, 2016/04/07 21:44:07]

Please see comment above?

+              'value': 1,
+              'caption': '''Allow users to specify cookies exceptions''',
+            },
+            {
+              'name': 'BlockCookiesPrefExceptions',
+              'value': 2,
+              'caption': '''Do not allow users to specify cookies exceptions''',

[Bernhard Bauer, 2016/04/07 15:30:13]

So, this would apply even if no policy sets the default cookies value? Because
otherwise, this would be covered by the not-set case anyway.

[huangs, 2016/04/07 21:44:07]

In this case user defaults (DEFAULT_PROVIDER) will be a catch-all; admin cannot
disable that.

Stepping back, BlockCookiesPrefExceptions might be a bizarre feature that nobody
wants (I added it for symmetry when copying existing patterns).  We can sort
this out in design, now that we have more time.  :)

[Bernhard Bauer, 2016/04/08 14:44:35]

Yes... I think this isn't very useful, because if the admin wants to apply the
default setting with no way for the user to override it, they could just
explicitly set the default setting and don't set this policy.

I also think removing this option would allow more simplifications in the rest
of the CL -- for example, we wouldn't need the tri-state return value in
GetUserExceptionsUsageSettingForType() anymore.

[huangs, 2016/04/11 19:01:03]

Sounds good, I'll remove the option.

We still have to hear back whether wildcards is a concern.  If so then we would
add "Allow non-wildcard only option".  If not then we can change type from
"int-enum" to "boolean" (assuming we won't need to handle "different types of
permission" in the future and would need to migrate).

+            },
+          ],
+          'supported_on': [
+            'chrome.*:51-',
+            'chrome_os:51-',
+          ],
+          'features': {
+            'dynamic_refresh': True,
+            'per_profile': True,
+          },
+          'example_value': 1,
+          'id': 327,
+          'caption': '''Pref exceptions cookies setting''',
+          'tags': [],
+          'desc': '''Allows you to specify whether users can set exceptions to override default cookies policy.
+
+          If this policy is left not set, user's ability to set exceptions depends on the default cookies setting.''',

[bartfab (slow), 2016/04/07 14:39:29]

Here and for the other policy: What are you referring to here? I cannot find
anything in the documentation of the default cookies setting that would tell me
when exceptions are/are not allowed.

[huangs, 2016/04/07 21:44:07]

Depends on DefaultCookiesSetting.  For exceptions, there are "policy exceptions"
and "user exceptions" (AKA "pref exceptions", owing to PREF_PROVIDER).  We're
want to choose to (1) keep old behavior, (2) elevate "user exceptions" over
"policy default", (3) disable "user exceptions".

[bartfab (slow), 2016/04/08 10:17:30]

But those policy exceptions come from a different policy, not from the "default
cookies setting."

[huangs, 2016/04/08 13:39:12]

Yes, this is a "meta"-setting that makes Policy settings aware of User settings
(and the layered nature of the system) hence the extra complexity.  Also, this
is a knob that's Policy-only and not controllable by User.  The consequence is
(unless we do the hole-poking approach) need to abstract the current
ProviderType-ordered approach.  Are there other concerns that might arise from
this?

[bartfab (slow), 2016/04/11 10:27:31]

My concern is that I do not understand "user's ability to set exceptions depends
on policy default cookies setting." Assume this policy is unset. The
DefaultCookiesSetting policy could take on four different values (unset,
AllowCookies, BlockCookies, SessionOnly). Which of those permit exceptions?
Which do not? How would I know? There does not seem to be any documentation
describing this case.

[huangs, 2016/04/11 19:01:03]

unset => Permit user exceptions by default.
AllowCookies => Block user exceptions by default. New switch allows user
exceptions.
BlockCookies => Block user exceptions by default. New switch allows user
exceptions.
SessionOnly => Block user exceptions by default. New switch allows user
exceptions.

Will write the design doc.  Part of this project also involves updating online
documentation, but let's worry about that after the feature is in.

+        },
+        {
+          'name': 'PrefExceptionsUsagePopups',
+          'type': 'int-enum',
+          'schema': {
+            'type': 'integer',
+            'enum': [ 1, 2 ],
+          },
+          'items': [
+            {
+              'name': 'AllowPopupsPrefExceptions',
+              'value': 1,
+              'caption': '''Allow users to specify pop-ups exceptions''',
+            },
+            {
+              'name': 'BlockPopupsPrefExceptions',
+              'value': 2,
+              'caption': '''Do not allow users to specify pop-ups exceptions''',
+            },
+          ],
+          'supported_on': [
+            'chrome.*:51-',
+            'chrome_os:51-',
+          ],
+          'features': {
+            'dynamic_refresh': True,
+            'per_profile': True,
+          },
+          'example_value': 1,
+          'id': 328,
+          'caption': '''Pref exceptions pop-ups setting''',
+          'tags': [],
+          'desc': '''Allows you to specify whether users can set exceptions to override default pop-ups policy.
+
+          If this policy is left not set, user's ability to set exceptions depends on the default pop-ups setting.''',
+        },
+        {
           'name': 'AutoSelectCertificateForUrls',
           'type': 'list',
           'schema': {