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

JSON formatter Chrome plugin now closed and injecting adware

github.com

Post reply on HN
Print view View original

141–146 of 146 posts

Re: JSON formatter Chrome plugin now closed and injecting adware

#141

Post by tredre3 »

babuskov wrote: post #118
jimrandomh wrote: post #60

I think the main problem here is the ideology of software updating. Updates represent a tradeoff: On one hand there might be security vulnerabilities that need an update to fix, and developers don't want to receive bug reports or maintain server infrastructure for obsolete versions. On the other hand, the developer might make decisions users don't want, or turn even temporarily (as in a supply chain attack) or perman…

If the extension does something that isn't changing, like JSON Formatting, I guess it's best to disable updates right after you install it. I just did this for all extensions I have in Firefox. Not sure about extensions like uBlock though? Doesn't it fetch new lists of sites to block or something like that? Or is that done separately from updates?

> Doesn't it fetch new lists of sites to block or something like that? Or is that done separately from updates?

It's done separately from updates.

I also disable auto updates for extensions and I keep extensions that I don't need daily installed but disabled.

It's annoying that firefox doesn't have a "Update all" button but clicking manually on a handful of extensions once a month isn't that much of a chore :shrugs:.

Re: JSON formatter Chrome plugin now closed and injecting adware

#142

Post by tredre3 »

grishka wrote: post #103
jimrandomh wrote: post #60

I think the main problem here is the ideology of software updating. Updates represent a tradeoff: On one hand there might be security vulnerabilities that need an update to fix, and developers don't want to receive bug reports or maintain server infrastructure for obsolete versions. On the other hand, the developer might make decisions users don't want, or turn even temporarily (as in a supply chain attack) or perman…

For me, the solution is simple: anything you download and run locally should not auto-update ever, period. Installing an update (or refusing one) should always be a conscious user action. Otherwise it's just a socially-accepted RCE backdoor.

I used to use Duplicacy for my backups. The author was hell bent on not allowing disabling auto updates.

The go binary would be downloaded automatically and silently periodically. I tried to fight it for a while but at some point he added checks (!) to ensure that nobody was blocking his RCE model. Meaning it would no longer run on one of my partially air gapped system.

I moved on, but many other software behave that way.

Most chromium-based browsers will show a big scary and permanent button if they can't update, for example.

Re: JSON formatter Chrome plugin now closed and injecting adware

#143

Post by olyjohn »

grishka wrote: post #103
jimrandomh wrote: post #60

I think the main problem here is the ideology of software updating. Updates represent a tradeoff: On one hand there might be security vulnerabilities that need an update to fix, and developers don't want to receive bug reports or maintain server infrastructure for obsolete versions. On the other hand, the developer might make decisions users don't want, or turn even temporarily (as in a supply chain attack) or perman…

For me, the solution is simple: anything you download and run locally should not auto-update ever, period. Installing an update (or refusing one) should always be a conscious user action. Otherwise it's just a socially-accepted RCE backdoor.

Yep, just like Anti-Virus back in the day. Sure, it might protect you from a virus now and then, but AVs actually caused more broken computers, and false positive triage work than they protected. In the long run it was never worth running an antivirus on your computer.

This is how updates are now. Sure, there are sometimes some security updates that you should have installed. But more often than not it's just some bullshit I don't want.

Re: JSON formatter Chrome plugin now closed and injecting adware

#144

Post by grishka »

tredre3 wrote: post #142
grishka wrote: post #103

Earlier quoted context omitted.

For me, the solution is simple: anything you download and run locally should not auto-update ever, period. Installing an update (or refusing one) should always be a conscious user action. Otherwise it's just a socially-accepted RCE backdoor.

I used to use Duplicacy for my backups. The author was hell bent on not allowing disabling auto updates. The go binary would be downloaded automatically and silently periodically. I tried to fight it for a while but at some point he added checks (!) to ensure that nobody was blocking his RCE model. Meaning it would no longer run on one of my partially air gapped system. I moved on, but many other software behave that…

> Most chromium-based browsers will show a big scary and permanent button if they can't update, for example.

Vivaldi which I use thankfully doesn't do that. At least on macOS it uses the common Sparkle updater, which would pop up a window in your face when you least expect it telling you that an update is available, showing a changelog and letting you decide when and whether to install it.

Even though it is an interruption, it's still much more respectful than what Chrome does. It insists on running a background service at all times and the only way I was able to neutralize it was to delete its .plist file and create a directory with the same name.

Re: JSON formatter Chrome plugin now closed and injecting adware

#146

Post by hybirdss »

eviks wrote: post #97
hybirdss wrote: post #72

just went through all my github actions and pinned them to commit SHAs after reading this. same problem — if someone pushes to @main your CI blindly runs it. auto-update anything is basically handing someone a key to your house and hoping they stay nice forever

Fyi you can add zizmor that warns about things like this and add a repo config that futures shas so that a mistake can't happen in the future (but not sure if you can have the setting globally)

nice, gonna run that on the repo tonight. the manual sha pinning approach was always going to be the kind of thing i'd forget after the next dependabot bump
Post reply on HN