You are congratulating them on adding malware and then removing it.

Actions have consequences and this is a natural consequence, not a punishment. Trust was broken and users are not bound to prove the dev was in bad faith. The dev broke the trust and they can try and prove adding malware was done in good-faith if they wish. If the dev didn't care or _understand_ the severity of this change, then I have no problem if the project dies, gets forked, or whatever.

I believe he acted in bad faith because the git commit message was "restructuring external dlls", as if it was a minor change which had nothing to do with botnets. He knew what he was doing was wrong, otherwise why not honestly say "integrated Spider service"? It reminded me of the PHP repo hack last year when a backdoor was added with a git commit message "fixed a typo".

Why on earth would you be defending this? No one would ever add something like this in good faith.

Do we know if this was enabled by default? The Spider.com SDK License [0] appears to not allow it.

> Partner shall ensure that only Users who have expressly agreed to become nodes will actually be marked by Partner as such (…).

[0] https://www.spider.com/sdk-license

Didn't read the whole code but this makes me think it was: https://github.com/d2phap/ImageGlass/commit/31c1b918165c42de...

The service was enabled by default. In a later commit he adds an option to opt-out of Spider being enabled.

If he was adding it in bad faith, why would he put it on GitHub for all to see, rather than building the binaries in a private fork? Seems like this is incompetence / naivete rather than malice.

He put the code in a commit titled "restructure external dlls" with no reference to what it did, and in other commits includes the string "Spider" (no description of _what_ that does in the title). These weren't added as pull requests where one might expect to review proposed changes, but as direct commits to ~master.

It's not uncommon for people to put obfuscated malware into open source code See: hackers putting cryptominers and wallet stealers [0] into compromised NPM packages, or UoM campus being banned from contributing to Linux for backdooring the Linux kernel [1].

[0] https://www.trendmicro.com/vinfo/dk/security/news/cybercrime...

[1] https://www.theverge.com/2021/4/30/22410164/linux-kernel-uni...

It’s disingenuous to assume people are acting in bad faith. The developer tried to turn his users computers into a botnet. The thing that made him change course was that other people noticed and said something. Public criticism and not a sense that spider runs counter to his users interest is what people are objecting to.

The idea that, at some point in the future, the developer will make a token effort to notify his user base before doing something against their interest is enough to make me not want to use this developers software.

Even if the author legitimately didn't mean to do harm, and was acting in good faith, he should never (or at least, for a very very long time) be trusted to contribute to software that isn't subject to someone else's review.

He's shown such a fundamental misunderstanding of the trust that was placed in him. He knowingly merged _malware_ into his software and then did the minimum amount of plausible deniability (a discord poll that 99.99% of his users don't access, and an opt-out buried in a menu).

> Even if the author legitimately didn't mean to do harm, and was acting in good faith, he should never (or at least, for a very very long time) be trusted

I disagree. Let people learn from their mistakes.

> ... to contribute to software that isn't subject to someone else's review.

That's hard to do when it is the author's own software. This "someone else must be lord and master" solution often doesn't apply to reality. Also, I've seen entire companies full of bosses managing people who "are not to be trusted" to do the right thing eventually end up doing the worst possible evil. Let the author learn, and move on.

> He knowingly merged _malware_ into his software and then did the minimum amount of plausible deniability

Or he asked his most active users, and they said it was fine as long as I can turn it off. Who knows... To assign any intent other than to make some money would be assuming a lot of facts that are not in evidence. The good guys won on this. Let's move on to actual problems instead of punishing someone for learning.

> Let people learn from their mistakes.

I'm interested in finding out to what degree you hold this viewpoint. How severe do the negative consequences of an action have to be where you would switch from saying "let them learn from their mistakes" to "we can't trust them again".

(I'm honestly interested in knowing, this isn't just a rhetorical statement.)

If a crime has been committed is one such line, and were the author to do this kind of stuff repeatedly, there's another such line there. But if we hang everyone on the first offense, there will be no one left to hang anyone.

I wouldn't necessarily "hang" a first-time offender, but I'd definitely be wary, and cautious of how much I'll trust them in the future. Personally, I'm not a fan of making statements that say "I'll never again buy/use such-and-such a service or product". I might be willing to consider using their software again in the future. (I'm speaking in the context of this argument, since I've never actually used ImageGlass.)

Regarding crime, there a lot of behaviors that aren't legally defined as crimes, but are still objectionable (sometimes very). As such, there is no court to prosecute them with the legal system's presumably objective processes, so it's up to the general public to make our own assessments.

Finally, I'm curious as to your level of tolerance to questionable, unexpected behavior by software developers. Maybe not this one, but I wouldn't be surprised if there were certain actions by software developers where you wouldn't tolerate even a single offense. In any case, our differences regarding tolerance to questionable behavior is why we're all discussing this incident anyway.

Maybe the best way for the author to learn from his mistake is to get yelled at and the project forked away from him.

Like, I dunno, but if someone decides to feed my dog a KitKat, I probably wouldn't trust them around my dog anymore, you know? Yeah, they've learned their lesson about dogs and chocolate, but what other stuff don't they realize?

> Maybe the best way for the author to learn from his mistake is to get yelled at and the project forked away from him.

If you feel like that is appropriate, you could do that. I'm just glad the author removed the malware, and hope he's able to find a way to make money that doesn't involve a commercial botnet.

Why are you defending him? He infected potentially thousands of people with malware to make a quick buck.

That he reluctantly reverted the change only when people noticed and called him out on it is not particularly honourable or worthy of praise.

Because people make mistakes

And those mistakes affect others. If your mistake was infecting people with malware, you're not going to be a popular person.

What was the mistake? Did they accidentally add the malware? Did they accidentally make the commit message "restructuring dlls"?

"My users pushed back against malware I snuck onto their computers, they're so toxic and they're killing my dreams of successfully infecting them with malware!"

Without really knowing the author, it's hard to know whether they did what they did in bad faith or in good faith. Regardless of whether it's malice or naivete, either one makes it hard to trust such a developer again, at least right away. They'll have to work hard at earning that trust again and be careful to not make such glaring mistakes again.

Not necessarily bad faith but bad judgment for sure. I could understand making this "opt in" for users who understand what it does and want to help out, but it definitely shouldn't have been loaded by default.

> My argument rests on the assumption that the dev was acting in good faith.

There is no way this was a good faith move, you don't expose your users to liability like this without informing them clearly and making it opt-in.

The reason they reverted the commit as soon as they got _called_out_ is because bam they got CAUGHT!!

They though they could be smart and slip in a malware quietly without anybody checking, which was pretty bad executed because literally anyone can see the commits.

You don't just accidentally type in a full line introducing a malware that IS of common knowledge ("Oh sorry my fingers moved on my own! I didn't it was a malware!!"), that doesn't exist, there is no sugarcoating, this was absolutely evil intended, stop painting as clean innocent what is visibly dirty