An Open Letter to the Chromium Team About Their Proposed Changes to the WebExtension Standard
Hi Chrome WebExtensions Team,
I’m Dan Finlay, a lead developer at MetaMask. We’re a chrome extension crypto wallet and account manager with about a million active installs.
I’m writing to raise a concern with Chromium Issue 896897, Implement Manifest v3 for Chromium extensions. I commented there, but I am re-publishing here for the sake of more easily linking to our specific concerns (especially since there are so many concerns being expressed regarding those changes).
We would like the v3 manifest format to not be pushed to production in its current form until support for the FrozenRealms specification has been included, or at least iFrame API support is kept in the background script context, allowing extensions to run foreign scripts in an isolated environment.
Most of the WebExtensions representing this perspective are plugin systems like GreaseMonkey, which increase security by limiting its extensions’ access to the DOM. In addition to plugin systems, I’d like to share another security concern related to these changes.
We have been working on using Agoric’s SES (Secure EcmaScript) to better isolate our dependencies, to reduce the risk of dependency-based thefts like the CoPay Dash event-stream hack, as suggested by Zooko Wilcox. SES was derived from Google’s own Caja project.
Currently Agoric’s SES relies on a polyfill of the Realms API that relies on the iFrame API, which is not available in ServiceWorkers at this time, which the proposed manifest v3 currently requires all background scripts to be.
All we really need is the FrozenRealms API, since it’s the simplest way to truly isolate foreign code in a secure way, but keeping iFrame support would at least let us continue using the SES Realms polyfill.
Our background script must handle user keys which manage cryptocurrency accounts, often the most security sensitive bits of data on the user’s entire computer, so it should be understandable that we care very much about the security available to the background script in particular.
Thanks for your time,
Dan Finlay and Aaron Davis,