michaelsamuel@ Could you please provide any sample extension to test this issue from Chrome-TE end.

Thanks!

I created a basic extension ID jndopnbadbiahpmbnfadmmadjhpjbmon that does this.

Some further testing shows that this only happens if the extension was removed by blacklisting after it was already installed.  It is very hard to remove the settings once this happens...

Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hi all,
I tried the following scenario to test the possibility of having an extension (B) observing changes to proxy settings and overriding them:
1. Ext A sets the proxy,
2. Ext B sees that change and tries to reset the proxy.

Unfortunately, the resulting proxy is the one set after #1 by Ext A. I repeated the test several times to make sure I'm not doing something stupid and it seems to hold.

IIUC...
When an extension sets a proxy, this information is stored in that extension's preferences (PreferenceAPIBase::SetExtensionControlledPref). When Chrome loads, it looks through preferences to find preferences that are controlled by extensions (ExtensionPrefs::InitExtensionControlledPrefs). This includes the proxy information saved in the extension's preferences. If an extension is marked as disabled or blacklisted in its preferences, its proxy information is skipped. 

When an enterprise blocks an extension, they add the extension ID to the ExtensionInstallBlacklist policy. This policy is enforced in StandardManagementPolicyProvider::UserMayLoad which overrides ManagementPolicy::UserMayLoad. Which is called from ExtensionService::CheckManagementPolicy. The issue is that when an extension is blocked by UserMayLoad in the CheckManagementPolicy, no extension preference is updated. This means that ExtensionPrefs considers the extension as enabled and will use its extension control preferences (e.g. proxy data) regardless of whether its on the blacklist.

There probably should to be a linkage between an extension load being denied by UserMayLoad and the ExtensionPrefs::.

If a user has an extension enabled that is added to the ExtensionInstallBlacklist policy while Chrome is running the extension should be unloaded. However we get the same issue as before where the proxy settings aren't ignored. If we disable the extension however the proxy settings would be removed.

I modified a local build of Chrome to set an extension as disabled when it failed the UserMayLoad check in InstalledLoader, and in ExtensionSettings. This seemed to fix the problem. I tested this with the extension michaelsamuel@ uploaded to CWS (extension appears to be restricted to @google.com). This may not be the ideal way to fix the bug, so I'll leave that up to the extension team to decide.

This may be affecting all other extension controlled preferences as well. I'd suggest that we confirm this bug and consider this a P1 since this is a security control. Bibin, can we get an owner assigned for this bug please?

Is there any other information you need to triage this? Can we get an estimate on when this will go to "Available"?

This explains an external request I recently came upon on the admin forum.

https://productforums.google.com/forum/#!topic/chrome-admins/beRTuBaR8iw

I thought the user was having some other issue but reading this bug it seems like he was hitting this issue. It does sound pretty bad to me and. 

It also sounds like a security/privacy relevant issue to me so adding the security label to it too for broader visibility.

Hey Devlin, can you please have a look at this issue? I would like to reply something to the admin forum about this.

Thanks! :)

Friendly Ping

triage!  karandeepb@, do you think you could look into this?

Regarding proper behavior, I think that the most logical thing to do here is have the proxy setting in effect iff the extension is loaded (since loaded essentially means "can be running").  This way, the setting is not in effect when the extension is unloaded or disabled.  I think we should address any oddness in policy blacklisting effects separately.

Will take a look.

Friendly ping, its been 2+ weeks. Is there anything I can do to help move this forward?

On it. I came to similar conclusions as yours in c#6. Basically in CheckManagementPolicy, for the list of extensions to unload, we don't remove their preferences. 

An extension can be enabled, disabled, blacklisted, greylisted, but the extensions unloaded due to change in management policy, do not clearly fall into any of these buckets. We can't also simply just delete the extension preferences for our case, since this causes some tests to fail (We currently expect that we should be able to reload unloaded extensions, which means their preferences should stay intact).

Will think about it a bit more and issue a patch soon.

Thanks for looking into this karandeepb@. Please let me know if there is any additional info needed.

CL: https://chromium-review.googlesource.com/c/599390

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2a1172308ad040e0d6abb2f20b824f5fef92ca68

commit 2a1172308ad040e0d6abb2f20b824f5fef92ca68
Author: Karan Bhatia <karandeepb@chromium.org>
Date: Wed Aug 23 00:24:56 2017

Extensions: Change how ManagementPolicy::UserMayLoad is handled.

Currently when an enabled extension is blocked by ManagementPolicy::UserMayLoad,
it is unloaded without its preferences being removed. Also, ExtensionPrefs shows
the state of such extensions as enabled. This can lead to bugs where unloaded
policy blacklisted extensions can have side-effects. Also,
ManagementPolicy::UserMayLoad is not checked while enabling a disabled
extension. This can cause blacklisted extensions to become enabled.

This CL brings the following changes:
  - A new disabled reason DISABLE_BLOCKED_BY_POLICY is introduced.
  - When an enabled extension fails ManagementPolicy::UserMayLoad, it is
    disabled with DISABLE_BLOCKED_BY_POLICY.
  - Hence extensions which fail UserMayLoad checks are now visible to the user 
    on chrome://extensions page, instead of silently remaining installed.
  - They are re-enabled automatically when they satisfy the policy. 
  - ManagementPolicy::MustRemainDisabled also checks
    ManagementPolicy::UserMayLoad now. This leads to cleaner code at call sites
    and helps avoid inconsistent checking of the management policy.
  - Some cases in which disabled policy blacklisted extensions could be 
    re-enabled are fixed.

BUG= 709264 ,  754448 , 461747
TEST=Install EvilProxy (https://chrome.google.com/webstore/detail/evilproxy/jndopnbadbiahpmbnfadmmadjhpjbmon). 
Ensure navigating to tools.google.com causes a 404. Add the extension to policy
blacklist. Ensure navigating to tools.google.com works fine. Restart browser. 
Ensure navigating to tools.google.com works fine.
TEST=Install EvilProxy. Ensure navigating to tools.google.com causes a 404. 
Close browser. Add the extension to policy blacklist. Start browser. Ensure 
navigating to tools.google.com works fine. 
TEST=Install EvilProxy. Add the extension to policy blacklist. Close browser.
Remove extension from policy blacklist. Start browser. Ensure navigating to 
tools.google.com causes a 404.
TEST=Install EvilProxy. Add the extension to policy blacklist. Ensure navigating
to tools.google.com works fine. Remove extension from policy blacklist. Ensure
navigating to tools.google.com causes a 404.
TEST=Install EvilProxy. Disable the extension from chrome://extensions page. Add
it to policy blacklist. Ensure it can't be enabled from chrome://extensions.

Change-Id: Ia25d7a2a49bd1c006a435c26397c834ffa5ae632
Reviewed-on: https://chromium-review.googlesource.com/611662
Commit-Queue: Karan Bhatia <karandeepb@chromium.org>
Reviewed-by: Ilya Sherman <isherman@chromium.org>
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#496521}
[modify] https://crrev.com/2a1172308ad040e0d6abb2f20b824f5fef92ca68/chrome/browser/extensions/api/proxy/proxy_apitest.cc
[modify] https://crrev.com/2a1172308ad040e0d6abb2f20b824f5fef92ca68/chrome/browser/extensions/crx_installer_browsertest.cc
[modify] https://crrev.com/2a1172308ad040e0d6abb2f20b824f5fef92ca68/chrome/browser/extensions/extension_service.cc
[modify] https://crrev.com/2a1172308ad040e0d6abb2f20b824f5fef92ca68/chrome/browser/extensions/extension_service_sync_unittest.cc
[modify] https://crrev.com/2a1172308ad040e0d6abb2f20b824f5fef92ca68/chrome/browser/extensions/extension_service_unittest.cc
[modify] https://crrev.com/2a1172308ad040e0d6abb2f20b824f5fef92ca68/chrome/browser/extensions/extension_sync_service.cc
[modify] https://crrev.com/2a1172308ad040e0d6abb2f20b824f5fef92ca68/chrome/browser/extensions/extension_util.cc
[modify] https://crrev.com/2a1172308ad040e0d6abb2f20b824f5fef92ca68/chrome/browser/extensions/installed_loader.cc
[modify] https://crrev.com/2a1172308ad040e0d6abb2f20b824f5fef92ca68/chrome/browser/policy/policy_browsertest.cc
[modify] https://crrev.com/2a1172308ad040e0d6abb2f20b824f5fef92ca68/components/policy/resources/policy_templates.json
[modify] https://crrev.com/2a1172308ad040e0d6abb2f20b824f5fef92ca68/extensions/browser/management_policy.cc
[modify] https://crrev.com/2a1172308ad040e0d6abb2f20b824f5fef92ca68/extensions/browser/management_policy.h
[modify] https://crrev.com/2a1172308ad040e0d6abb2f20b824f5fef92ca68/extensions/common/disable_reason.h
[modify] https://crrev.com/2a1172308ad040e0d6abb2f20b824f5fef92ca68/extensions/common/manifest_constants.cc
[modify] https://crrev.com/2a1172308ad040e0d6abb2f20b824f5fef92ca68/extensions/common/manifest_constants.h
[modify] https://crrev.com/2a1172308ad040e0d6abb2f20b824f5fef92ca68/tools/metrics/histograms/enums.xml
[modify] https://crrev.com/2a1172308ad040e0d6abb2f20b824f5fef92ca68/tools/metrics/histograms/histograms.xml

Now that this fix has been committed are we safe to close this bug or do we leave it open until it hits stable?

Confirmed that the fix works fine on Linux dev.