As our readers should hopefully be aware by now, Chrome extensions have proven to be a continuous threat. Google is slowly but surely working to make extensions less potentially dangerous for users and enterprises. Extensions are a good way to improve the browser end user experience, but that opens up users to potential security and privacy issues.
Their latest tweak involves reducing Chrome extensions’ access to user data and moving from recommending developers add privacy policies to requiring it.
Latest Chrome extension changes
Google announced an update to Project Strobe at the end of May focusing on two specific changes developers must now follow. When Strobe was first revealed in last year, one aspect was around improving data protection (e.g., limiting access to Gmail accounts, SMS, contacts, and phone numbers), which is the focus of the recent updates.
First, developers must now request only the appropriate data needed to implement features in the extensions and nothing more. Basically, if there are multiple potential permissions that would provide the extension with access to data it needs, developers must the select the permission with the least access. This reduces the chance a utilities extension could siphon too much user data that it really doesn’t need access to anyway.
Google says the two changes will officially go into place sometime this fall, but developers will get 90 days’ notice when Google is ready with an official date.
Other recent changes
At Google Cloud Next 2019, they announced the release of Chrome Browser Cloud Management, which Google admin use to manage browser extensions more easily. From a dashboard, admins can select permissions they don’t want on any Chrome extensions, preventing them from downloading on enrolled devices. Less security-regulated organizations can use Chrome Browser Cloud Management to disable extensions with certain permissions on selected websites, giving users more freedom.
In a less-welcome move, Google made it clear they were forging ahead with the partial deprecation of the webRequest API content blocking extensions relied heavily upon to work. Enterprises are not affected by this decision, just average users; a move potentially made to allow enterprises to continue to develop in-house Chrome extensions. But part of the Manifest v3 does include some positive changes to extensions, such as disallowing remotely hosted code, allowing only ServiceWorkers to run background services, and pushing for more developers to use optional permissions at runtime.
Slow steps but progress!
Google is definitely slow moving when it comes to tackling the problems around Chrome extensions, but I’ll give them the benefit of the doubt that they were focused on lower-hanging fruit (plus you can’t move too quickly with widespread changes when you have 2/3 user share of all browsers).
Still, it’s definitely a good thing for enterprise users forced to use Chrome who worry about security and what extensions might expose. For organizations unsure about Chrome extensions, there’s always Duo’s free-to-use CRXcavator tool, which scans all your Chrome extensions and provides a risk score. IT admins can also use the previously mentioned Chrome Browser Cloud Management tool to manage Chrome extensions via permissions.
There are a few features we think would be potentially valuable that we haven't seen, like the ability for admins to isolate Chrome extensions in a sandbox to determine whether they’d really like to allow it in their organization. You could open a small container, like Windows Sandbox, and run Chrome in that, but requires extra work.