Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Temptations of an open-source Chrome extension developer (2021)

github.com

Post reply on HN
Print view View original

161–170 of 374 posts

Re: Temptations of an open-source Chrome extension developer (2021)

#161

Post by hot_gril »

amadeuspagel wrote: post #2

The root problem here is that there's no legitimate way to monetize browser extensions. Extensions are meant to be simple, so it's hard to sell premium features. Extensions usually don't "own" any space to embed ads in.

Might at least make these attacks harder if users could disable extension updates, or had to opt into them. Most of these extensions are simple and don't really need to be updated, yet the update mechanism is silent full auto bada bing bada boom no rollbacks. I can't think of any updates more aggressive, not even Steam.

Re: Temptations of an open-source Chrome extension developer (2021)

#163

Post by hot_gril »

burkaman wrote: post #19
amadeuspagel wrote: post #2

The root problem here is that there's no legitimate way to monetize browser extensions. Extensions are meant to be simple, so it's hard to sell premium features. Extensions usually don't "own" any space to embed ads in.

An extension user could theoretically be willing to pay for the value the extension provides them. The malicious actors sending these emails are willing to pay for the value that a user's data provides them. These two numbers are not related in any way, and the value of user data will often be much higher than the value of the extension's functionality. There is no way for monetization to solve this, because the two…

Yeah. We've already seen user data win over paid software in other spaces. Someone charitable or just not-so-bad has to buy it out instead.

Re: Temptations of an open-source Chrome extension developer (2021)

#164

Post by jcparkyn »

Chabsff wrote: post #10
6DM wrote: post #5

Earlier quoted context omitted.

I think the only way is to treat access like we do web apps, then enable/disable features accordingly. That's kinda lame because now you have to have a backend setup, just so you can charge for some features.

The issue with that is that "Gets to read and/or write the DOM" happens to be the only permissions a nefarious extension needs while also being those that a vast number of useful extensions require.

That's why it'd be nice to have a general "access the internet" permission, since DOM reads are usually harmless if they can't get any data back.

Re: Temptations of an open-source Chrome extension developer (2021)

#166

Post by xboxnolifes »

jdthedisciple wrote: post #118

What's wrong with selling data if it's truly anonymized?

If it was up-front and clear in scope and intent, I would have much fewer problems with it. But, I don't think I've ever some across software that clearly and explicit listed the scope of what will be tracked (and how), clearly stated that it was intended to be sold, and gathered clear and explicit consent from the user.

Re: Temptations of an open-source Chrome extension developer (2021)

#167

Post by shadowgovt »

bensecure wrote: post #156
shadowgovt wrote: post #130

Earlier quoted context omitted.

In manifest v2, downloading and executing arbitrary code is a feature. What you're describing is the migration path from v2 to v3. "Detect if the extension downloads and executes arbitrary code, and ban it if it does" is isomorphic to "deprecate the eval arbitrary code permission, cease supporting it in the store, and provide an alternative declarative model to get some of the behavior back;" it's what Google is tryi…

It's a composition of two features, both of which are useful on their own. Removing this "feature" requires removing at least one of those sub-features, in this case eval. We could alternatively allow eval to be used, but ban it from being used on code downloaded from the internet. This would require vetting the code, rather than a fully automated check. The goal of such a removal is, supposedly, to enable manual vet…

> This would require vetting the code, rather than a fully automated check.

Then it's a non-starter for the manifest format supported by the chrome web store. Because Google's goal is to automate as much as possible.

Re: Temptations of an open-source Chrome extension developer (2021)

#168

Post by pynappo »

donkeydoug wrote: post #147
extesy wrote: post #76

Maintainer here. My extension is pretty much unmonetizable so any offer I receive would require some degree of a moral sacrifice. The least intrusive offer I've seen so far is to put a reciprocal link to somebody else's extension inside of mine, kind of like DarkReader is doing on their website. Even though it won't compromise any of my users data, the reason I'm not doing this is because it indirectly endorses that…

Hi, I used to love hoverzoom... was there a malware scare a while back or am I thinking of a similarly named plugin ? At the time I switched to imagus & adjusted to it. Either way, thanks for turning away the monetization attempts :)

that was hover zoom (the original) not hover zoom+ (the fork by GP)

Re: Temptations of an open-source Chrome extension developer (2021)

#169

Post by bensecure »

shadowgovt wrote: post #167
bensecure wrote: post #156

Earlier quoted context omitted.

It's a composition of two features, both of which are useful on their own. Removing this "feature" requires removing at least one of those sub-features, in this case eval. We could alternatively allow eval to be used, but ban it from being used on code downloaded from the internet. This would require vetting the code, rather than a fully automated check. The goal of such a removal is, supposedly, to enable manual vet…

> This would require vetting the code, rather than a fully automated check. Then it's a non-starter for the manifest format supported by the chrome web store. Because Google's goal is to automate as much as possible.

Naturally. Thus, it doesn't much matter whether code is shipped in the extension package, or downloaded off the internet, since nobody will be checking what it does regardless.

Re: Temptations of an open-source Chrome extension developer (2021)

#170

Post by Firmwarrior »

eviks wrote: post #155
collaborative wrote: post #56

I don't know what the solution to this is, but I know a few trusted/legitimate companies that sell their user data for around £20/year even after having monetized their users with actual money I will never do this because violating privacy goes against the core of my beliefs, but there is a conflict I can't seem to work out. On the one hand, I KNOW that the vast majority of users prefer to sell their privacy than pay…

The solution of for the app store owner to develop a better monetization scheme that would reward developers + track change of ownership + some distributed review system + better sandboxing + no forced autoupdates + A few other things

Man, that would be nice

World of Warcraft has an in game ui addon modding system built in that ends up suffering from these same problems. It’s so damn frustrating to see addon developers sell out their fans to a super shady spyware company for like $3/month (and the alternative is $0)

I could understand betraying people for a life-changing amount of money, but £20 is 5-20 minutes’ worth of pay for a competent SWE…

Post reply on HN