Perhaps I'm missing something, or things have changed in the last couple of years, but when I last took a look there were a few main issues with the extension security model that would have been dead-simple to implement.
My understanding at the time (I realize I could be mistaken about any of these):
* Users have no idea what code they're installing. Extensions aren't required to be open source, where the community can audit them for malicious behaviour. Even if an extension claimed to be open source, there's no verification system to ensure the code actually being executed is the code displayed on their github.
* Automatic updates. Maybe this isn't the case now, but at one point I remember extensions were updating themselves automatically. Users of popular extensions are frequently contacted to add an "analytics" dependency from some shady company, in return for a nice payout. Users don't have the ability to opt out of these kinds of updates when some of their extension devs inevitably cave into the pressure. In my mind, these kinds of updates should only be shipped with user's full consent and understanding that they are being asked to install updates which have no practical utility to them
* Code obfuscation. I don't see why every extension shouldn't be shipped fully unobfuscated, at least as an option. Perhaps minified bundles could also be shipped as a way of supporting users on low-spec devices which really need those extensions, but then again, if disk space is so short for those users maybe they shouldn't be installing extensions in the first place
* Better observability of interactions between user-requested websites and extension background pages. If I look in my network panel I want to see communication with installed extensions happening
> Users have no idea what code they're installing. Extensions aren't required to be open source, where the community can audit them for malicious behaviour. Even if an extension claimed to be open source, there's no verification system to ensure the code actually being executed is the code displayed on their github.
I love this idea fwiw. Browser vendors should totally do this. Requiring OSS seems like a fair tradeoff for the power that extensions wield.
> Automatic updates.
In my day, extensions could auto-update but not change permissions. Also all updates had to be reviewed. The bribery issue is serious and sad, but killing updates seems like the wrong tradeoff. Ability to fix and deploy bugs is important for extensions just like any other software.
It is already possible to know which extensions are active on a page: https://i.imgur.com/73lmozH.png. This is a better level of observability than what you describe because once an extension has access to a page, there is no way to prevent it from exfiltrating data from that page. The communication with background page is not relevant. There are myriad ways to exfiltrate just given access to normal DOM, unfortunately.
Ideally before downloading the extension. However, with automatic updates, this is nearly useless. Malicious code can be injected at any time in the future, long after the user audits the code.
> Requiring OSS seems like a fair tradeoff for the power that extensions wield
To be precise, I wasn't advocating requiring OSS, just source-availability. Extensions should have at a minimum a visible repository displaying the source code, where users and auditors can publicly comment or leave issues (ideally, which the maintainers can't remove). Chrome should verify that the extension code matches the code in the repo (without an additional build/compile step - the repo should reflect the exact code being shipped in the extension). This way prospective users can inspect the code of an extension without installing the extension first and mucking about in dev tools.
> Ability to fix and deploy bugs is important for extensions just like any other software.
Ability to fix bugs, sure. Ability to deploy bugs (without user consent or knowledge) is an antipattern ;P Third-party browser code should never be shipped to the user without their consent and full transparency into what is being shipped. Users who don't intend to inspect the updates can opt-in to automatic updates, sure.
> Obfuscated code is already disallowed
This is great! Though they distinguish between minification and obfuscation, which is bizarre. Intentionally obfuscated code is hard to detect. I was suggesting they also disallow any form of minification (or at least require extensions to distribute with minified and unminified options, and have minified bundles verified)
> It is already possible to know which extensions are active on a page: https://i.imgur.com/73lmozH.png. This is a better level of observability than what you describe because once an extension has access to a page, there is no way to prevent it from exfiltrating data from that page. The communication with background page is not relevant. There are myriad ways to exfiltrate just given access to normal DOM, unfortunately.
This is true, but even background scripts which don't have access to the DOM can communicate with the content script through sendMessage.
A user looking at the network panel on the page might not see a network request sending their password to a strange server if the message is being sent to the background script and the request is being made from there. All communication in and out of the sandboxed extension environments should be logged and inspectable from any page where the extension contexts are being communicated with.
> Chrome should verify that the extension code matches the code in the repo (without an additional build/compile step - the repo should reflect the exact code being shipped in the extension).
To ensure that the code matches, Chrome servers could download the source code and build the extension themselves. This is what F-Droid does. For each version of the extension, they could also archive the source code they used to build it. Even if the repository gets rewritten or taken down later, the archive remains.
Funny story, the original version of the web store had a button you could press to see the source of an extension.
> Ability to deploy bugs is an antipattern
Disagree then. One doesn't come without the other.
> even background scripts which don't have access to the DOM can communicate with the content script through sendMessage
If by "content script" you mean the web page script, then this is true, but in that case the web page is collaborating with the extension. Whatever the web page is sending to the extension it could just as easily send anywhere on the internet.
> If by "content script" you mean the web page script, then this is true, but in that case the web page is collaborating with the extension. Whatever the web page is sending to the extension it could just as easily send anywhere on the internet.
Content script would be part of the extension that runs in the context of the webpage, and has access to the DOM
Yes, I agree this could be sent anywhere, but when sent to the background script with the sendMessage API, you don't get visibility into that with devtools out of the box
My understanding at the time (I realize I could be mistaken about any of these):
* Users have no idea what code they're installing. Extensions aren't required to be open source, where the community can audit them for malicious behaviour. Even if an extension claimed to be open source, there's no verification system to ensure the code actually being executed is the code displayed on their github.
* Automatic updates. Maybe this isn't the case now, but at one point I remember extensions were updating themselves automatically. Users of popular extensions are frequently contacted to add an "analytics" dependency from some shady company, in return for a nice payout. Users don't have the ability to opt out of these kinds of updates when some of their extension devs inevitably cave into the pressure. In my mind, these kinds of updates should only be shipped with user's full consent and understanding that they are being asked to install updates which have no practical utility to them
* Code obfuscation. I don't see why every extension shouldn't be shipped fully unobfuscated, at least as an option. Perhaps minified bundles could also be shipped as a way of supporting users on low-spec devices which really need those extensions, but then again, if disk space is so short for those users maybe they shouldn't be installing extensions in the first place
* Better observability of interactions between user-requested websites and extension background pages. If I look in my network panel I want to see communication with installed extensions happening