By most estimates, Chromium browsers have a 70-80% market share and are deployed in academic and enterprise environments across the globe. Policy-based management is vital to ensure a uniform user experience and enforce security controls, yet on Windows bypassing some aspects of this as a restricted, non-admin user is trivial. This is concerning because schools may rely on these settings for duty of care and student protection.
In recent posts I’ve outlined why Internet security is important for schools and how network-based monitoring and filtering solutions are no longer sufficiently comprehensive to be viable in isolation. To achieve an acceptable level of visibility we must push this function higher up the stack, onto the device or into the browser. The latter is appealing as Internet protection products based on browser extensions don’t need invasive drivers or services on the host to leverage an unsurpassed degree of access and control over the student’s experience, exposing metrics that would not be visible via network traffic inspection alone, such as:
- Time spent on a certain page, tab or video
- Content viewed such as text, pictures and video transcripts
- Content typed by the student
- Content copied, pasted or saved
Obviously this only works in an environment where the device is restricted to a single managed browser and non-browser apps are strictly vetted, but it opens the door to dynamic filtering via an on-the-fly evaluation of the properties of content being viewed rather than the traditional approach of checking a static list of known-bad locations. This holds the promise of increasing accuracy while reducing administrative burden in the process of keeping students safe online.
Unfortunately on Windows the browser operates entirely in user-space and all of its settings and extensions are stored in a single user data directory:
Even when following best practice for device restrictions where the user is not an administrator and their system is restricted with Applocker, they will retain full control of this folder. They can open the path via the %localappdata% environment variable, browse to the extensions folder within their profile and delete or alter files to prevent it from loading.
When the browser encounters an extension it can’t start, it will log application event ID 256 referencing the affected folder, but will fail-open and continue to operate normally. Most importantly, there is no method for automatic remediation.
Baffling lack of interest
While it is possible to configure an alert on the event ID, or run a regularly-scheduled script to check for the presence of the extension files to know when a user has tampered with their device, preventing it is more difficult. Changing ACLs to prevent user modification of the profile or extension folders seems logical but can cause unintended consequences. If it cannot write to the profile, the browser will encounter stability issues and the extension will fail if it cannot be installed or updated.
The only workaround I have found is the GPO / Intune CSP for “Hide these specified drives in My Computer” which will result in access being prevented if targeted at the system drive but this may limit necessary functionality elsewhere and it’s still possible to side-step by browsing through the File/Save dialog in an application such as Notepad.
I raised the issue with Microsoft’s Edge team and the support ticket was closed under ‘behaviour by design’. While that’s true, and this is certainly a universal Chromium-on-Windows issue rather than a Microsoft-specific one with their Edge implementation, I urged them to follow up with an investigation and suggested several possible solutions.
- The monolithic user data directory is split in two with a path outside of the AppData folder (to which the user has no write access) containing system-wide policies and extensions applied to all user profiles on the browser.
- Broken extensions can be automatically remediated. This could be a simple case of a flag that when set will force a removal and reinstallation of any broken extensions on first run, using the stored source path (the place the extension was downloaded from).
- Extensions can be administratively assigned as essential, so the browser will fail-closed to some degree when they are absent or broken.
Perhaps I’ll be able to get someone more familiar with the internal workings of the Chromium browser to take a look and see if I’m missing something; if I hear anything interesting I’ll post an update here.
Since my school has a support agreement with Google and their Chrome browser is also based on Chromium so would exhibit the same behaviour, I thought I’d try raising it with them directly. Following submission of a video demonstration and detailed documentation including my suggested fixes above, they responded:
Our Product engineering has confirmed that behavior exposed cannot be controlled/managed by Google Chrome browser. However, in the best effort to help you with this incident, I would suggest creating a kind of automated process (should be created/written separately) that changes access to the folder(s) so a user couldn’t delete/cut it off. If you are running Windows 10 Pro, you can use the built-in BitLocker functionality to password protect/encrypt the “App Data” folder.
That’s a doozy of a statement isn’t it? Not only does it suggest something that I explicitly explained in my submission could not be reliably done (changing permissions on Chrome’s user data directory) but it throws in a wholly inappropriate solution in the form of Bitlocker.
With a heavy sigh, I replied at length with references to explain what exactly Bitlocker is and why it won’t help in the slightest, asking to be connected to someone on their Chrome engineering team to have the discussion directly. After some delay, the response came back:
I understand your concern regarding this situation. Please keep in mind that Google Chrome has limited control over your Windows devices, the type of restriction you are requesting is usually handled by a directory service, such as Active Directory (AD).
At this point I feel like extending an invitation to come and sit in my technology essentials class. Instead I referred them to their own documentation which states:
Setting the policy specifies a list of apps and extensions that install silently, without user interaction, and which users can’t uninstall or turn off.
I pointed to my evidence which proves that this is not correct since users can indeed uninstall these extensions and again requested to chat to someone on the Chrome engineering team. Unfortunately they’re holding to their rather shaky position that this is a Windows issue:
I understand what our documentation states, and the user can’t uninstall or turn off the extension from the actual browser, however such behavior (cutting/deleting folder with extensions) is not managed by Chrome, it falls in this case to Windows level. We suggest that once an extension is installed, a kind of automated process is executed that changes access to the folder(s) so a user couldn’t delete/cut it off.
I asked for proof-of-concept code for the process to change access to the folder without breaking the browser but that was a bridge too far, so the entire issue is now being buried at the bottom of their feature request list and the ticket closed.