asap

joined 1 year ago
[–] asap@lemmy.world 3 points 1 week ago (1 children)

If they're running their own LLM hardware, and their Lemmy spam posts are generating enough revenue to cover that, then I take it back, because that is impressive.

I guess we're fucked.

[–] asap@lemmy.world 2 points 1 week ago (2 children)

I'd actually prefer that. Micro transactions. Would certainly limit shitposts

[–] asap@lemmy.world 2 points 1 week ago (3 children)

Must be strange to live in a world where you can't imagine that software could have configurable parameters, such that you could find something that's fine for a person posting individual comments and painful for a bot farm.

[–] asap@lemmy.world 5 points 1 week ago* (last edited 1 week ago) (5 children)

It seems like a no-brainer for me. Limits bots and provides a small(?) income stream for the server owner.

This was linked on your page, which is quite cool: https://crypto-loot.org/captcha

[–] asap@lemmy.world 6 points 1 week ago* (last edited 1 week ago) (7 children)

How much resources are we talking about here? If it's 3% of your CPU usage for 2 seconds, you're really going to have an issue with that?

Whatever solution should be negligible for you, but costly for a botfarm.

Here's a live example, not exactly onerous: https://demo.mcaptcha.org/widget/?sitekey=pHy0AktWyOKuxZDzFfoaewncWecCHo23

(Obviously in Lemmy's case you wouldn't have the additional unecessary checkbox)

[–] asap@lemmy.world 23 points 1 week ago (31 children)

Add a requirement that every comment must perform a small CPU-costly proof-of-work. It's a negligible impact for an individual user, but a significant impact for a hosted bot creating a lot of comments.

Even better if you make the PoW performing some bitcoin hashes, because it can then benefit the Lemmy instance owner which can offset server costs.

[–] asap@lemmy.world 1 points 1 week ago

Very true. The discussion helped me, as I did think it meant not easily editable.

As root of course you can change the system to be any other type of system (layer packages, rebase, whatever), but I did assume it meant not easily modifiable in it's current state.

[–] asap@lemmy.world 1 points 1 week ago (2 children)

My comment in the comment chain was:

An attacker escaping from a container can't be system root as Podman runs rootless (without some other exploit or weak password).

We could give the op the benefit of the doubt and thinking that they were saying that the attacker inside the container managed to gain root inside the container.

[–] asap@lemmy.world 1 points 1 week ago (4 children)

While you are correct, any system is compromised if you have root, so isn't that irrelevant at that point?

[–] asap@lemmy.world 3 points 1 week ago

Makes sense. An "immutable" distro provides no additional security benefit, however CoreOS does have a reduced attack surface area compared to other distros, which itself is a benefit.

[–] asap@lemmy.world 1 points 1 week ago* (last edited 1 week ago) (10 children)

edit: "Immutable" means "all of them are the same", not "unchangeable".

~~You sound confident, but the fact that Fedora is using the term "immutable" makes me wonder if you actually have domain expertise here.~~

~~Immutable means immutable. It would be strange for them to call it that if it actually means "completely irrelevant from a security perspective".~~

~~Unless you provide some evidence to the contrary I'm going to assume you aren't correct.~~

[–] asap@lemmy.world 0 points 1 week ago* (last edited 1 week ago) (12 children)

They 100% can.

An attacker escaping from a container can't be system root as Podman runs rootless (without some other exploit or weak password).

The filesystem itself is also read-only.

/dev/nvme0n1p4 on /sysroot type xfs (ro)
/dev/nvme0n1p4 on /usr type xfs (ro)
/dev/nvme0n1p3 on /boot type ext4 (ro)
view more: ‹ prev next ›