zlacker

In your experience where?

No research has been done about whether shadow moderation is good or bad for discourse. It was simply adopted by the entire internet because it's perceived as "easier." Indeed, for platforms and advertisers, it certainly is an easier way to control messaging. It fools good-faith users all the time. I've shared examples of that elsewhere in this thread.

>>rhaksw+(OP)
I think that you are reading this too narrowly. SPAMers etc are often in a hurry. For example, simply avoiding responding for a second or two to an inbound SMTP connection drops a whole group of bad email attempts on the floor while no one else even notices.[0] Another example: manually delaying admitting new users to a forum (and in the process checking for bad activity from their IP/email etc) seems to shed another bunch of unwanteds, and raising the cost a little with some simple questions on the way in, also. This point about small extra delay and effort deterring disproportionately bad behaviour is quite broad.

[0] https://deer-run.com/users/hal/sysadmin/greet_pause.html

>>DamonH+TN
In your cost/benefit analysis, you overlook the harms created by secretive actions. That's why I asked for details about your experience.

The internet has run on secrets for 40 years. That doesn't make it right. Now that everyone and their mother is online, it's time to consider the harms that secrets create.

>>rhaksw+AO
There are bad actors, and many of them are lazy/stupid. Their activity imposes a tax / harms on the rest of us. One way to minimise that harm to the good actors includes some mildly covert measures. The sendmail GreetPause is hardly a secret for example: it catches a common deliberate malicious protocol violation and is publicly documented. This is not unique to the Internet nor new; see also banking and personal security and so on.

>>DamonH+fP
This subthread started with a discussion about how "HN itself also shadow flags submissions" [1]. That's a slightly different form of moderation than the t.co delays.

Another commenter argued "Increasing cost of attacks is an effective defense strategy."

I argued it is not, and you said adding a delay can cut out bad stuff. Delays are certainly relevant to the main post, but that's not what I was referring to. And I certainly don't argue against using secrets for personal security! Securitizing public discourse, however, is another matter.

Can you elaborate on GreetPause? Was it to prevent a DDOS? I don't understand why bad requests couldn't just be rejected.

[1] >>37130143

>>rhaksw+vR
Here's another reasonable summary:

https://www.revsys.com/tidbits/greet_pause-a-new-anti-spam-f...

I get several thousand SPAM attempts per day: I estimate that this one technique kills a large fraction of them. And look how old the feature is...

>>DamonH+qW
Okay, so the requests do get rejected, it just uses a delay to make that decision.

I don't consider GreetPause to be a form of shadow moderation because the sender knows the commands were rejected. The issue with shadow moderation on platforms is that the system shows you one thing while showing others something else.

Legally speaking, I have no problem with shadow moderation. I only argue it's morally wrong and bad for discourse. It discourages trust and encourages the growth of echo chambers and black-and-white thinking.

>>rhaksw+4X
How do you view the rest of typical SPAM filtering, where the mail is apparently accepted for delivery but then silently thrown away? For simplicity assume a system such as mine where I control the MTA and client, so no one is making decisions hidden from me as the end user who wants to get the ham and see no SPAM. (I get tens of ham per day and many many thousands of SPAM attempts.)

>>DamonH+CY
With spam email, the recipient has a chance to recover the mail by looking in their spam folder.

No such spam folder is provided to the public on social media.

>>rhaksw+5Z
Note that in the GreetPause case the SPAMmer will not see the rejection errors since they don't look at the response to their hit and run (ie no one gets to see any error, neither sender nor target), and a legitimate sender should never get the error, so even this may be messy by your criteria I think!

>>DamonH+v01
> even this may be messy by your criteria I think!

Only if the recipient sent a false response.

If the response were misrepresented then I would object to the technique. But it doesn't sound like that's what happens.

>>rhaksw+V21
OK, thanks!