3 ms·

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

> 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. >
  - 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.
silvestrov 4y ago
Chrome need a "view source" equivalent for extensions. If should be just as easy to inspect extensions as it is for web pages, including all the network requests they have made.
- pcthrowaway 4y ago
  "view source" doesn't really even work for regular pages now, since the DOM is often very different from what is in the HTML page the user receives
- londons_explore 4y ago
  They pretty much do... In the web inspector, you can filter for network requests by an extension.
- salt4034 4y ago
  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.

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

silvestrov 4y ago

Chrome need a "view source" equivalent for extensions. If should be just as easy to inspect extensions as it is for web pages, including all the network requests they have made.

pcthrowaway 4y ago
"view source" doesn't really even work for regular pages now, since the DOM is often very different from what is in the HTML page the user receives
londons_explore 4y ago
They pretty much do... In the web inspector, you can filter for network requests by an extension.
salt4034 4y ago
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.