New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 906184 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Figure out behavior for user-installed extensions later becoming required by policy

Project Member Reported by rdevlin....@chromium.org, Nov 16

Issue description

See issue 894184 for an instance of this potentially happening.

In short, if a user installs an extension (e.g. from the webstore) and that extension is later required by policy, Chrome doesn't handle it well.

From https://bugs.chromium.org/p/chromium/issues/detail?id=894184#c70:

----

Looking forward to what the fix for this should be, it's not entirely clear what the desired end state is.  If a user has an INTERNAL (for the record, you can basically read "INTERNAL" as "regular user install") extension and then enterprise policy tries to force-install the same, then that extension should inherit the enterprise policy capabilities (e.g., not being uninstallable by the user, but also having access to private enterprise APIs, etc).  In many ways, it would be nice to "upgrade" any extension installed in this way to have the new manifest location.  Unfortunately, there are a few complications with this:
- Sometimes, the location on disk of the extension wouldn't be the same.
- Unclear if any other preferences associated with the extension would need to be updated.
- Might break extension state/assumptions.
- If the enterprise policy changed to make the extension not-force-installed, we would remove it (rather than "downgrading" it to INTERNAL again).

If we instead uninstalled the existing "internal" extension and then installed it again as a policy extension, then we can avoid the first 3 issues.  Unfortunately, this has another drawback of potentially conflicting with sync (e.g., we'd need to be sure to not push the deletion to sync).

I think that whatever we do here will probably end up being very complicated if we want to fully sane-ify the situation and account for all possible edge cases.

----

Revision ae9baf56cb8e788322298f8c6ca3f4776e8028c5 made this slightly better, but still has some drawbacks (as described in the CL).  We should determine what we want behavior here to be.

James, assigning to you to triage/track.  Nick, I think you'll probably have some opinions here from a corp policy perspective.  Drew, FYI (I think this is generally lower priority for you, since users won't typically be able to install arbitrary extensions, but there's always the possibility).
 
The suggestion of uninstalling the existing "internal" extension and then installing it again as a "policy" extension seems ideal.

This is both from a security perspective and a support perspective.

From a security perspective, we don't know what data the extension has stored / relies on before it was force installed (LocalStorage, IndexDB, ...).

Additionally, we wouldn't want to "upgrade" a locally unpacked extension or one that is sideloaded. Manifest keys for extensions are sometimes exposed on CWS if you download the CRX.

From a support perspective, as Devlin mentioned this reduces the concern that the extension gets into a broken state.
Overall, that sounds reasonable to me.  It will still be tricky, because we need to deal with fun edge cases like sync (we need to be sure to not uninstall the extension everywhere, just on that device).  It also means that if the extension is ever *removed* from policy, it will be uninstalled on the device.  That's probably okay, given the likelihood of that happening.  I'm a little more concerned about losing all local data for the extension without giving any notice or recourse to the user, but I don't know if there's anything reasonable we can do in that situation.  And maybe, since this would (by definition) only affect managed devices, it's okay?

jawag@, anyone else we should run this by?
Cc: goanuj@chromium.org
This seems reasonable to me as well. From the user's perspective, the extension would just silently switch to the policy-install state, right?

+anuj does this SGTY? Anyone else from the enterprise side we should loop in?

Assuming we decide to move forward, WDYT about including a bullet in enterprise release notes?

Sign in to add a comment