My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 155743: Need to be able to enable/disable loading of specific plug-ins based on internet/intranet detection
16 people starred this issue and may be notified of changes. Back to list
Reported by, Oct 14, 2012
UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.13 (KHTML, like Gecko) Chrome/24.0.1290.1 Safari/537.13

Steps to reproduce the problem:
With the recent spate of severe Java vulnerabilities, it’s looking like we will be forced to restrict the use of Java in our organisation to Intranet sites only while maintaining a whitelist of internet sites we trust to load the plug-in.  

Unlike IE, there is no way in Chrome to be able to handle this locally or centrally via GPO without putting the decision-making in the hands of the user by using “click to play”.   Reliance on click to play, I’m afraid is not an acceptable solution in our organisation. 

We would like to be able to configure Chrome to only load the Java plug-in (or any plugin for that matter) based on whether the site is detected as Intranet or Internet, as well as being able to manage a site specific exception white list.  

Could this perhaps be considered as a future feature? Many thanks.

What is the expected behavior?

What went wrong?

Did this work before? No 

Chrome version: 22.0.1229.94  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Oct 15, 2012
The "PluginsAllowedForUrls" and "PluginsBlockedForUrls" policies do what you describe. You can set the "DefaultPluginsSetting" to block all plugins and then whitelist the internal sites in "PluginsAllowedForUrls". Have a look at these policies' descriptions at

Does this cover your scenario or do you need something else?
Oct 15, 2012
@Joao. Not quite, that's too inflexible a setting. I'm looking to block specific plugin-ins from running on sites (or preferably within a zone such as Internet), and not block all plug-ins on all sites.

e.g. I want to be disable the Java plugin from running on all sites except for those detected as Intranet and ideally those too that match a set whitelist.  Thanks.   
Oct 18, 2012
So what's the suggested next step here? Thanks
Oct 25, 2012
@Ligi: Kindly please look into this issue.

Oct 25, 2012
This is a feature request. There are plans to consolidate the policy settings for extensions, content settings, and plugins to allow for finer-grained control over what versions are allowed to run, what sites stuff is allowed on, what permissions are granted (for extensions) etc. There's no ETA today because we're busy with other topics.

Cyrus, let's talk some more about the timeline for these features.
Labels: -Type-Bug Type-Feature
Oct 25, 2012
Thanks guys, appreciate this is a feature request but also happy to hear you had plans already.  It really is important for us in the enterprise to have a more granular degree of control over what's allowed to run on which sites and/or in which zones (Internet/Intranet) etc.  I know it would be better if we just ensure all plugins etc are up-to-date all the time, but as you would have guessed, that's easier said than done when legacy web apps and technology have a tendency to outstay their welcome!  Heck, we're even finding it tough right now to keep auto updates enabled for Chrome due to pressure!

I would be really interested to hear the kind of timelines we might be talking about once you've had your discussion.  Please keep me posted. Thanks.
Dec 15, 2012
Have you considered whether a force-installed extension (by policy) that uses the content settings API works for you until this is implemented?
Dec 15, 2012
@battre It may work as an interim solution, will need to investigate as well as see if we have someone capable of writing such an extension. Thanks.
Mar 10, 2013
(No comment was entered for this change.)
Labels: -Feature-Enterprise Cr-Enterprise
Mar 18, 2013
We've yet to investigate the extension solution.
@mnissler We really need the ability to whitelist a blacklisted plug-in based on specific URLs.  Any news on how the consolidation of policy settings for extensions, content settings, and plugins to allow for finer-grained control is going, which might allow us to do this?

As you'd expect the threat posed by Java is real and of a growing concern to most and such a feature if introduced in Chrome I'm sure will be lapped up by enterprise security admins.  In our case, unless we can find someone to develop an extension to do what Chrome doesn't do today, we're going to forced to disable Java in Chrome entirely and users will need to use IE instead.  A less then ideal option I'm sure you agree. :-(  Thanks. 

Mar 18, 2013
@wydmex: I certainly feel your pain and this is definitely on our radar. I'm not in a position to make promises at this point however.

Adding dconnelly@ who is active on the extensions management consolidation side of things.
Apr 26, 2013
@mnissler and @joaodasilva I don't want to speak too soon but it looks like we have perhaps cracked this via an unexpected combo of policies.
I say "unexpected" because between the various policy explanations, they do not (at least to me) suggest this is going to generate the behaviour we witness.   

To reproduce:

•	Specify a list of disabled plugins (DisabledPlugins) = Java*
•	Specify a list of enabled plugins (EnabledPlugins)= Java*

•	Block plugins on these sites (PluginsBlockedForUrls)= *
•	Allow plugins on these sites (PluginsAllowedForUrls)= [*.],, etc

1. Java is blocked on all sites barring those listed under PluginsAllowedForUrls
2. The running of other plugins such as Flash etc remains unaffected.

The key to making this work is to both disable AND enable Java via DisabledPlugins and EnabledPlugins

Is this a fluke, can you perhaps validate and confirm this as the correct behaviour?  If so perhaps it's worth while documenting to make it more obvious?


Apr 26, 2013
So you want to generally disable all plugins, but enable Java on a few select sites?

That'd probably be:


That should yield the same result as the configuration you describe (i.e. no plugins allowed with the exception of Java on, otherwise we have a bug ;)

Note that this approach doesn't work if you have a second plugin that you want to enable on a different set of sites.
Apr 26, 2013
@mnissler No, we just want to disable Java on all sites barring those we define.  We don't want to touch other plugins
Apr 26, 2013
But then, PluginsBlockedForUrls will block these other plugins everywhere, no?
Apr 26, 2013
The ultimate request here is to deal specifically with Java: 

* Java works only on white-listed sites 
* All other plugins work on all sites

The use of existing PluginsBlockedForUrls was just a potential workaround -- it would probably be better to just make a direct mechanism to allow a whitelist (and maybe a blacklist) for a SPECIFIC plugin. 

I unfortunately have one specialized Java app I use on my LAN, but otherwise would not even have Java installed due to the continuous security issues and the fact that it's generally unnecessary. I would love to just whitelist it for my one local site, and then otherwise use the rest of the internet normally (albeit with no Java) -- that is to say: with other plugins, like Flash, enabled.

Apr 26, 2013
We have recently expended a great deal of effort in identifying all business applications which use the browser plugin, and trying to corral Java use to just those applications/sites.  The latter has proved next to impossible.

At present time, only Safari's just-landed Java whitelist provides what we're hoping to achieve.
Apr 26, 2013
@mnissler re comment #15
I would have thought that too but no it doesn't...I've tested Silverlight and Flash and they continue to function everywhere else!

Apr 26, 2013
A simple domain policy exists for JavaScript.  It seems rather obvious to enable a similar functionality for extensions and plugins.  It is a significan risk that plugins are able to scan my email, bank details, product roadmaps on intranet sites, etc.  The imagination runs wild.
Apr 29, 2013
@wydmex: If done some quick testing and found you're missing the DefaultPluginsSettings policy in your configuration. You probably want to set DefaultPluginsSettings=2 (i.e. block) as well. Also, with the configuration in comment 13, I actually don't see plugins other than the single whitelisted one running. If you're seeing something different, can you elaborate on your configuration? Also, it'd help you could take a look at about:plugins and see which ones are grayed out (that indicates what DisabledPlugins applies to).

For background: DisabledPlugins and EnabledPlugins control whether Chrome is willing to load the plugin at all. DefaultPluginsSetting controls whether a plugin is available to web content for use or not (block, allow, click-to-play), and the PluginsAllowedForUrls and PluginsBlockedForUrls are overrides for DefaultPluginsSetting on a per-site basis.
Apr 29, 2013
@missler: If we set DefaultPluginsSettings=2 then I'm sure all plugins will be blocked and we certainly don't want this.  #12 (not #13) represents the only settings we've changed and their values as well as the resulting behaviour - which is exactly what we're after!  It seems though that the resulting behaviour is not what you'd expect!? Give it a try, see please if you can confirm the behaviour?

I guess what I'm suggesting here is there is perhaps some sort of logic bug with your policies.  However it's one we intend to take advantage of at least in the interim, so we can restrict the Java plugin to running on only sites we trust. ;-) 

FYI with these settings all plugins are under user(enable/disable)control, except for Java which reports: (Enabled by enterprise policy) and can't be disabled (but it's instantiation can be controlled on a per site basis) :-)
Apr 30, 2013
Gave it a quick try, and found that with your configuration in comment #12, all plugins do get blocked by default (except for the whitelisted domains). That's as expected. Here is what I did:

1. Configuration:
   "DisabledPlugins": [ "*Talk" ],
   "EnabledPlugins": [ "*Talk" ],
   "PluginsBlockedForUrls": [ "*" ],
   "PluginsAllowedForUrls": [ "[*.]" ],

2. Go to, site info says plugins are allowed by policy. Verify that the Talk plugin is active (i.e. chat settings confirm the plugin is loaded).

3. Go to, site info says plugins are blocked by policy, verify that the Talk plugin doesn't work (i.e. hangouts don't load).

4. Go to, site info says plugins are blocked by policy, find that the media player plugin doesn't load.

I guess you're seeing something else then? Would be good to get detailed repro instructions so we check whether what you're seeing is really a bug.
Apr 30, 2013

1. policy config created as per your own

2. The site info for reports "Plug-ins: Allowed by policy" and the talk plugin is active.

3. The site info for reports "Plug-ins: Blocked by policy" and the talk plugin is active. - No, not what I would expect either given your testing and what we've been seeing with Java.

4. The site info for reports "Plug-ins: Blocked by policy" yet the Windows Media Player plugin is active.

In addition, the site info for reports "Plug-ins: Blocked by policy" yet all plugins (Silverlight and Flash) except for Java are active!

If I now replace *Talk with Java* and [*.] with [*.] then:

1. The site info for reports "Plug-ins: Allowed by policy" and the Java plugin is active

2. The site info for "Plug-ins: Blocked by policy" and the Java plugin is blocked

3. The site info for and reports "Plug-ins: Blocked by policy" yet the talk plugin is active!

4. The site info for reports "Plug-ins: Blocked by policy" yet the Windows Media Player plugin is active!

5. The site info for reports "Plug-ins: Blocked by policy" yet all plugins (Silverlight and Flash) except for Java are active!

Now if I delete my Chrome profile and start afresh, the outcome is altogether different, in both sets of tests I see the behaviour you would expect.
Clearly then this looks to be an issue with how the policy settings influence (or not) the user's existing Chrome profile!   I don't believe it is a once off either as others have recreated the behaviour I have been seeing.

A new bug report needed perhaps? :-(

Apr 30, 2013
wydmex: Can you check your old profiles to see whether you have exceptions configured for the URLs where the plugins do run? Check chrome://settings/content#content, and click the "Manage Exceptions" button in the plugins section.
Apr 30, 2013
mnissler: Nothing untoward there barring a couple of extensions that serve up their own plugins.  See attached.
27.6 KB   View   Download
Apr 30, 2013
Another stab in the dark: Did you restart your browser after applying the policy? Maybe there's a problem with the plugin settings propagating to tabs?

Adding a few people since this is starting to look like a plugins/content settings issue.
Apr 30, 2013
mnissler: Yes we've been doing this, and also running gpupdate to ensure the settings are mirrored under HKCU\Software\Policies\Google\Chrome
Jul 2, 2013
@mnissler any news on this, it's been several months? Thanks.
Jul 2, 2013
I'm totally at a loss of explanations what you're seeing and I was never able to reproduce the behavior you describe.

To make progress and finally diagnose the issue, we'll have to find a way to reproduce the behavior you're seeing. Would you be willing to do any of the following:

a/ Recreate the problem, zip up the Profile folder and pass it on to us so we can try to reproduce
b/ Give us access to a life setup on which you recreated the problem (remote desktop?)

If you have better ideas, I'm all ears. Feel free to contact me via email if you'd rather not discuss details on the bug tracker.
Jul 2, 2013
@mnissler, I decided to run though your scenario in #22 again and substituted "*Talk" (Correct me if I'm wrong but the talk plugin is now dead and buried?) for Java* and "[*.]" for "[*.]" 
I validated the settings using Chrome://policy

On 2 separate machines both running Chrome 29 with different profiles I got different results:

Machine 1

1. Went to, site info says plugins are allowed by policy. Verified that the Java plugin loaded.

2. Went to, site info says plugins are blocked by policy. Verified that the Java plugin did not load. "Java(TM) is not allowed"

3. Went to, site info says plugins are blocked by policy YET the WMP plugin loads!

4. Went to, site info says plugins are blocked by policy YET all the plugins (Flash, Silverlight etc) EXCEPT for the Java plugins load!

Machine 2

1. Went to, site info says plugins are allowed by policy. Verified that the Java plugin loaded

2. Went to, site info says plugins are blocked by policy. Verified that the Java plugin did not load. "Java(TM) is not allowed"

3. Went to, site info says plugins are blocked by policy and the WMP plugin does not load!

4. Went to, site info says plugins are blocked by policy and none of the plugins load.

Machine 2 seems to represent the desired result.  It has a much newer profile than Machine 1.
I suspect if you round up a few folks to recreate the test scenario above, depending on the age of their profile you'll return a mixed bag of results.

All this aside the current Chrome plugin policies still don't give us the ability to block the Java plugin, yet allow it on specific sites only, but still allow all other plugins to run irrespective of site.
Jul 8, 2013
In my reproduction attempts, I still only get what you describe in #2. If there's any way for you to provide a copy of the Profile that doesn't work or otherwise give us access to it, that'd be great.

As stated above, we're working on improving the situation for extension right now and we'll eventually get to plugins as well.
Mar 31, 2014
Saswat: this bug requires a new policy to configure plugins similar to the one we're working on for extensions at issue 177351. Please prioritize.
Labels: Enterprise-Triaged
Jun 13, 2014
@Saswat, any news on this? Thanks.
Sign in to add a comment

Powered by Google Project Hosting