Hacker News new | ask | show | jobs
by blowski 1737 days ago
Let's say I have a rule to block emails that mention "bitcoin" from arriving in my inbox. Is that censorship?

Let's say, so many people have set up a similar rule that the email provider offers a quick way of adding that very rule. Is that censorship?

Let's say, so many people use that "quick way" that the email provider turns it on by default. Is that censorship?

2 comments

Yeah, of course. How would it be possible to have censorship at all if "so many" people didn't tolerate it?
No, No, Yes. "Censorship" comes from the word "censor" - an intermediary who controls speech. Programmers need to stop assuming that every situation is scale- and convenience-invariant.
If the email provider says "Would you like us to add a set of rules people tend to add?", is that censorship?

There's a very fuzzy line somewhere, on one side of which a provider is helping users get what they want, and on the other is blocking content they don't want users to receive. I'm exploring where that line is.

While you have a right to send emails to me, I have a right to sign up for a service that automatically blocks emails I don't want to receive. The line is crossed when that service starts blocking emails I would like to receive. I'd say there is a pretty competitive market of email providers, and the rules are reasonably transparent about what's being blocked. Thus, it seems that "censorship" is a rather strong accusation here.

I would say the line has to do with how informed/empowered the user is about the initial content, ongoing changes, and their ability to make their own modifications.

The original comment was about text messages, of which there is certainly not a competitive market (the Ma Bell T-1000 has reassembled itself into only 3 remaining pieces), users were surprised at the behavior, and there doesn't seem to be a straightforward way to opt out of stupid rules like blocking whole TLDs. So it's a far way from being able to say that such blocking represents the will of the user.

What if users don't want to be informed, or make their own modifications? What if they just want a click a button and not receive junk mail, albeit also not receiving the occasional non-junk email because it had an unusual address.

I'd guess there are far more users like that, which is precisely why there are no major email providers offering the kind of service you talk about.

As always comes up in these conversations, while you have a right to speak, users have a right not to listen, and to use tools to help accomplish that.

You say you are "exploring where that line is", but then continue pushing a single sided view by conjuring some perfect user archtype who simultaneously has very strong opinions but also can't be bothered to express them. I know users are unreasonable, but completely discounting their agency does not make for reasonable analysis.

I've merely put forth a straightforward definition of "censorship" - one where there is a third party censor who controls the content of speech.

To translate your scenario into an earlier time - if most people in a society don't want to hear thoughts that conflict with the teachings of the church, and they appoint someone to an office to approve play manuscripts before they're performed, is that censorship?

If merely labeling centralized user-uninvolved content filtering with the technical term of "censorship" makes you uncomfortable, then perhaps you need to revisit your own assumptions.

Have you ever thought you might be wrong? Go and talk to the nearest non-technical person you can find and ask them whether they’d consider it censorship. It seems you’re in for a surprise.
> Programmers need to stop assuming that every situation is scale- and convenience-invariant.

I’ve seen it termed the “All Ns are equally likely” fallacy. I.e. when programmers write code, they know that they should write different code for when N is 0, for when N is 1, but as soon as it goes higher, most programmers tend to write code which is optimized for arbitrary values of N, even though in actual practice N might almost always be, say, at most 10. This often leads to inefficient and overcomplicated code, where a simpler algorithm might be faster most of the time while still able to correctly, if more slowly, deal with non-typical values of N.