3 ms·

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 s

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

aboodman 4y ago
> 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. > Code obfuscation. Obfuscated code is already disallowed: https://blog.chromium.org/2018/10/trustworthy-chrome-extensions-by-default.html https://blog.chromium.org/2018/10/trustworthy-chrome-extensi... > Better observability of interactions It is already possible to know which extensions are active on a page: https://i.imgur.com/73lmozH.png 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.
- pcthrowaway 4y ago
  > 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 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.
  - aboodman 4y ago
    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. >

aboodman 4y ago

> 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. > Code obfuscation. Obfuscated code is already disallowed: https://blog.chromium.org/2018/10/trustworthy-chrome-extensions-by-default.html https://blog.chromium.org/2018/10/trustworthy-chrome-extensi... > Better observability of interactions It is already possible to know which extensions are active on a page: https://i.imgur.com/73lmozH.png 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.

pcthrowaway 4y ago
> 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 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.
- aboodman 4y ago
  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. >