Many temptations of an open-source Chrome extension developer | Hacker News Reader

Many temptations of an open-source Chrome extension developer

github.com

214 pointstech234a61 comments

I found this list from a recent comment by extesy on another HN thread: https://news.ycombinator.com/item?id=27326974.

A similar list was also posted by another extension developer a few months ago: https://news.ycombinator.com/item?id=25884338.

Thanks for posting this. I've actually submitted the link myself a few months ago but HN ranking algorithm didn't pick it up back then: https://news.ycombinator.com/item?id=25907905

Anecdata: I develop an open source Chrome extension that's fairly niche but has about 80k active users, and I still get emails like this a couple of times a year. They tend largely to be offers for outright buying the extension (and thus install base, presumably to augment with ad- or malware); it's interesting to see how these kinds of offers to a more generally popular extension differ a bit (seemingly more asks to collect & sell user data rather than just taking over ownership)

Another thing I'd note for context is that Hover Zoom probably has a pretty broad hosts permission in order to allow it to operate on many types of sites (my extension, which is a web analytics DevTools extension, also needs an all hosts permission [to my chagrin, as it often makes the Chrome Web Store review process more difficult] ) which I would imagine makes it a more appealing target

How much do they offer you if I'm not too blunt?

Some samples from the last ~year:

- "expected $800/mo" for an affiliate ID injector

- "up to $50 per 1000 daily actives" for search engine override

The purchase requests largely take the form of "if you're interested in selling, please respond" and I don't really feel like opening that dialogue, so can't answer that part.

Interesting, thanks! What is an "affiliate ID injector" in this context?

Amazon pays affiliates money each time they refer you to purchase something on Amazon. They check the referral by giving you an affiliate id, which you can add as a query param to urls on your pages.

Injecting your id into unrelated pages gets you affiliate rewards sooner.

I imagine it injects affiliate links - ie if you search for something on Amazon, the affiliate payment would be attributed to the extension's owner. This would include overwriting existing affiliate links too.

Affiliate marketing pays out a fee to an affiliate (i.e. referral source) when a user makes a purchase, normally to the last-touch source using a unique affiliate id (e.g. Wirecutter constructs an Amazon link that contains their ID, so they get some money back when you buy one of their recommended products). With certain extension permissions, malicious actors can replace these instances of IDs with their own, or cause all Amazon links to contain their affiliate ID, etc, thus falsely claiming that payout for themselves.

Some blog has a link to Amazon (or wherever) and the extension modifies it to include the referral code of the affiliate.

It seems there is a major conflict between the following two goals:

1. Allow app (or extension) developer to push new updates to the users without the consent of the users.

2. Not allow the app (or extension) developer to push malicious/dangerous updates.

I would prefer a system where all extensions that are installable by default without jumping through hoops are hand-reviewed by the same people who package my browser for me.

I generally oppose automatic updates and granting app/extension developers the ability to push code to my computer without my consent. I support a walled garden controlled by benevolent package maintainers.

This is where I think the traditional Linux package maintainer shines, protecting the user from malicious software. If a package-maintainer (generally independent from the developer) packages software for a Linux distro, the package-maintainer can drop harmful updates. If instead we give the developers free-reign to push updates without user consent, the developers can and will sell out to the highest bidder.

Seems valid to want someone to vet your software, especially if it’s capable of self-upgrade. But I also think that’s an expensive process, and one that Google probably doesn’t want to pay for. People seem very up-in-arms about App Store fees but then complain when unmanaged stores produce mounds of garbage and/or malicious software.

I feel Linux distros have this problem solved.

1. Only distribute Free/Open Source software.

2. Only distribute software that somebody is there to package.

3. Allow the users to install other software and shoot themselves in the feet if they so desire.

And absolutely no auto-anything.

Every operation by package manager is a result of explicit user action.

To me it seems like there is a different trend happening - Ubuntu now has snaps which auto update and you no longer can get some software without them, whereas even Debian comes with unattended upgrades enabled in some cloud vendors.

Of course, only security update being enabled isn't such a bad thing, but in my experience and and all updates can break things sooner or later.

By default, many distros already install urgent security patches automatically. I'm pretty sure Debian does it for me, but I cannot remember all of the details.

In 2021, "absolutely no auto-anything" seems to guarantee your host will fall out of compliance and fall prey to hackers. How do you respond?

>This is where I think the traditional Linux package maintainer shines, protecting the user from malicious software. If a package-maintainer (generally independent from the developer) packages software for a Linux distro, the package-maintainer can drop harmful updates. If instead we give the developers free-reign to push updates without user consent, the developers can and will sell out to the highest bidder

Sounds good in theory but that hasn't been battle tested in a mass product used by non-tech savvy people like Chrome extensions that are heavily targeted. On the other hand there have been breaches even in the packaging landscape.

I have never heard of malware actually making into a mainstream Linux distro.

Has this happened? Which distro?

To expand on this, the opposite has been true. IIUC Firefox telemetry is enabled for all binary downloads from Mozilla website by default, but every distdo package manager worth its salt has it disabled. So the system is actually working as intended.

Arch btw, it was in AUR though, cannot blame maintainers.

Note that browser extensions are reviewed by humans, as are updates to them. You also need to pay a nominal fee ($5 by credit card) to submit an extension to the Chrome store, to avoid spammers.

Chrome extensions are generally not subject to human review. I maintained one with 50k+ weekly actives for about 3 years and I think out of probably ~500+ updates I had at most 10 go through human review, and most of those were due to a fraudulent DMCA claim (they started doing manual reviews afterward for a bit, then stopped again)

At the very least Google should detect "significant" changes in ownership and or the underlying account for extensions that have "important" permissions.

With this you could implement something where once changes are detected, users have to manually opt-in. Users who care about such things could look at the changes and see that sketchy changes have been made.

Wow. So many shady offers that you could use them as training data for a shady-offer generator.

Perhaps someone could help me understand what the attack vector of the group suppousedly conducting "DNS error research" is.

No idea, but I wonder if squatting on the most popular misspelt domains, to serve malware/whatever?

e.g. facebool.com or similar, presumably there's an interesting distribution of similar misspellings.

Just a guess but maybe they want to detect domains people are looking up that don't exist so they can squat them.

This really implies that the whole idea of chrome extensions is broken: a mix of attempted malware and adware.

It seems like they should be more carefully sandboxed in some way.

Are there any proposals for fixing this?

All new extensions are manually vetted now, and there is manifest v3, but there has been a lot of concern about the effect of this on adblockers so progress has been slow.

How is manual vetting supposed to prevent malicious updates? Are all updates vetted?

Most of the work that the Chrome folks have been doing on web extensions recently has specifically been to make finer-grained APIs to do the sorts of things extensions do without giving them full access to edit pages etc.

For instance, see the new "Declarative Net Request" API, which allows you to specify certain transformations on requests in JSON, like blocking them if they match a regex, without knowing what the request is: https://blog.chromium.org/2019/06/web-request-and-declarativ...

In theory, this allows you to implement things like ad blockers without having high levels of access to the user's browsing behavior. In practice, it's very hard to make these APIs complete enough.

"The data we’re interested in are basically just DNS errors:

NXD – Non Existent Domain - the domain that a user entered that resulted in a DNS error. [...]"

What's the catch here? Are they making the extension query invalid names like userspersonallyidentifiableinformation.com to exfiltrate data from NXDOMAINs?

Perhaps they want to snatch up the domain names people are trying out and then sell them to them with a margin?

If it's malicious it could be to buy up commonly typo'd domain names

Maybe they just want to buy these domains. I imagine that available domains people query a lot can be resold for a lot of money. Or they are into typosquatting.

A few possibilities I can think of:

- Trying to figure out commonly-mistyped domain names in order to buy them for ad placement.

- Trying to obtain confidential information that's accidentally pasted into the address bar.

- Trying to obtain internal domain names that someone tries to access while disconnected from a VPN or just physically outside the office.

- (If the extension could catch all non-existent domain errors, not just ones from typing in the address bar) attempting to find abandoned domains that are still referenced by JavaScript and whatnot in order to buy them. This could potentially be used to inject content (probably ads) into the systems that still reference those domains.

- Legitimate research into how users mistype domain names, maybe to figure out how to think of names that are less likely to be mistyped.

I don't know offhand if modern browsers also do DNS lookups as the user is typing characters into the address bar, or just do Google/Bing/whatever queries as the user is typing. I know they do the latter (i.e. typing 'news.ycombinator.com' into the address bar will send queries for 'n', 'ne', 'new', 'news', and so on to the search engine), but I don't know if they're also still doing DNS lookups at each step as well. If they are, and the extension could capture all of those, then that could be an interesting way to collect users' search queries.

Answered in https://news.ycombinator.com/item?id=27328642

There are 85 instances of 'redacted' on that page.

I don't think I'd have been as kind.

interesting how the offers went from mostly buying user data to most recently mostly acquiring the extension.

Why redact the company names?

Maybe to stop giving them publicity? Or maybe some of those people are not representing the actual company or it's work so people might mistake legit companies as bad.

The publicity from trying to bribe extension developers would not benefit the companies doing this.I f the people doing this aren't representing the companies you'd think they would want to know so they can stop it. Either way, they should be named and shamed.

Yep, this would also be useful for devs who only care about money, so that they can reach out to the more promising companies of these and see whether they can monetize their extensions as well.

Personally, I feel like that'd be a clear drawback to naming and shaming, even if I also support disclosure in general.

It’s addressed in comments on the page. The author does not want to get sued by a large company over a chrome extension, not worth the risk.

would love to see some communication from Google on this phenomenon...

What would they say about it?

The most obvious things Google can do are to either limit the power of extensions and deprecate abusable APIs or to be much more stringent about human review of extensions, both of which they're doing and are justifiably unpopular.

In theory they could come up with some sort of "Any cooperation with third parties who pay you to add stuff to your extension gets your extension banned" rule, but it seems hard to write that rule in a way that distinguishes it from legitimate commercial activity.

That they are aware of the growing problem and here's what they plan to do about it. I don't know what that would be.

> "Any cooperation with third parties who pay you to add stuff to your extension gets your extension banned" rule, but it seems hard to write that rule in a way that distinguishes it from legitimate commercial activity.

Requiring disclosure would make sense and not be a problem for "legitimate commercial activity", but also not sure how it would be enforced. I'm certainly no expert.

You could make it so the ability to access the network is a permission you have to grant to extensions. Got a shady extension that can't access the internet? Who cares.

Same thing would work very well on Android. Got a shady app that can't access the internet? Who cares. Of course, Google trembles at the idea of being able to run apps without a constant connection to an advertising network.

Isn't the point here, though, that the shady people reach out to try and buy control of non-shady extensions? How would you know whether or not your previously non-shady extension is now shady?

If the extension cannot access the network to send data anywhere, what's the worse that could happen in that scenerio?

Obviously some extensions have good reason to use the network, and there's no easy solution there. Some extensions change a color them on a page and that's it, I wish those could be denied internet access.

That would be a misleading permission if the extension has full DOM access because it could be easily circumvented.

> The most obvious things Google can do are to either limit the power of extensions and deprecate abusable APIs or to be much more stringent about human review of extensions, both of which they're doing and are justifiably unpopular.

I don't know about that. They seem to have too much stringent non-human review, which is what I usually see complaints about.

True. I guess I meant they could say "We default to not allowing extensions unless a human thinks the extension is a good idea," which will produce a similar outcome to the status quo - non-human review that has a high reject rate plus a frustrating human override process.

> 100к users ~10 000 $, and so on.

хахаха...

Why are you laughing?

I don't know what ad revenue CPMs are like, but surely any Chrome extension that gathers all web traffic (metadata, content and potentially credit card details) of 100,000 users is surely worth at least $0.1/user per month?

Especially if the users are predominantly from wealthy countries?

Are you laughing because you consider that figure on the low side or the high side?

I laughed in Cyrillic at the accidental Cyrillic ("к").

Reposting my experience from https://news.ycombinator.com/item?id=27326268:

As a dev of an extension with 10k users I get 3-4 emails a month in my spam which ask me to monetize my extension by secretly changing its users' search engines. My extension is open-source and quite small, but if the change was sneaked in I think most of the users would not notice. I stick to using userscripts for the most part since you can easily check their downloaded source and disable updates.

Example:

Beth Anderson <beth@monetize-extensions.com> Mon 10:58 AM To: Mostly Spam <dev@x-ing.space>

Hello

I am Beth and I am offering monetization for browser extensions, with everything that is going on our team was extremely focused and productive in creating a way to earn revenue on extensions.

We offer to change default search to Bing or Yahoo on your extension which can earn up to $800 a month per 5000 users. This is a premium product by invitation only and can easily be added to your chrome extensions.

You are might curious to know if it is allowed? And I must say that this is completely allowed! Please reply to this email to discuss this further!

Looking forward hearing from you!

Beth Anderson

Business Development Manager

There must be something more that they want as well? Seems very strange that Microsoft and Yahoo would be interested in paying big bucks to lure people to their search engines through some dodgy extensions?

Yeah, when I first shared it in a developer discord server I joked that Microsoft was operating a black market Bing-conversion program. Seems too shady even for Microsoft though. I guess they want me to inject ads/trackers into the results, but I don't see how it's easier with these search engines?

I think it is just to illustrate the scope of the change, not that their customers are either of those two.

Please don't copy-paste comments on HN: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que....

If you want to refer to what you posted someplace else that's great, but a link is the tool for that job. In rare cases you could always ask us at hn@ycombinator.com to move your comment to a different place, if it's much more relevant there.

Reply on news.ycombinator.com