chrome.contentSettings API: Block patterns that match extension URLs for mic and video

chrome/browser/extensions/api/content_settings/content_settings_api.cc

Index: chrome/browser/extensions/api/content_settings/content_settings_api.cc
diff --git a/chrome/browser/extensions/api/content_settings/content_settings_api.cc b/chrome/browser/extensions/api/content_settings/content_settings_api.cc
index c63d8f45e015fc794c3b8d4ccf7e9ed7c85be237..51e795481ab3848523cd0944a7f7b29c069ca747 100644
--- a/chrome/browser/extensions/api/content_settings/content_settings_api.cc
+++ b/chrome/browser/extensions/api/content_settings/content_settings_api.cc
@@ -214,8 +214,11 @@ ContentSettingsContentSettingSetFunction::Run() {
   // some values might not be supported.
   // For example, camera supports [allow, ask, block] for exceptions, but only
   // [ask, block] for the default setting.
-  if (primary_pattern == ContentSettingsPattern::Wildcard() &&
-      secondary_pattern == ContentSettingsPattern::Wildcard() &&
+  // Also, do not allow wildcard patterns that match chrome-extension URLs.

[Devlin, 2017/03/02 21:55:02]

I don't know if this is desirable.  What if I have an extension that manages my
content settings and I want it to be able to restrict what other extensions can
do?

[meacer, 2017/03/07 20:50:38]

Note that this CL only changes behavior for microphone and video permissions.

But besides that, adding chrome-extension patterns currently doesn't work
either. I also don't think we should allow them unless we go around and divide
contentSettings API into two (one that can only downgrade permissions and one
that can do everything).

Otherwise, an extension can similarly grant all these permissions to other
extensions. Also, our stance has been that one extension shouldn't be able to
tamper with another extension and this seems consistent with that.

+  if (((primary_pattern.MatchesExtensionUrls() &&
+        secondary_pattern.MatchesExtensionUrls()) ||

[Devlin, 2017/03/02 21:55:02]

Some settings don't have a secondary url, or don't always consider it.  Those
would never be taken into account since the pattern wouldn't match extension
urls.

[meacer, 2017/03/07 20:50:38]

I added the secondary pattern for consistency with the wildcard check. The
secondary pattern seems to be used for iframes by most permissions, and for
subresources by cookies.

The scenario this prevents is as follows: Extension A grants permissions to
extension B by adding it as a secondary pattern, then iframes it (if extension B
has a web accessible resource), then communicates with it. That way extension A
will be able to use granted permissions itself, if extension B cooperates.

+       (primary_pattern == ContentSettingsPattern::Wildcard() &&
+        secondary_pattern == ContentSettingsPattern::Wildcard())) &&
       !HostContentSettingsMap::IsDefaultSettingAllowedForType(setting,
                                                               content_type)) {
     static const char kUnsupportedDefaultSettingError[] =