Mastodon doesn't enable harassment by not giving information to harassers that have been blocked.
Mastodon is going to tell harassers that they have been blocked so that they know to find another avenue of harassment.
Read the release notes.
You can see the problem listed here: https://github.com/tootsuite/mastodon/releases/tag/v2.8.0rc1
yeah this "feature" is pretty unacceptable, and designed solely for the benefit of bad actors in the fediverse.
I agree that this "feature" has adverse effects, it doesn't solve or help anyone.
I can see why it was added (reducing confusion means fewer non-bug bug reports for the developers to deal with), but I do agree that telling people when they've been blocked isn't a good idea. I would feel safer if it would just ambiguously error out. I agree that this feature will help blockees and hurt blockers.
Edit: Here is the PR: https://github.com/tootsuite/mastodon/pull/10420 It's a change to a sensitive bit of the system, so at the time I was concerned that there were no screenshots or anything.
I am really not looking forward to people dunking on other people with screenshots showing that they got blocked, like they do on Twitter
"Lol I did this terrible thing and lol they blocked me" [screenshot]
the fact that some profiles don't load and some do is impossible to be
ambiguous about. the only time mastodon will refuse to show you someone's
posts is when you're blocked.
On Sun, Mar 31, 2019, 10:26 AM Cassolotl notifications@github.com wrote:
I can see why it was added (reducing confusion means fewer non-bug bug
reports for the developers to deal with), but I do agree that telling
people when they've been blocked isn't a good idea. I would feel safer if
it would just ambiguously error out.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/10433#issuecomment-478346665,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAORV6LvELvcKCJ0hPUfVBs2WHG08g4Gks5vcMWngaJpZM4cUTrE
.
Yeah but we don't have to give the trolls a screenshot
Please revert this change, it doesn't help anyone that we should want to help.
'It isn't perfect' isn't a reason to make it worse.
the fact that some profiles don't load and some do is impossible to be ambiguous about. the only time mastodon will refuse to show you someone's posts is when you're blocked.
A blank profile is still pretty ambiguous as to whether it's a block or if their posts were never there. A harasser can't easily get their kek on if all they have to show for it is an empty profile.
A better choice would have been to prevent blockers from showing up in the blockee's search results or the profile column altogether. You know. Completely vanish from their end. Because that's the goddamn point of blocking: the blocker doesn't want to be seen by the blockee, full stop.
I understand the issue this addresses, but another solution should be implemented as this is a huge help for harassers and as I see it will bring bad behavior we know from Twitter
Software shouldn’t lie to its users, and being blocked is important information. This allows users to reflect that they may have done something wrong and/or remind them that further correspondence is not wanted. Besides: There will always be pieces of information that give it away anyhow.
This allows users to reflect that they may have done something wrong and/or remind them that further correspondence is not wanted.
Plot twist. They never do. Twitter has proven this time and time again.
Adding my support to this. "YOU ARE BLOCKED" is like handing trolls a trophy.
It's already pretty obvious if you're blocked, so this barely changes anything.
Maybe don't block people and just mute them.
I mean a 403 forbidden when trying to follow someone only happens when you are blocked, so it is in essence a block message already. If anything blocking someone should make your profile invisible to theirs and vice versa.
The above arguments are why I initially designed the block feature in a way that would be impossible for the blocked person to tell they have been blocked. But the community insisted on a way to stop the blocked person from performing certain actions, and at that point the cat is out of the bag. If someone wants to favorite or follow and they can't, it's quite obvious what happened when they get a "403 not permitted" error. But not obvious enough that I don't regularly get bug reports from people and have to tell them "you have been blocked". You can't really hide that. That's why i personally only use the mute feature, for example, I don't want anyone to make a big deal about me not wanting to see them.
This change had the added benefit of hiding follower/following lists as well as posts from the web UI.
Before: blue follow button that says "not permitted" when you click it
After: greyed out follow button and "you are blocked" clarified before clicking
I agree with Gargron here, it's already possible to tell if you're blocked, now it's just a bit more intuitive.
This should be opt-in on the blocker side. I don't _know_ that a block indicator was part of what turned Twitter into hellsite, but I do know this was part of the debris falling over the cliff with it.
Maybe opted in blockers could provide a reason and possibly an alternate form of contact.
Edit regarding the UX for trying to figure out why you get the error: Shadowbans were invented for this purpose. Twitter goes too far with it. I'm currently in the box for...who knows. But a block could just make it look like the blocker hasn't tooted since the block. The blockee sees a profile frozen in time, possibly with a fake bio provided specifically for them.
You can't really hide that.
The point of a safety feature is to make it _harder_ to get around, if not completely impossible.
You know, like how any lock can be inevitably defeated, but that doesn't mean you should remove all the bloody doors. >.>
So making Mastodon "more intuitive" for harassers and abusers is a goal now?
One of the "stop the blocked person from performing certain actions" were types of harassment. I remember this one because people i had blocked were still able to follow me, boost my posts and expose them to all of their terrible followers. Which just brought in more harassment. A 403 message already tells them they are blocked. While mutes dont directly inform a user something has happened, its not hard to figure out when it happens.
Knowing you are blocked i dont think has a lot of hard incentives behind any particular behavior. Sure some people might post some screenshots that they were blocked but most will not. I have thousands and thousands of people blocked on twitter and thats large enough for a good sample size. Very few make a big deal about being blocked. The rest i never see or hear from again. Theres the occasional determined harasser but when you have a determined harasser you need stronger tools than blocking anyways.
403 is only used to indicate a block, so maybe use a different error code which means other things too. GitHub is purposeful in using 404 fir permissions errors as well because they feel that obscuring the accuracy of the error helps to reduce the attack surface for people trying to guess at things; maybe Mastodon could serve up a 500 (because instances go down) or 404 (yay troll you won now you can’t see them anymore) or something.
Yeah it sucks to have the wrong status code but what sucks even more is a culture of abuse and harassment.
Most status codes are to benefit humans; computers only really care about 200, 30x, and everything else.
Smart idiot: Smart enough to find out he's been blocked without explicitly telling him. But most likely he's also smart enough to refrain from killing me.
Stupid idiot: Doesn't understand all these 403s and 404s and most likely moves on to next victim due to boredom. But if he would know that he's been blocked because there's an in-his-face red sign, he most likely would come and kill me. Because he's a stupid idiot.
403 errors only appearing when you are blocked isn't a reason to make it easier for people to tell if they are blocked, it is a reason to change that behaviour. This is a consistent message from anti-harassment people, you don't give information to harassers.
Blocks shouldn't give in your face indication that you've been blocked it should be silent and indistiguishable from resource not found.
If you block someone your profile should be from their perspective gone.
404 Not Found therefore it is just like the resource is gone.
I think the most sensible solution would be to completely remove blocks and get rid of this hassle. The block feature is finicky anyway.
Mute works for most cases. Instance wide suspension of the user for the edge cases.
this is a pretty bad regression bug, i can't believe it wasn't caught earlier
@haleyashleypraesent I disagree. Shadow banning/blocking is a way bigger issue than dedicated harassers being able to see if someone has blocked them.
@haleyashleypraesent I disagree. Shadow banning/blocking is a way bigger issue than dedicated harassers being able to see if someone has blocked them.
@ealgase sorry but if I block someone I don't want them to easily figure out I've blocked them, I want it to look like my profile from their perspective is not found that way they're more likely to give up, my experience on other social networks is if the blockee knows they've been blocked they will often go to make other accounts, if they think my account is gone I don't thitk they're going to waste time making a new account just get around it.
@haleyashleypraesent I disagree. Shadow banning/blocking is a way bigger issue than dedicated harassers being able to see if someone has blocked them.
Server-side muting (which is what "shadow-banning" typically means) is outside the scope of this discussion.
From discussions I've had and overheard, the ideal approach seems to be:
In general, does that seem accurate?
A better choice would have been to prevent blockers from showing up in the blockee's search results or the profile column altogether. You know. Completely vanish from their end. Because that's the goddamn point of blocking: the blocker doesn't want to be seen by the blockee, full stop.
I have often wondered why this is not the usual way it works! I'd be up for this. I want the blockee and I to be totally removed from each other's social media experiences, like they were never there for me and vice versa.
Shadowban >>>>> error message > block notifications.
Shadowbanning can be difficult to implement (show the asshole only whatever posts they've already viewed so it just looks like the person stopped posting? which means you need to store that info somewhere for all users? ??? or show a blank profile? or make it look like the target deleted their account?) so I get not going that route, at least yet.
That's absolutely not a reason to add a feature solely to the benefit of assholes.
The error message is obviously superior. There's plausible deniability. It takes more effort to confirm. It may be harder to tell if the person you're bothering blocked you or the instance admin did.
Revert this change. Twitter already does this. And it's bad.
@matrix07012
I think the most sensible solution would be to completely remove blocks and get rid of this hassle. The block feature is finicky anyway.
Mute works for most cases. Instance wide suspension of the user for the edge cases.
This is probably something to open a new issue for? I don't think it really fits here.
All this change does is improve general usability. It's trivial to find out if you've been blocked by just attempting to follow someone and seeing if you get a 403. Anyone who thinks this change somehow enables harassment has been lulled into a false sense of security by the current (broken) system which IMO further proves this is a good change since giving people a false sense of security is much more dangerous than simply doing nothing.
Please don't give the trolls a screenshot
Even if "they can figure it out"
Don't give them the "blocked" screenshot
We don't need that coming in from Twitter
I _strongly_ support using a Github-style "access denied becomes a 404" model, from a standpoint of reducing information leakage. In the case of Github, that is "if I can't access user/repository
, I don't get a 403, I get a _404_, which doesn't leak the existence of the repo"; in our case, it's "if a user blocks you, it looks like they've disappeared.
Obviously, this is trivial to circumvent; look at that user outside your instance's webui and check that they exist! But, this is a better solution than _nothing_; it forms an activation barrier to drive-by trolls.
I have bigger takes about _Access Control On The Fediverse_, but this thread seems to be going in the direction I outlined in the first paragraph anyway, minus a small amount of chaff messages going in circles.
I tentatively agree with @joyeusenoelle, but I have to add:
Are we just assuming everyone who has ever been blocked is an abuser/harasser/asshole?
When Randi Harper blocked trans activists on Twitter and it traversed through the blocktogether thing, were those trans activists the abusers/harassers/assholes? Would it have been better for everyone if those activists would not have been able to tell that they have been blocked by random strangers, because the UI would just glitch out?
And on Mastodon, we encourage people to block anyone they don't like to avoid conflict, and we have mods weeding out the worst abusers and harassers who break the rules, so I think there's a lot of everyday, average people blocked by someone, somewhere, that aren't necessarily bad people. So framing this discussion as trying to make something more intuitive for harassers is disingenious.
The Randi Harper issue is because Block Together was a terrible hack on top of shitty moderation controls. Mastodon has much better moderation, at least on the smaller instances, and the fact people get suspended for abuse makes Block Together unnecessary. Any comparisons with that are, IMO, invalid or at least specious.
We need an ecosystem where Block Together never becomes necessary in the first place.
Are we just assuming everyone who has ever been blocked is an abuser/harasser/asshole?
Honestly, those are the main cases worth discussing, because the people who are decent human beings acting in good faith probably won't be the ones we need to worry about in terms of deliberately acting badly.
So please don't characterize this sort of discussion as "disingenuous." It's a legitimate concern.
There is an "import blocks" function and an API that allows managing blocks, there are third-party apps that block everyone who interacted with a specific post, so there is definitely a potential for BlockTogether-esque situations to occur. But I think you are missing the point. Even if Randi's blocks didn't propagate, the act of her blocking those people wouldn't make those people assholes.
There's a culture of posting "blocked" screenshots on Twitter, because the technology allows for this
In some contexts, if you can show that you provoked someone so much that they blocked you, this counts as a point in your favour and you get to dunk on them by posting the "blocked" screenshot
And I'm just saying ... Can we please not?
@Gargron Absolutely there are people who've been blocked who are good people. I've been blocked and I try very hard to be a good person! I agree that framing this change as implemented in the PR as an attempt to make things more intuitive for harassers isn't the correct framing; of course nobody is trying to make things easier for harassers.
But a lot of people on the Fediverse, and especially on Mastodon, are coming at every change from the perspective of "how does this help reduce harassment?".
Sometimes the answer is "it doesn't and it's not supposed to". Sometimes the answer is "it doesn't but it could be done differently and better", and that's the case here - and sometimes, when that's the case, people take the change to mean "I've considered the better option and discarded it" rather than "the better option hasn't occurred to me yet".
It serves nobody well to pretend that Eugen wants to make things easier for harassers (and that has happened upstream in this conversation, so let's not be hasty in dismissing it). But now that we know that there's a better way to handle this, let's handle it that way.
@Gargron Alright, a feature for people who might be okay users most of the time but are much much more likely to be assholes (they bothered at least one person enough to be blocked, after all) and to the detriment of people doing the blocking.
Is that accurate enough for you? It's still not the constituency you want to build software for.
As long as the blocking person has posted any public posts, I am not sure how pretending the profile to be empty or non-existing would prevent a block from being trivially discoverable:
You can still just open the public profile page of a user on their home instance. You can even subscribe to their public posts via RSS or Atom!
This kind of blocking can only serve to make interactions impossible for a blocked user, and for that case clear error messages/ status codes make sense. As long as each profile is still publicly accessible via https on their home instance, blocked harassers can just post 2 screenshots – one of the empty profile and one of the public profile page – instead of a single "You have been blocked" screenshot.
So IMHO these new changes make sense, as everything else would just create a false sense of security.
As long as the blocking person has posted any public posts
Not everyone has public posts, and even for people who do, we don't need to automate a potential bad actor's work for them
blocked harassers can just post 2 screenshots – one of the empty profile and one of the public profile page – instead of a single "You have been blocked" screenshot
This is way less of a punch-line, if you have to explain it or correlate two images together
everything else would just create a false sense of security
People who are targeted for abuse are very well aware of how abusers can navigate the system and circumvent anti-abuse tools, generally
@schmittlauch These issues have been brought up and addressed upstream in this very conversation.
Look, I reflected what another contributor had stated - that the 403 result is equivalent to this change, but this was "more intuitive".
While it may not have been the _intention_ to deliver a better UX for harassers, that's what this does. And this happens, over and over and over again. There are dozens, more, people with experience and valuable info on how harassment occurs, and the types of tools that can be deployed to prevent this who have attempted to contribute. And they are ignored, over and over and over again.
At some point, the continued delivery of harassment-capable tools, and the continual failure to listen, to consult, with people who can add value to the discussion, leads to an inescapable conclusion.
blocked harassers can just post 2 screenshots – one of the empty profile and one of the public profile page – instead of a single "You have been blocked" screenshot
This is way less of a punch-line, if you have to explain it or correlate two images together
In the scenario where the profile appears deleted, it would be "Look, they lost the argument so hard they deleted their account", would it not? This is a having cake and eating cake type of situation. You can mute, and then the person has no idea they've been muted and has no ammunition to use that fact. But they see your profile and content and can follow you and boost and favourite. Or you can stop them from following you and seeing you and boosting and favouriting you, but there is no way to do that such that they would not notice it happening, giving them ammunition to make a fuss about it.
In the scenario where the profile appears deleted, it would be "Look, they lost the argument so hard they deleted their account", would it not?
No that's not a thing. Nobody does that.
In the scenario where the profile appears deleted, it would be "Look, they lost the argument so hard they deleted their account", would it not?
It's about escalation vs. de-escalation, though, isn't it? Like, YOU'VE BEEN BLOCKED is more escalating than "HA! Behold, evil followers! The target of my harassment has made it IMPOSSIBLE FOR ME TO LIKE, BOOST OR REPLY TO THEM!!!! VINDICATION!"
"You've been blocked" is confrontational, aggressive, more likely to make someone feel righteous, outraged, and other harassment-triggering feelings, etc. "Oh no I seem to be unable to interact with someone and there's no satisfying visual to go with it" is more of a... pathetic fizzle, ie: de-escalation. De-escalation is less likely to lead to someone getting hurt.
Honestly, if it's just looking at the costs and benefits to _users alone_ I can't see how this is a hard choice. If you opt for the pathetic fizzle, nothing really bad happens to good people, _and_ life is less good for trolls. Is the main motivation that the devs don't want to have to deal with bug reports when people get blocked and are confused by the error message? Because if so, I think there are a bunch of clear and honest error messages that have already been asked for on this issue list.
Edit: "You've been blocked" is like shoving someone in the chest to get them to back off, whereas updates-and-interaction-disabled is like just walking off and leaving them to yell at a tree. It is pretty clear which one leads to confrontation and fighting and your mates piling in, right?
I mean, we could change the message if that's the problem. Perhaps "you've been blocked" is too confrontational indeed--it could just become "You are not permitted to view this profile"
I mean, we could change the message if that's the problem. Perhaps "you've been blocked" is too confrontational indeed--it could just become "You are not permitted to view this profile"
Making the exact wording less confrontational is better, but it still doesn't really address the root cause.
A specific error message would work a lot better if there was more ambiguity, to cut off that initial "rarrrrgh!!!!!" Because doubt kind of short-circuits the rage a bit, I think.
Like, maybe if there are other situations where a profile might say "you are not permitted to view this profile". Domain blocks? An admin has suspended a user from another instance? Something that adds an element of "this might not be personal, maybe it was someone else that did the thing instead of this individual choosing to block me, I don't know whether to be angry at this individual." And then the rage dissipates.
Edit: And if you post a screenshot of that, it definitely fizzles rather than escalating, because while you're posting it you're thinking, "well someone could say 'maybe it's a domain block' or something, and I wouldn't be able to prove otherwise."
In the scenario where the profile appears deleted, it would be "Look, they lost the argument so hard they deleted their account", would it not?
That does happen, but it's actually considerably more rare. "Alice blocked me!" can't be gainsaid except by Alice re-engaging, because nobody can see the block but Alice and Bob. But "Alice deleted her whole account" can easily be gainsaid by Eve, one of Alice's supporters, who can say "uh, no she didn't, she's right there".
The second actually loses face for Bob, because at that point either Bob looks dumb or Bob says "well, uh, at least she blocked me?" and since all of Bob's supporters were expecting an account deletion, a mere block is just a letdown.
Domain blocks? An admin has suspended a user from another instance?
In those situations, the API returns a 410 and the account is not shown. I guess we could do the same. It's not perfect wrt. bogus bug report, but no solution that attempts to make the block non-obvious will be. Together with filtering blocking users from search results, this should also limit exposure to those accounts in the first place. Mentions to those people would still link to their profile (which would error out in the web interface) though, so it'll still be easy to find out that you're blocked (or they are blocked instance-wide).
Domain blocks? An admin has suspended a user from another instance?
In those situations, the API returns a 410 and the account is not shown. I guess we could do the same. It's not perfect wrt. bogus bug report, but no solution that attempts to make the block non-obvious will be.
That sounds good. It means the first thing someone will do if they see that error is go to their admin, who is in control of domain blocks and user suspensions, which isn't great for the admins but it's more appropriate than bug reports to the developers. (Edit: As long as the error message suggests an admin decision rather than a bug.)
Also, if the blocked person thinks they might be unable to see an account because of an executive decision their admin made, rather than a bug, they are probably less likely to ask the admin to reverse a past decision? They might also be less willing to speak to the admin out of pride, in case the admin says "oh it's not my fault, sorry, you've been blocked" and then the user feels silly. The user might also not want to risk having admin attention drawn to them having been blocked in case the admin is like "I'll keep my eye on this one." 🧐
Are there words that go with 410? Like, 410: account not accessible
, or something?
410 Gone
making the blocked profile show a 410 gone instead is a great compromise solution to absolutely refuse to listen to the concerns in this thread and simply uphold your change stubbornly no matter whether that change is a deliberate message or an http code just because you want to implement feature creep
"it's already easy to tell when you're blocked anyway" tell me one good reason to fix what isn't broken then instead of adding more feature creep into an already bloated piece of software Just Because
"it's already easy to tell when you're blocked anyway" tell me one good reason to fix what isn't broken then instead of adding more feature creep into an already bloated piece of software Just Because
Because it _is_ broken. When someone clicks on someone's profile and sees a 404 error, they think it's an issue with Mastodon. If they open the profile in a new tab and see it still exists, they get even more confused.
@ealgase Bob clicking on Alice's profile and seeing a 404 Not Found error is not the current behavior. Currently, Mastodon returns a 403 Forbidden if Alice has blocked Bob (which shows up in the web interface as simply a failure to load the profile). The PR under consideration simply replaces the 403 with a "You're blocked" message in the web interface.
e: vvv I stand corrected.
No, the "current" (2.7.4) behaviour is that the profile shows, with a clickable follow button, just no toots. No errors. Error 403 appears when you click follow.
Do you realise the solution I was talking about is basically the one which was massively upvoted here? https://github.com/tootsuite/mastodon/issues/10433#issuecomment-478361985
Le 1 avril 2019 00:08:13 GMT+02:00, Erin Pinheiro notifications@github.com a écrit :
"it's already easy to tell when you're blocked anyway" tell me one good
reason not to fix what isn't broken then instead of adding more feature
creep into an already bloated piece of software Just Because--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tootsuite/mastodon/issues/10433#issuecomment-478389908
--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Making blocks function as a "this person never existed" button isn't exactly a new concept. It's one thing that Failbook actually got right.
Since people have already bikeshedded like 50 comments after it was posted, again, here is the solution:
From discussions I've had and overheard, the ideal approach seems to be:
Revert this change.
When Alice has blocked Bob, and Bob seeks out Alice's profile in the web interface or logged-in API, instead, serve the "profile not found" error that occurs when Bob tries to open a nonexistent profile. (This may simply entail serving a 404 error.)
When Alice has blocked Bob, and Bob uses the web interface or logged-in API's search function, remove Alice's account from the potential search results.
When Alice has blocked Bob, and Bob attempts to mention Alice in the web interface or logged-in API, remove Alice's account from the auto-complete, and do not resolve Alice's account if Bob types it out in full.
I think that @barzamin 's solution is the correct one here, for what is perhaps a somewhat philosophical reason. When one is accessing the Fediverse from a particular instance logged in as a particular user, that is one view of the Fediverse, and from that view, _users who have blocked you should not exist_.
Yeah, that was my intent, and what I suggested is nearly identical to @joyeusenoelle's plan, and also what @ThibG suggested, with the caveat that where @ThibG suggested a 410 Gone, I think a 404 "this profile isn't available" is more appropriate if a user somehow manages to access it, and not show said profile in the UI otherwise (eg in search results).
This maximizes plausible deniability; there are about four different reasons I can think of (domain blocks, suspensions, personal blocks, not existing/deletion) that such a message would occur, and would _put liability for helping instance members onto the admins of the instance_, which is (imo) where it should ideally be in the first place.
Also note that error copy makes a huge difference here! You could even do something vaguely friendly like "404: We can't find this profile for you (perhaps it doesn't exist?)".
Ultimately we're playing a game of psychological manipulation and denial of access against unknown adversaries, which nominally sounds really bad (I mean, we're basically gaslighting people into doubting the actual state of an account), but this _externalizes the actual poking of things_ to the user of an instance being confused or putting in the effort to be like "hey admin whyn't this working!!1!" instead of just creating accounts and ban-evading, lol.
Ultimately we're playing a game of psychological manipulation and denial of access against unknown adversaries, which nominally sounds really bad (I mean, we're basically gaslighting people into doubting the actual state of an account), but this externalizes the actual poking of things to the user of an instance being confused or putting in the effort to be like "hey admin whyn't this working!!1!" instead of just creating accounts and ban-evading, lol.
This is my main problem. We're breaking some part of federation for... what benefit? Preventing certain people from getting satisfaction and making them spend ~10 seconds more? Not worth it, especially as, under what you just suggested, it would require server admins to do more work.
This is my main problem. We're breaking some part of federation for... what benefit? Preventing certain people from getting satisfaction and making them spend ~10 seconds more? Not worth it, especially as, under what you just suggested, it would require server admins to do more work.
Understand, please, that your "not worth it" is many others' "absolutely worth it". Worthwhileness is not an objective trait.
There are objective reasons to have concerns about the suggestions being made here. Many of them have been made above. But declaring that an approach is "not worth it" is not useful to the debate; it's a perspective that presents no arguments for others to attach to.
Also, this isn't "breaking federation" (whatever that means anymore ([1][2]) because posts are still federating if they need to be federated (you know, like if there are still unblocked users on that instance).
They're just getting hidden from the people who the author of those posts have blocked.
[1] It sounds like a cultish buzzword at this point, seriously.
[2] It's not some inalienable right to see or speak to another person if they don't even want to give you the time of day.
I for one think joyeusenoelle's solution is ideal.
A note on 404 vs 410: this wouldn't change anything to what a typical user would see, but if they start digging into it, 404 would currently only happen when someone deletes their account (or they get suspended from their own account), and in no other situation. So a person getting a 404 would know with certainty that they have been blocked, since checking whether the account still exists is pretty easy. A 410 currently happens when the profile being viewed is blocked instance-wide.
Hm, it seems properly “hiding” the account (returning a 404 or 410) will be more difficult and expensive than I thought.
The reason for that is that a blocked account should never reach the client ever, but account information is serialized in a lot of different places, and up until now, there was no receiver-specific decision as to whether that information should be serialized or not.
Adding that filtering will necessarily add some cost, and any place we forget to do that filtering will reveal the blocking situation. I will try to do it, but I'm not too sure that's worth it (hiding from search results and compose suggestion is easy and not very expensive though).
Also, this isn't "breaking federation" (whatever that means anymore ([1][2]) because posts are still federating if they need to be federated (you know, like if there are still unblocked users on that instance).
They're just getting hidden from the people who the author of those posts have blocked.
What I mean by this is that, since multiple things can cause a profile to have a 404 error, we're intentionally confusing users. One of those things that can cause a 404 error is a federation error.
[2] It's not some inalienable right to see or speak to another person if they don't even want to give you the time of day.
Exactly, but you should be able to know they exist and the reason you can't see their stuff is because they blocked you, not because of an issue in the software or protocol.
you should be able to know they exist and the reason you can't see their stuff is because they blocked you,
Why? We've seen what that leads to on twitter. You don't have some sort of entitlement to know that you've been blocked.
Why? We've seen what that leads to on twitter. You don't have some sort of entitlement to know that you've been blocked.
Keeping the interface understandable is worth more than removing a bit of satisfaction from a troll.
Keeping the interface understandable is worth more than removing a bit of satisfaction from a troll.
@ealgase Understand, please, that this is a philosophical position and not a factual axiom. Other people hold the opposite position, and it's equally valid.
Moreover, "if you've been blocked by Alice, Alice no longer exists as far as you're concerned" is understandable. What you seem to want is for the software to be accurate in its description of events, and that isn't always desirable. My car will continue to drive for about 50 miles after the fuel needle goes below the Empty marker; strictly speaking that means it's not accurately reporting my fuel level, but in this case the practical value of offering a buffer outweighs the desire for accurate reporting. Similarly, the practical value of not offering a traction point to harassers, as far as many users are concerned - you can see them expressing this in the conversation above - outweighs the desire for the software to accurately report the blocking status.
User safety is worth a hell of a lot more than protecting a troll's fee-fees.
You can cite software "rules" all you like, but the reality is that they don't universally apply to every situation and exceptions _are_ going to have to be made.
This issue has been addressed in https://github.com/tootsuite/mastodon/pull/10442
We might revert #10442 unless someone has a better idea. Indeed, hiding accounts who block you prevents you from blocking them, which means that whoever blocks the other first gets to decide exactly when the block ends. I think this is a pretty serious regression, and arguably more serious than displaying a bit of information telling whether an account is blocking you.
Unlocking this issue becase the solution of "hide me from the person I blocked completely" turned out to not be such a good idea given that it takes away the other person's ability to block back
Why not just have the block take effect both ways automatically?
There are implications to that that I don't like. Users sometimes get blocked by other users without ever having interacted with the second user, and forcing blocks to be two-way removes the possibility of someone saying "I'm sorry you have a problem with me but I have no problem with you". Moreover, many people use blocks in anger, fear, or upset, and regret the decision later; reciprocal blocking means that they can't rectify the problem.
I think there is a solution to this that doesn't require fully reverting #10442 but also gives the response that people have looked for upstream. A 410 is served on two occasions:
1) When the server has suspended a remote user
2) After #10442, when the remote user has blocked the viewing user
In both cases, we can safely serve a minimalist user info panel through the web interface, consisting solely of the remote user's username and the "hamburger" menu, which only allows the ability to mute or block the remote user.
That way there's still no "this user has blocked you" trophy, and you can't tell the difference between "this user is suspended" and "this user has blocked you" (and, if you don't look at the headers, there's little difference between this and "the server is having trouble fetching that user info").
Does that make sense?
This makes perfect sense, and sounds like a great idea! (Of course, there may be other implications to this I haven't thought of, just like I never considered the possibility of being unable to block back.)
What about having an option in Preferences that offers a single input box for a username and Block/Unblock buttons?
I mean, if one's vindictive enough to block back, surely they'll either recall the username off the top of their head or be able to copy-paste it from somewhere.
I could see that in addition to the profile-with-only-block solution, but if you didn't have any way to block them except by remembering their username I'd be a little worried about this scenario. I don't know how likely this is or if it would be at all practical, but...
_Edit:_ Although now that I think about it, I don't know what good that would do you, since you couldn't see any of Alice's future posts because you blocked her. Unless I'm misunderstanding blocking, and you can interact with people you've blocked.
_Edit 2:_ But then Troll could probably come along in the future, unblock Alice, say more nasty things, and then immediately reblock her. _Hm, that probably wouldn't help, because then she would see the username._
_Edit 3:_ Or Troll could just sneakily unblock Alice and silently observe. But Alice has no idea she's been unblocked, so she makes no attempt to block Troll.
There's always the email notification, if those are enabled.
Email notification of what? Does it send an email when someone blocks you?
...email notification of the Troll's mentions. >.>
Don't those happen only if you haven't logged in for a while? Or is there a setting to get mailed about _every_ mention? That sounds like it could get overwhelming fast.
You can set your account to email you whenever you're followed, requested, boosted, faved, or mentioned (and it's configurable for any combination of those) regardless of whether you've logged in recently, as well as the option of a "digest" email that only gets sent if you haven't been on for a while.
It could get overwhelming if you just leave it all to sit in your inbox, but it's also possible to filter your mail and have it moved to a specific folder on arrival. :)
Ah, that's good to know! Well, I had no idea that option even existed and wouldn't want it on anyway. So assuming the ghost-troll scenario is actually a problem, let's provide some way to avoid it from within the UI. (:
Because it seems that it's not obvious why being unable to block someone back is an awful regression (possibly because only good people ever block someone), let me outline a use case:
That's a lot of gymnastics just to avoid screenshotability of a short, reasonable message that disables the follow button and hides follower/following lists. I'd almost say "Okay, let's not show any message, only disable the follow button" except that it's a worthless sacrifice of clarity. In a system where networking issues are omnipresent, being able to tell apart bugs from intentions has value. Worthless sacrifice because as people in the thread mentioned, anyone who's been on Mastodon for some time is able to determine whether they are blocked just by the way the software behaves, which comes down to the dichotomy between blocking and muting that I have also outlined in a previous post upthread.
Do you have any concerns about the only-show-a-minimal-profile option @joyeusenoelle proposed above? It would both make it clear that it's not a network issue, and also keep it ambiguous whether the person blocked you or got suspended.
The blocked person would probably have an idea, of course, but it would lack the easy "look, they blocked me!" screenshot, since it would be ambiguous to _other_ people. And it seems to me that the "look, they blocked me" screenshot is the primary reason for not wanting to show a message (unless I'm misunderstanding this, in which case please let me know).
Because it seems that it's not obvious... snip
You just recited what other people have just been discussing and considering solutions for. Pay attention. >.>
I agree with Jo's idea. A manual block input would be useful for a lot more use cases than this.
I'm running the Master branch and ran into an issue yesterday where I needed to block someone who had blocked me, and was unable to find any way to block them back since their profile would not load under any circumstances. As @Gargron mentioned, this can be particularly nasty as giving one party the agency for cutting off contact and not the other leaves open the possibility of abuse.
I definitely understand the concern about block trophy screenshots, but I would even argue that those are the symptoms of a problem and not the root of them. If you don't want block trophies to be a thing, create and be enthusiastically part of communities centered on kindness, setting and respecting boundaries, and acting in good faith.
I think a message _might theoretically_ be able to work, but only if it were worded _very_ carefully. We would probably need to keep the ambiguity, but then "this person either blocked you or was suspended" would likely be interpreted as "this person blocked you", since I would think blocking trolls is more common than suspension by an instance, if it's a troll sharing the screenshot.
If we said something to the effect of "there was an error loading the profile" combined with the minimal-profile idea, that would work on the minimal-information side, but it very well might make people think there's a weird network error going on instead.
Unfortunately, as nice as a message would be, I don't think there's a good solution for those issues. (Prove me wrong!)
@witcheslive Community kindness works wonderfully, right up until the point where a bad actor comes in from outside and starts attacking people. ): Of course we should handle them at the instance level, but we _also_ need user-level tools to deal with that sort of thing.
@SilverWolf32 right, but what I'm saying here is that leaving open a loophole that can be exploited for abuse is much worse than something that is the symptom of problems that cannot be solved by technical means alone.
@Gargron I agree that that's a bad scenario and one we want to avoid. That's why I suggested that 410 return a substantively different result from 404.
Another potential solution is to have Mastodon compile a list of the last N people who mentioned you, whether or not they've blocked you since - such that blocking you might remove their mentions from your notifications column, but not from the list - and allow the user to block/mute/follow from that list. (This has the added benefit of providing an additional feature for people who get lots of likes/boosts and don't want to cull them from their notifications.)
@witcheslive Yes, we are absolutely looking for a technological solution to a social problem here, and we would all, I think, prefer a social solution! Unfortunately, part of the issue is that as federation expands, so does the society associated with it, and it's impossible to prevent bad actors from joining that society. That problem is what the technological approach attempts to solve.
Hm, what if someone harasses/threatens you, but then you get a deluge of other mentions (perhaps you're very popular or are in a lively discussion) and they fall off the end of the list?
I agree that would be nice for other purposes though.
HTTP return codes are irrelevant to the ongoing discussion: If you're talking about showing a "minimal UI" (which the thing that sparked this issue was, in a way), you need the JSON to do it, so you won't be returning errors.
I think that reverting everything to how I did it, but rewording the "You are blocked" string to "Profile unavailable" would be the most optimal solution.
There is not a perfect solution to this.
@SilverWolf32 If you're getting so many notifications that your harasser always scrolls off the list before you get to it, odds are you're not actually noticing the harassment. And if you are, that's a case so far to the edge that we've reached diminishing returns by considering it.
@Gargron You don't have to serve JSON to provide the UI I'm suggesting. You just need a template for handling a 410 that uses session variables to populate the "username", "block user", and "mute user" fields. You don't need any data from the server beyond that.
Anyway. I have said all I have to say about this. You may take my suggestions or leave them. (Please don't @-mention me, as this will resubscribe me to the thread.)
imo the solution that seems most ideal is the one where you stop serving updates to that account, effectively freezing it in time and making it look inactive rather than invisible or outright telling you "you are blocked". if you consider email, your old inbox messages aren't affected when someone blocks your messages, so the analogous thing would be to retain all visible messages at the time of block and hide all new messages.
pro: it makes it effectively undetectable that someone has blocked you unless you manually compare the public page to the in-app profile (with no other side effects). you'd probably want to make the account appear locked or at least cause the follow button to look like "request follow" (since you can technically send a Follow, but will not receive an Accept Follow due to being blocked). you'd also probably want to error out any interactions with existing public objects, or maybe silently discard them idk
con: old messages remain visible, though this is no different than opening in new tab. could also be computationally a bit expensive (unless you store a max_id that each person is authorized to see and silently apply that filter?)
the simpler, lower-computation solution would be to genericize the block message so that it is indistinguishable from any other error. something like "no posts available" is less aggressive but still obvious that something is not normal. or you could simply revert both this and the "you are blocked" commit so that blocking profiles go back to being empty as if a loading error occurred
"Profile unavailable" sounds like it could be a workable solution...but I would still be worried about "look, they blocked me!" screenshots, since "profile unavailable" right after you harassed them is still pretty likely to be a block.
That would also affect the minimal-profile solution, although not as much since there's no punchline text.
The last-N-mentioners list sounds like a good idea. Anyone have thoughts on that?
Just silently maintaining a shadow state for every blocked person is an interesting idea. Everything is timestamped, right? Yes, we could probably just store a max ID/timestamp, possibly applying that filter when we get stuff from the database.
Does anyone else have concerns about this approach?
Just silently maintaining a shadow state for every blocked person is an interesting idea. Everything is timestamped, right? Yes, we could probably just store a max ID/timestamp, possibly applying that filter when we get stuff from the database.
A profile not updating is a common networking issue that you'll find in multiple troubleshooting threads on this GitHub. Furthermore, displaying old posts for the sake of ambiguity may run counter to people's expectations who might want to stop someone from looking at all of their posts, right now.
Oh, those are both very good points. Don't know how I didn't consider the networking-error issue.
profile not updating is a common networking issue
that's the implicit tradeoff being made here, though. this is fundamentally an issue of deniability vs. clarity, with "you are blocked" at 100% clarity and "frozen profile" at near-100% deniability. so the only question is, where along that spectrum should the optimal solution lie? since there is no perfect one.
in other words: do you want to deal with people not knowing they are blocked, or people knowing they are blocked?
"Profile unavailable" sounds like it could be a workable solution...but I would still be worried about "look, they blocked me!" screenshots, since "profile unavailable" right after you harassed them is still pretty likely to be a block.
I think at some point, we need to accept that people will just share these screenshots. It's not something that's really worth it to prevent.
A good reason to block someone is to keep them from rifiling through your shit. I mean, yeah, right click new window is always there, but having 0 control over at least some basic obstacles between a stalker and your corpus is not a very good idea.
Why not just have the block take effect both ways automatically?
It is already the case, to some extent. Blocking someone does not prevent you from seeing their toots if you look for them (and that's needed, otherwise the block-then-report workflow wouldn't work), but limits the interactions you can have with them.
In both cases, we can safely serve a minimalist user info panel through the web interface, consisting solely of the remote user's username and the "hamburger" menu, which only allows the ability to mute or block the remote user.
Serving a minimalist user info panel for a 410 is tricky because the client may not know stuff like the username at all. Also, without allowing people blocking you in search results, this is not very practical. If we do re-enable search results, that's already one difference in behavior with suspended users (who do not show up in search results).
What about having an option in Preferences that offers a single input box for a username and Block/Unblock buttons?
That would be a useful feature, but only to the extent you know the exact handle of the person you want to block, which might not be practical, especially if you have to deal with multiple people. Also, the current implementation assumes the blocked account is known to the instance, so we would either have to error out if the typed handle isn't known, or change things significantly. Which we could do, but would be a separate issue with a longer term resolution I think.
All in all, I think the best solution, at least short term, would be to revert both #10442 and the original PR that spawned this thread, even if I don't like the prior state very much as it was neither a good way to provide plausible denial nor a good way to avoid bogus bug reports :weary:
A good reason to block someone is to keep them from rifiling through your shit. I mean, yeah, right click new window is always there, but having 0 control over at least some basic obstacles between a stalker and your corpus is not a very good idea.
Are basic obstacles really worth sacrificing usability for everyone?
How much usability does this really sacrifice, though? If we don't load their posts and instead just show a blank profile, it still lets you block the user back and such, and if you're blocked, you really shouldn't be seeing their posts anyway.
@ealgase I'm talking about like, leaving your statuses before the block visible to someone you blocked, I think that is a really bad idea
Does anyone here opposes to us reverting both PRs, so that things behave like they did before this release candidate? That is, accounts will still show up, pretending they don't have toots, and you won't be able to follow them, but you'll be able to block, mute or report them (but not specific toots since they'll be hidden from you).
EDIT: Oops, I hadn't seen it had been reverted already in #10491
Shadow banning and ghosting. Both are insidious anti-solutions, and not the same as muting at all.
Muting makes the offender disappear from YOU - you never hear from them again, and this is good. All of their efforts at stalking or harassing fall on deaf ears, as it should, and without notice, their profile and history still appears when you peruse them, and so does yours, but it's like they are being Uber-ignored by you - again, as it should be. You see none of their posts unless you bother to proactively look for them.
The paradigm is the same as it is in firewalling, we know it is best to DROP packets rather than REJECT packets, in most cases, and for goodness sake, don't REJECT packets with a message, that just baits the troll leaving your box or network especially vulnerable to getting pwn3d.
If one must insist on taking the easy blanket way out and instituting an actual block (analogous to "null routing" the packets before they even reach the firewall), then it is most certainly not a great idea to say so with a message (go back and read my previous paragraphs above).
A 403 is comical. By definition, it is actually saying that you are in fact blocked - Google "403 forbidden", or "HTTP 403", and then read my previous paragraphs.
A 404 is a lie... Sort of, and hinges on the unethical, IMO, in the sense that although it is indeed a result of a resource not found, it is but for an artificially manufactured reason.
It's like advertising that the eggs in your farms cartons are laid by hens that are free from hormones - and that is a lie, not because it isn't true, but rather, because it's true by virtue of being illegal to inject commercial laying hens with hormones in the first place.
Therefore, I recommend that if one were to search for someone who had blocked them, that instead of receiving an intrinsic lie in the form of a 404 error, or a tell tale 403 error, which in fact is actually saying that they're blocked, that we instead hand them a real result - the same result that one would have returned to them on Mastodon were they to search for a non-existent profile... And that result currently is: A splash page that reads, "No results!". i.e., no HTTP Error code included with the result!
It's plain, simple, it's not a lie that breaks the notion of HTTP protocol, and gives no indication that the blocked account has in fact been blocked.
Here's another reason, and a particularly important one. Almost everyone commenting in this thread seemingly is of the opinion that accounts are only blocked for reasons related to harassment and stalking related offenses. Such is not necessarily the case - you might wish to proactively block someone who is actually a friend, classmate, relative, or neighbor, simply because you feel constrained to post freely in an environment where your profile is readily available to them, perhaps you're engaged in activities or involved in communities where you seek to keep those aspects about yourself private where those relatives, neighbors, classmates, or associates are concerned. i.e., for privacy reasons that are your concern alone...
As an example, if you were a whore, it might be prudent to block your mom from seeing any of your ads before you make any postings. Or maybe you just haven't come out of the closet yet and you don't want your dad to know about your same sex partner. There are thousands of use cases.
Now, a 403 (and even a 404 error probably) says, "yes the user exists!!!". And then the hunt for Red October begins. Not a pretty picture, when an adult child signs up, seeks out their parents' accounts to preemptively block them from seeing what the child isn't comfortable leaving laying around for their parents to see.
Another functional point on blocking someone is important, and gplus was wise to institute this methodology: all posts up to the point in the profile of the blocking party as it were, a/o the day the block went into place, will continue to suggest and indeed appear to the blocked person just the same as it always did, before the point in time that the block went into effect... Like a snapshot in time, with the profile of the blocking party appearing to be forever frozen (unless and until the block is disabled).
Finally, we get back to Shadow banning and ghosting. These are system-wide anti-solutions designed to thwart postings by people and bots, by virtue of hiding the fact that all of their posts system-wide have been moderated to dev/null, with the exception of when they themselves try to lookup their posts, in which case they will see those posts and hopefully think that the public can see them too.
This type of blocking methodology is commonly Incorporated at places like Craigslist and Reddit. I believe that although it is often a frustratingly effective measure against spammers and haters, these measures typically serve to work against legitimate folks who actually trigger those trip wires accidentally (especially when algorithms are used to institute these measures), and sometimes for a very long time before they discover having been wronged by the admins or robots of the system.
So yes, ghosting and shadow banning are different tiers at the system-wide level as opposed to those remedies of blocking and muting at a user to user level.
That's my two cents, thank you for taking the time to read and digest this reasoning.
I agree with @tallship that shadowbanning/ghosting are anti-solutions and inherently counter-intuitive, and thus I think #10491 was a bad move. I think the way the current system works assumes the blocker is the good guy and villainizes the blockee (that is the general sentiment I get from comments in this thread as well after briefly skimming it).
This happened to me recently. I followed someone whose toots I enjoyed (albeit I knew they had a volatile persona), and one day their toots stopped showing up. I checked their profile and was greeted with "Profile is unavailable." I assumed there was something wrong with their server, so I waited a day, but still same thing. I spent an hour troubleshooting, uninstalling my app, reinstalling, checking my desktop, until I realized "oh this is how Mastodon indicates you have been blocked." It hadn't crossed my mind that I had been blocked because I didn't think there was any reason I should be blocked.
I think making a liar of software is bad in general, and I also think software that makes assumptions on its user's ethics is ironically unethical. My 2 cents.
This happened to me recently. I followed someone whose toots I enjoyed (albeit I knew they had a volatile persona), and one day their toots stopped showing up. I checked their profile and was greeted with "Profile is unavailable." I assumed there was something wrong with their server, so I waited a day, but still same thing. I spent an hour troubleshooting, uninstalling my app, reinstalling, checking my desktop, until I realized "oh this is how Mastodon indicates you have been blocked." It hadn't crossed my mind that I had been blocked because I didn't think there was any reason I should be blocked.
This is what any tech related people will do. Or they just create shadow accounts on different servers to debug such things because the shout after a broken server. https://github.com/tootsuite/mastodon/pull/10491 is a bad decision and if more decision like this are made mastodon will fragment and forks will start to arise.
Or because the servers don't know about the blocks just DDoS each other until the network is overloaded.
Again, nobody is entitled to know they have been blocked.
Software not giving you that info even if it has it isn't really software “lying to you”. End-users aren't entitled to the full knowledge of the server software when this involves multiple users.
Or because the servers don't know about the blocks just DDoS each other until the network is overloaded.
Stop saying things like that, that makes no sense, there is no increase of load in any way because someone blocks you.
Again, nobody is entitled to know they have been blocked.
Software not giving you that info even if it has it isn't really software “lying to you”. End-users aren't entitled to the full knowledge of the server software when this involves multiple users.
I agree no one is entitled to know they have been blocked. I don't think entitlement was relevant to my point. My point is that showing "Profile is unavailable" is unintuitive to the end user, and if you are tech-inclined, you can end up spending more time than it's worth troubleshooting (funny enough, I found this Github issue trying to troubleshoot 😊). If I had known that I was blocked, I would have left it at that.
The current implementation is a bit weird. It gives you a 100% verifiable way to know you're blocked… but the wording doesn't make it clear that you are blocked. I think it would have been better not to display the info at all (thus leaving you with something like “The user hasn't posted anything”, which is wrong, and may let you think that there is an unrelated issue, much in the same way we have now, but at least wouldn't disclose you you're blocked… idk)
The current implementation is a bit weird.
That's the problem!
wouldn't disclose you you're blocked
Whats the problem with that? Security by obscurity is not an effective solution to a problem. This just encourages fake accounts to stalk people and try getting around it instead of just telling you the truth.
Mastodon tries not to be shady or do any of the weird and random stuff other platforms do but this is exactly this: shady and non trustworthy
The only real solution is for "tech related people" to get used to Mastodon doing things this way
I don't think this is a solution.
The current implementation _is_ a bit weird. It gives you a 100% verifiable way to know you're blocked… but the wording doesn't make it clear that you are blocked. I think it would have been better not to display the info at all (thus leaving you with something like “The user hasn't posted anything”, which is wrong, and may let you think that there is an unrelated issue, much in the same way we have now, but at least wouldn't disclose you you're blocked… idk)
I agree it is tricky if you are trying to balance intuitive-ness with curbing abuse by folks who are inclined to make smurf accounts to continue their abuse.
My few questions are: do the Mastodon devs believe that most blockees are blocked because they themselves were offenders/harrassers? If no, the solution in place is inadequate/just plain bad, because the user will just end up confused and assume Mastodon is broken. Or like me, spend a bunch of time troubleshooting only to realize they were blocked.
If yes, do Mastodon devs believe that most blockees would in turn start creating smurf accounts to continue their harassment? If no, then again the solution in place is bad. They won't know they are blocked, might assume they did nothing wrong, or that Mastodon is broken.
If yes, then like @ThibG said, they will eventually find out that they certainly were blocked (maybe by running into this Github issue like I did) and then will find a way to continue their abuse.
In the end, I think the current solution can potentially cause more confusion/annoyance to benign users than it does actually stop abuse or harrassment.
Mastodon is broken.
I believe people will start to think that Mastodon is unreliable or just broken.
I'm so confused because would you have really preferred the way it was before? A profile that shows no toots with no explanation for why and a follow button that you can click but that always resets to "follow" because it never goes through? In my view that's way worse in terms of making you believe it's a glitch. Right now you're saying it's broken literally because the message says "Profile unavailable" instead of "Profile unavailable to you because you're blocked".
I know I may be in a minority here based on earlier discussion, but I actually thought the idea to just let a user know that they are blocked, or a "You can't view posts by this user" kind of message, was fine. In my opinion, the benefits outweigh the negatives. The OP of this issue and the two following comments present a false dichotomy. I think saying that the RC in question was "designed solely for the benefit of bad actors in the fediverse" is disingenuous. I sincerely doubt that was the intention of Mastodon devs, and it paints a space where only harassers & those that are harrassed exist.
EDIT: fix typo
Expected behaviour
Mastodon doesn't enable harassment by not giving information to harassers that have been blocked.
No, it creates all sorts of administrative issues completely unrelated to the matter at hand.
Woosies complaining about it only serving to notify an abuser to incorporate another method are demonstrating a bit of idiocy. An actual abuser knows this already, and to be sure, blocking is different than being reported. If someone rises to the level of incorporating another avenue (which, by the way, they can absolutely do anyway - Duh!) to harass, it is called STALKING, and on most servers, grounds for an immediate Kick/Ban on most instances, if it's not the policy on the home instance of the person being victimized, then they might well be advised to migrate their account to another instance where it is the policy.
Kinda sorta really simple, but some people are just stupid little babies.
Most helpful comment
Server-side muting (which is what "shadow-banning" typically means) is outside the scope of this discussion.
From discussions I've had and overheard, the ideal approach seems to be:
In general, does that seem accurate?