Google-chrome – Get a list of installed chrome extensions

There are really only a couple of options open to you as the ability to run the extensions has been programatically disabled with no plans to re-enable it (or at least none made public)

You can try installing from the canary channel or the developer channel releases which may allow you to still run these extensions as mentioned in Google Chrome help forum:

What if I want to run non-web store extensions?

Advanced users can continue to use our Dev & Canary channels to run any extension. Please note that these channels are updated very regularly, and may contain features and bug fixes that are actively being developed.

Alternatively, I have heard that quite a few people install Tampermonkey which then allows the running of user scripts.

Might be worth a look.

Short answer: As long as you install a Chrome extension from the Chrome Web Store and do not explicitly install a separate standalone binary, then the extension is, by default, trapped within the browser profile and cannot access nor modify other Chrome users. To say that there are "no filesystem protection in place" is inaccurate, as Chrome has never supported XUL-type extensions.

I'll address the two ways the other answer mentions as routes an extension can leverage to escape the confinement of a browser profile and access other parts of the filesystem, plus an extra. The first is through the nativeMessaging WebExtension permission, the second through triggering a file dialog, and the third is through the isAllowedFileSchemeAccess API. None are automatic (background or otherwise) and all require the user to explicitly agree to such access.

1) A WebExtension using the nativeMessaging permission cannot pull in the privileged native application on its own. Until the user explicitly decides to install the native application, the WebExtension is trapped within the browser profile it was installed in.

From the other answer, "[i]f any ... extensio[n] require[s] administrator access to install" then said software comprises more than just a pure Chrome extension, e.g., the extension taps into a standalone nativeMessaging client installed outside of Chrome, and by installing the external client (outside of Chrome) one might as well have installed a system-wide standalone keylogger binary that affects much more than just the browser. Game over, but the user's fault, since s/he has overridden the security provided by the browser.

2) From the other answer: "I was ... able to launch a portable copy of Firefox in which I installed an sqlite browser ... and browse to my old profile and see my history." File dialogs require explicit user interaction, hence this is not a security bug. If the user explicitly loads files into the browser profile for the extension to manipulate, then the user has expressed his/her agreement to having their data shared with the extension. Otherwise, the extension can do nothing but hope for the user to select a file in the Open File dialog, which the user (recalling the profile is meant to trap potentially untrustworthy extensions) can simply close.

3) The isAllowedFileSchemeAccess API on Chrome allows read-only access to the filesystem via the file:// protocol. However, "a user must explicitly permit this behavior for a given extension through the Chrome preferences pane in chrome://extensions" and as of early 2017 only 55 extensions on the CWS ask for it. (Source: Mozilla Wiki) Not only is the likelihood of encountering an extension abusing this privilege to snoop into the filesystem highly unlikely, but the privilege also requires that the user manually grants it to a browser extension.

Using separate browser profiles to isolate potentially dangerous extensions is more than good enough, as separate OS-level user accounts is overkill, unless one is defending against zero-day browser exploits that completely trash Chrome's WebExtension API permission model, in which case VM-level protections are in order. If we're playing with software that leverages exploits, then OS-level user accounts provide insufficient protection as we are now toying with malware.

Chrome Apps are an entirely different kettle of fish since they enjoy more permissions than standard Chrome extensions, but they are a deprecated technology and, more importantly, outside the scope of the OP's question since it asks about Chrome extensions. Thus, Chrome Apps are not covered in this answer.

In conclusion, a Chrome extension cannot jump across browser profiles unless 1) the user has manually installed a standalone executable external to Chrome, in which case all bets are off 2) the user selects a file in a file open dialog generated by an extension, in which case the user has explicitly granted the extension permission for arbitrary file access 3) the user manually ticks a box in chrome://extensions that extensions cannot themselves modify.