zlacker

> If SpamBot2000 shows up and starts flooding groups, one command is all it takes to wipe out the spam. Where it gets trickier is if someone releases an NNTP client that has legit users but which can be turned into a spambot, like via scripting features. At that point users would have to make the call themselves, or the client devs would need to find a way to limit how much damage a scripted client can do

At which it comes back to not allowing anything but the most locked-down clients, and disempowering users... and still failing, bcecause all clients can be turned into spam bots with the most trivial application of autohotkey et al.

>>yjftsj+(OP)
It's all built in chains:

- The OS can trivially expose to the app whether events are coming from real hardware or another app, information the app can then either report or not report.

- The attested user-agent string given can be extended to include information about any scripts that are driving it, e.g. script hashes.

And so on. Then these things can have reputations computed over them. If there's a script hash that shows up reliably in spam, and never shows up in ham, then you can auto-mark those posts as spam. If the scripts aren't known then messages can be throttled until enough users have voted on whether the messages are spam or not. All this is fairly straightforward to code up, again, in a theoretical world in which operating systems expose information like whether events are emulated or not (today they don't).

The trick is that clients don't have to be locked down. The tech is fundamentally about letting you prove true statements. Those statements can be as complex as needed to allow whatever level of customization and control is desired. The more malleable clients are the more complex it becomes to determine what is and isn't considered OK, but in a decentralized system that policy complexity is up to the end users themselves to decide. They can share logic in the same way USENET users used to share killfiles.

Anyway, my point isn't to try and design a full system here. It's research level stuff. Only to point out that this stuff brings spam/abuse control out of BigTech-only world back into the realm of small scripts that can be written and shared by users in a decentralized way.

>>mike_h+Aa
> If there's a script hash that shows up reliably in spam, and never shows up in ham, then you can auto-mark those posts as spam. [...] All this is fairly straightforward to code up, again, in a theoretical world in which operating systems expose information like whether events are emulated or not (today they don't).

And in a world that has zero outliers or unusual users. In reality, I guarantee my accessibility software would get flagged as emulated input (because it is) and marked as spam.

>>yjftsj+jc
Then maybe we can also take into account whether the emulated input comes from remotely attested assistive technology. Yes, this will have the effect of at least restricting third-party assistive technology, but we have to keep in mind what's best for the largest number of people (including disabled people who aren't hackers) in the big picture, rather than taking an absolutist stance on hacker freedom.

>>yjftsj+jc
Again, it's all chainable. If an app is being controlled by accessibility software, the identity of that software can show up in the RA, so readers can say "it's OK if this app is automated as long as it's by something on this community maintained list of genuine accessibility tools".

>>mwcamp+uk
That makes the tech far more expensive because you introduced useless overhead without gaining anything relevant.

You didn't protect non-tech savvy users at all, on the contrary, you introduced a point of failure for their devices. Some have customized ones which would need to be verified. Doesn't sound like a good idea at all.