Re: Excessively energy-consuming software considered malware?

[Christine Lemmer-Webber <cwebber@dustycloud.org>]

Taylan Kammer <taylan.kammer@gmail.com> writes:

> On 20.02.2022 11:05, Maxime Devos wrote:
>> 
>> Guix has a policy against including malware[citation needed 2], and
>> furthering global warming[3] (and energy prices[4], if [3] is not bad
>> enough for you) seems rather bad behaviour to me.
>> 
>> Would these miners be considered malware in Guix?
>> 
> I'm not a fan of cryptocurrencies at all, but I don't like the idea of
> excluding software from Guix on the grounds that it's harmful in some
> indirect way.
>
> Malware is software that harms/exploits the user without their knowledge.
> The inefficiency of cryptocurrencies was never a secret, though people
> didn't think much about it; recently it's become widespread knowledge, so
> I think considering crypto miners to be malware is somewhat unreasonable.
>
> An example of actual malware would be a *hidden* crypto miner that sends
> the mined coins to the author of the software.

I think that's a good analysis.  Software which installs a crytpo-miner
*without a user's knowledge* is a serious problem.

> If we're going to exclude software on grounds of it being used in harmful
> ways, I can already see people arguing that one should exclude software
> such as aircrack-ng for aiding in breaching into networks, or anonymity
> software like Tor because it aids perverts in sharing you-know-what or
> aids terrorists in planning attacks.  Slippery slopes and all.

I agree... I'm also conscious that it'll put Guix in a position where
this will be a large portion of the work that Guix is doing is screening
software on a very large number of grounds, whereas we already screen
software much more so than most places.  It could absorb a lot of our
energy.  It's easy to underestimate just how all-consuming this could
become.

I share criticisms of proof-of-work.  Though some of the criticisms
being raised on this list are treating "blockchains" and
"cryptocurrencies" as if they even were one coherent thing.  In reality
the variance space of this is huge:

  https://dustycloud.org/blog/what-is-a-blockchain-really/

You'll see plenty of my own criticisms coming up in there.  But part of
my issue is, it's worth being precise about what's being criticized.
For instance, "proof of stake" has other problems (arguably still has
plutocratic properties), but not the energy consumption issue.  Most of
the discourse contemporarily is acting as if both are the same.  But
even proof of stake based systems are often being built on top of
software that's being refactored from "proof of work".

I think this activism criticizing design choices along these lines *is*
worthwhile, but building alternatives and getting them adopted may be a
stronger choice.  I'd like to replace proof-of-work based systems
largely; there are under-appreciated directions that even predate
Bitcoin dramatically that are worth exploring.

Relatedly, the title of this is: "Excessively energy-consuming software
considered malware?"  That's broad enough that it could also put a lot
of emphasis on "don't use inefficient languages" (actually that's how I
misread what the subject of this thread originally before opening it).
That's worthwhile also, but similarly, is Guix's package repository
acceptance/rejection the right place?

> One might argue that those pieces of software also have good uses, but
> the same could be argued about a crypto miner: perhaps I want to install
> one simply to study its operation to aide in some sort of research, maybe
> even research about its inherent inefficiency.  Or maybe I want to devise
> a small-scale blockchain-based network for a niche use-case where the
> blockchain won't reach an unwieldy size or will be limited in lifetime.
>
> All in all, I think the baseline is that if something is software, and it
> respects the user's freedoms, it belongs in Guix.
>
> What do you think?  I'm happy to have my mind changed.  I've never used a
> crypto miner and continue to be disinterested in them so don't care about
> this particular case all that much, but the principle behind the reasoning
> bothers me somewhat.