Detect when your installed Chrome extensions have changed owners

• under-new-management

  2 582 8.0 TypeScript

  Detect when your installed extensions have changed owners.

  

This is a cool idea!

However, I have a number of reservations:

1. Firstly, the JavaScript code in the release version of the extension is 12MiB. This is a lot of code, with much of it in a bundled form, making it very difficult (if not almost impossible) to verify them against the originals in the case of React, lodash, etc.

2. It seems like the code uses an external API[0] to find the current owners of the installed extensions. While I appreciate that this may be one of the only ways to do it (since I imagine Google themselves would not appreciate an extension programmatically accessing the Chrome Web Store to find new developers) - and as far as I can see from the published code, it doesn't send any identifying data beyond what a normal Web request does, hence why I'm not identifying the site by name here - I would still urge caution as it might still cause alarm to someone examining their Web traffic and seeing a suspicious domain name, as the sort of person who would be interested in this extension is probably also the sort of person who would do that.

[0] https://github.com/classvsoftware/under-new-management/blob/...

• crxmon

  2 24 8.3 TypeScript

  WIP - scripts for analyzing the (in)security of Chrome extensions

> How is this even possible that Google allows this? Is this really true?

Yes, you only need to upload the key (meaning, include a `key.pem` in your packed zip file) on first upload. [0]

However, I'm not sure if Google will allow you to upload with a _different_ key. Since the extension would change, I'm not sure what would happen, both to the webstore page (does the previous one 301 to the new one?) and to existing extensions (do they stop auto-updating?).

> This weekend Chrome decided to disable all these extensions on just one machine

There is a trick for this, if you are loading an unpacked extension. Simply edit `manifest.json` in the unpacked extension directory, to add a `"key": ""`. You can do this with any extension from the store, since you can extract the public key from a .crx file [1]. When you load an extension this way, the ID will be the same as the "real" extension.

[0] https://groups.google.com/a/chromium.org/g/chromium-extensio...

[1] https://github.com/milesrichardson/crxmon/blob/4dae445b05b76...

• InfluxDB

  www.influxdata.com sponsored

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• DivMagic

  12 52 5.5

  Copy design from any website as CSS or Tailwind CSS components

  

I'm currently working on an extension as well ([0]) and share the same concerns many have mentioned about extensions here. I'd like to highlight another dimension concerning the Browser APIs ([1]).

Handling the permissions necessary for certain API functionalities and the corresponding warning messages can be somewhat confusing. For instance, our extension uses "chrome.devtools.panels" to open a new window within DevTools. This API doesn't require any permissions by itself. Yet, for messaging across the popup, content, and DevTools windows, we're required to use activeTab and sendMessage APIs. The DevTools window operates in its unique context, almost like a tab within another tab. For example, updating the URL in the active tab doesn't directly update the DevTools window but triggers an event.

Messaging across these different contexts requires the "https://*/*" host permission, without which Chrome and Firefox won't send the messages between these isolated windows.

We made this permission optional, the DevTools Panel is activated only upon receiving explicit user consent. However, the permission prompt's messaging is something like "This extension requires access to all your data," which sounds very alarming. We don't access any data nor that we want to, but requiring that permission is mandatory since the message APIs won't work without them.

This is just one example of the many undocumented complexities within Chrome's documentation. Similar pitfalls exist with message exchanges between the background service and content scripts. Sometimes you don't know why your API call doesn't work even though you think you have the required permission and asking for more permissions show very alarming messages to users.

I think that a more granular permission approach, made specific to API functionalities rather than broad permissions that cover a list of APIs, would significantly help user experience. For example, requesting permission for the "sendMessage API" with a clear explanation would be far more informative for users than the general "All host https:///" permissions.

There's also the issue of building for different browser. The same browser API calls can have different permissions requirement on Chrome and Firefox which makes the development process more difficult and more confusing for users since the same extension requires different permissions on different browsers.

[0] https://divmagic.com

• chromium

  224 17,574 10.0

  The official GitHub mirror of the Chromium source

  

Recently my favorite open source mouse gestures extension SmartUp Gestures was taken over by some shady entity (with github no longer being updated of course).

I opened Chrome ticket that they should ask to re-enable extension when ownership changes. They just closed the ticket replying with this link:

https://chromium.googlesource.com/chromium/src/+/main/extens...

:(

• ad-accelerator

  5 375 7.3 JavaScript

A few months ago I made a free open source extension to speedup youtube ads that I shared here & hit the front page. Within a week a guy (who commented on my show hn thread) copied it and promoted his version on reddit which went viral and has 300k+ Users [1]

But why copy a free open source extension instead of just contributing? Well... a few weeks later he was trying to sell it on multiple sites for 5 figures. Maybe they still own it but I couldn't help but notice that the registered developer for his extension on the chrome store has also changed since it was originally published.

[1] https://github.com/rkk3/ad-accelerator/blob/main/lessons_pos...

• little-rat

  8 1,993 6.9 JavaScript

  🐀 Small chrome extension to monitor (and optionally block) other extensions' network calls

Great idea! We need a lot more visibility into what extensions are doing. I made little-rat [1] last year, to detect network calls coming from other extensions. Love to see more tools like yours!

[1] https://github.com/dnakov/little-rat

Suggest a related project