3 ms·

> 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. Exte

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

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. >

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

salt4034 4y ago

> 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.