Hacker News Reader

Comment by extesy | Hacker News Reader

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 other extension and I don't control what they do with their users data.

View on HN

You're doing a very admirable thing, and this helps dispel the little voiced but commonly held perception that "everybody sells out" when they get big.

uBlock Origin is also an incredible success story here!

and you are essentially trusting the moral integrity of the current maintainer.

why can't there be a method for making sure that such trust cannot be abused? Is this a tractable problem at all?

You'd still have to rely on the trust of the original maintainer, but they could set up something like a warrant canary[0], but for if they sold it or if they added tracking items.

[0] https://en.wikipedia.org/wiki/Warrant_canary

warrant canary assumes the maintainer is under coercion. But if the maintainer is untrustworthy, their warrant canary also won't be trustworthy, since it's trivial for the "sale" and the new maintainers to continue the existing warrant canary as though nothing has happened.

Aren't these also useless even for their original reason as they can just be given a demand from the legal system to keep updating the canary as if nothing happened?

The legal theory is that the law cannot compel you to lie. Of course, this is untested.

I don't think there's a solution for it after all. At the end of the day, you need to trust someone / something, unless you are the one who writes the whole code.

Which browser are you using?

Blockchain technology! ;D

I do think that reproducible builds would make a lot of sense for open-source browser extensions. Google could say "if you want your extension to get a Trusted Build tag, put the source code on Github, and we'll run the build script for you to ensure that the code submitted for store review is built from the code from a specific Git commit." And from a security perspective this would be better than what we have, which is zero guarantee that an "open source" extension even matches its stated repository. I'd trust the integrity of Google's automated build systems more than an independent developer with nothing to lose and everything to gain by sneaking in a third-party script.

Alas, the presence of this kind of reproducible build system would bring needed clarity to the chaotic ad blocker market, and the lack of that clarity works in Google's favor as an advertising company, so sadly I doubt they'd do such a thing.

Yes, that's what I mean, at the end of the day, you have to trust somebody / something.

Here you have to trust both developer's code and Google's build system. Can you verify all of the developer's codes? And can you verify how privacy-trustworthy Google's build system is? At the other side, you have to trust developer's code and developer's build.

I didn't mean which one you "should trust more" at all in my comment above. Please read again. What I mean is the first sentence here.

There is a method. Designing plugin and system API in such a way that allows users a granular control over plugins or apps permissions and network activity.

But that doesn't solve the problem of a plugin developer selling out. Under the granular permission control, your existing, granted permissions _should_ be revoked, but there's no way you could know to revoke it.

Something like a plugin is a fairly well defined thing and ideally should not need a lot of permissions. E.g. an ad blocker has a simple flow: occasionally update filters from a number of specified endpoints and then match and block web pages’ request urls against downloaded lists. Between update it should have zero web traffic and filter updates are expected to be from known whitelisted sources and asymmetrical in size: very few bytes sends and a lot received. If all of a sudden after an update your plugin wants to send a bunch of data to a new URL you know immediately something is fishy. With respect to granularity, in this case the plugin might not even need to know the entire URL but just the host/domain name - this makes it less attractive to adtech.

Yet the very same author turned over the OG uBlock to a shady character, having to launch a competitor to take back the momentum. To this day there is still confusion among normies.

I didn't turn over the extension in the Chrome Webstore, I always have been the owner of it since I first published uBlock in June 2014.

Thanks for clarifying. I stand corrected. Curious if you've secured the trademark? Seems someone has tried with #78022486

I really appreciate the transparency from you. I don't use Chrome anymore, but back in the day I absolutely loved Hover Zoom+ and my wife is still loving it to this day. It's a great extension and having read your comment and the linked Github issue, I feel even better about it. Thanks for your hard work.

Thank you for the kind words. I actually publish hoverzoom+ to Firefox and Edge as well (links are in the repo's readme) so you can use it there too.

Wow! This just made my day, thanks so much. I don’t know why I never bothered to check if there was a Firefox version. Thank you!

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)

ah okay, thanks :)

Reply on news.ycombinator.com