Explain critical blocking feature that causes tremendous misunderstan…

[jidanni]

I've seen it a 1000 times: User A gets angrier and angrier because User B is not responding, even to @mentions.
That's because User A never read that blocking actually prevents User B from getting the message.
This has exacerbated friction on teams I have worked with and needs to be documented.

[welcome]

Thanks for opening this pull request! A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.

[jidanni]

That takes care of documentation potential blockers should read.
Also somebody please add notes for blockees, e.g., on
https://docs.github.com/en/free-pro-team@latest/github/managing-subscriptions-and-notifications-on-github/configuring-notifications etc. Please say there:

Note: if User X has blocked you, you won't get email notifications even for comments where he has @mentioned you.

[janiceilene]

Thanks for opening a PR 👍 Please fill out the pull request template in the top comment in this pull request, then we'll get this up for review!

[jidanni]

Why:

Many users block other users due to poor interaction.

Then the interaction only becomes worse, due to the block.

Because even when @mentioned, the blockee no longer responds to the blocker.

Ah, if only the blockee could see what the blocker asked them. But alas, he won't get the email notification, due to the block.

But the blocker doesn't realize this, and gets even angrier.

What's being changed:

Here I update the documentation, so blockers understand this situation, so won't get angry anymore.

Check off the following:

• For content changes, I have reviewed the Content style guide for GitHub Docs.

[janiceilene]

Thanks so much @jidanni! I'll get this triaged for review 🌟

[jidanni]

In fact not only email notifications, but web notifications are blocked too.
User X blocks User Y. User X can then make lots of comments on User Y's issues without user Y ever knowing what happened.

[github-actions]

This PR is stale because it has been open 7 days with no activity and will be automatically closed in 3 days. To keep this PR open, update the PR by adding a comment or pushing a commit.

[janiceilene]

This is not stale! Thanks for your patience @jidanni 💛

[jidanni]

Actually I tried very hard to get people to be aware of the problems involved with this issue. So here's what I posted elsewhere:

Description:

Here we see how GitHub's simplistic implementation of blocking
actually backfires.

Steps To Reproduce:

Mallory visits https://github.com/settings/blocked_users
and blocks Alice, thus "anesthetizing" her for the next step:

Mallory then proceeds to add insulting comments to all 1000 of Alice's
issues:

Hey sleepy Alice, you are so dumb that you don't even notice I defaced
this and all the other issues you opened, be it in your repository, or others'. Ha ha
ha!

Even using @mentions:

Hey @Alice, I hacked GitHub. @Get @The @Message?
I don't think so! Ho ho ho!

The defacement needn't even be on an issue Alice opened. But merely below a comment she left
on another user's issue. In all cases the goal is achieved: make Alice look dumb to others without
Alice's knowledge the incident ever occurred.

What legitimate GitHub user would @mention another user, wishing it to
be without the mentioned person's knowledge? Clearly the blocking implementation
was simply hastily written.

See also:
https://en.wikipedia.org/wiki/Internet_trolls
https://en.wikipedia.org/wiki/Website_defacement
https://en.wikipedia.org/wiki/Vandalism#Cybervandalism(Add details for how we can reproduce the issue)

Also...

Mallory double checks
https://docs.github.com/en/free-pro-team@latest/github/building-a-strong-community/blocking-a-user-from-your-personal-account
even more confident that GitHub's simplistic design will allow him to get away with the hack for years to come.

Also... the following scenarios could happen, sooner or later.

Scenario A:

10:30 AM: real Bob, the company president, posts
tonight's dinner party details (via a GitHub Issue, as is Bob's custom):

Black tie required.
Fee: $100. Transfer to account XXX-YYY-ZZZ.
Capacity: 1000 people.
Location: 1234 N. Main St. ...

10:35 AM: @bob' (Bob "prime" (name looks almost the same, say via
Unicode tricks, and picture, copied, exactly the same as real @bob)
first anesthetizes real Bob (blocks real Bob from getting notifications
about Bob Prime's activity, even on issues that real Bob created), and
also anesthetizes real Mary, and adds comment:

Oops, I meant 1234 S. Main St. Not North.

(And that's where the terrorist ambush is waiting. The Primes are
operating remotely, but they'll be there tonight, guns drawn.)

10:40: Mary' (Mary prime) anesthetizes the (same photo) real Mary, and
also real Bob, and adds comment:

This is Mary from the financial committee.
@bob, that's the Services account. You meant the Activites Account,
ZZZ-MMM-NNN. Right @bob?

(But of course real Bob won't be notified that she asked him.)

10:42: Bob' (Bob prime) adds comment:

Oops, you are right @Mary. Everybody please send the cash to the
Activites Account.

11:15 Real Bob (unaware of the Primes' comments) adds comment via email:

Oh, and remember to bring your silly party hats, everybody!

11:30 Some other employees post simileys, etc.

12:00 Lunch time: everybody waves at real Bob and real Mary, who are
eating together at the supervisors' table. Bob gets on the microphone:
"See you all tonight!"

15:00 Real Bob and real Mary are approving pull requests etc. as normal
on GitHub. Everybody is sure they are not offline, so no need to go to
their office to double check and ask if that's what they posted or not.

18:00 Real Bob is wondering where everybody is. And real Mary is
wondering why nobody transferred any money.

The next day families of the victims start suing, but lose the case as
GitHub's Terms and Conditions probably rule out such liability.

Why wouldn't this also be possible on Facebook?

Well on Facebook, if you block somebody, there is no chance you could
comment on a thread of theirs in the first place! (No matter if in a
group, page, or on a profile.)

And real Bob is still going to be notified of any fake Mary positing on
his thread, even if real Mary is blocked.

Anesthetizing a user is going beyond simply not allowing you to "follow
them." No, I'm not interested in following somebody around into their
home and bathroom. But I would still kindly like to know when they
entered mine please!

Scenario B:

Real Linus T. comments

Those components are located in a/b/c/d.

Fake Linus T. blocks real Linus T., and comments:

Oops, I mean w/x/y/z.

Developers download the fake software and the kernel gets infected, etc.

[Mary]

lol

[bob]

Where is everybody?

[jidanni]

Sorry I had to paste it all in from a cell phone and couldn't clean it up.
Update: OK I have @fixed all the @'s so they won't ring up anybody.

[message]

holla at your boy

[jidanni]

@brentjo says elsewhere:

It’s by design that blocking a user will silence notifications
from that user,

Yes, but I am talking about notifications to that user.

In my discussions here I am only talking about "blockee's rights are
being neglected". Neglected to the point that it even has security
implications.

You see, people get used to https://github.com/notifications being like
a "security camera."

Anybody "tampering" with their issues will show up on the security
camera.

Ah ha, but one day someone comes along and slides a cheery picture of
birds and trees in front of that security camera, and then proceeds to
do bad deeds, unknown to the security guard watching it.

OK, all the security guard needs to do is rig up his own security camera
(a cron job, combing all his issues for activity). But it will take a
few months for him to realize GitHub's security camera was not reliable.
And a few more months for him to write the cron job.

but notably, this does not prevent the blocked user’s content from
being visible to blocking user.

That is good! (But a side effect is they forget they blocked the user
and do e.g., "Hey @jidanni, why aren't you responding to my comments"
they should at least see a message "jidanni won't be notified, because
you blocked them.")

It’s important that the user still has the ability to see and
potentially interact with the content directed at them in a public
setting, for the reasons you mentioned above.

Yes. But (after Bill blocks them,) instead of getting a notification
"Bill commented on your issue" they instead need to check each day
manually, to find out. That's the only difference. They don't even need
to switch accounts. But they do need to write their own notification
cron jobs to comb all their issues for comments that they didn't get
notified about.

The blog post User blocking vs. user muting,
written by a PM here at GitHub, goes into our philosophy on blocking
vs. muting, and elaborates on the decision to mute
notifications from blocked users while keeping the content itself

Yes but I am only talking about notifications to blocked users.

@benbalter's article only touches on that at

(although it does prevent notifications).

But such a coarse implementation fails to distinguish the good case of
"Don't let Larry 'follow' me any more, or subscribe to updates about my
daily activities." Vs. "Don't let Larry even know I went wild and
defaced all his issues with silly comments."

2. GitHub doesn’t have any common spaces (timelines, newsfeeds,

That's right. In jidanni/mymaps#1, clearly a
space "belonging" to jidanni (me), I give a PoC of how my "evil"
jidanni2 test account was able to block notifications to jidanni add
comments that jidanni did not get notifications about.

OK, that is the case of X being able to "anesthetize" (block) Y and then
"deface" Y's stuff unknown to Y.

Boy, this is getting hard to remember. Let's just use two roles, 1.
Linus, a Good Guy. And 2. Evil user, an evil user.

So rewriting that sentence:

OK, that is the case of an evil user being able to "anesthetize" (block)
Linus and then "deface" (what is clearly) Linus' stuff, unknown to Linus.

Then there is the case Linus writing on Evil User's stuff... but that is
not what I am concerned about.

Then there is a interesting third party case: Issue A started by user X
in repository B owned by user Y has a comment added to it by Linus.
Then Evil User blocks Linus and adds a comment calling Liuns names, etc.
But Linus will never know it happened. (Unless he makes batch jobs to
comb issues he has commented on for notifications he missed.)

So how does Linus ever find out? Well say unrelated user C adds a
comment, which Linus gets a notification about. And then, when visiting
the issue (on the GitHub website) if Linus' eyes somewhat look above, he
will notice all the Evil comments above it. (If Linus just reads or
replies to the notification email, then he still will never know.)

I hope that helps shine a light on our approach to user blocking on
GitHub.com, but let me know if you have any further questions!

(I just want to thank you all at GitHub for still being available to
interact about such problems. Any larger, like Google, or Facebook...
well, all there is left is some black hole Feedback button.)

(Also I bet my "rapid tone" here is part of the reason I have become a
"being blocked" expert :-) ... Ah! Enabling me to discover this "gaping
security gap!")

Anyway: about the blocking party: Fine: the less stuff they see the
better. Whatever. I hope they go blissfully about their lives never
bothered about whatever. That is not my concern.

My concern is entirely from the point of blockees (people who have been
blocked) being "anesthetized" and missing notifications due to the
actions of evil parties.

[lee-dohm]

Thank you @jidanni for your thorough explanation of the various permutations of the problem you’re describing. We understand the point you’re making and will review your PR as soon as we can. However, continuing to comment will not make the review happen any faster and, in actuality, may slow down the review process because of the time spent ensuring we’ve given due consideration to any new information.

Thanks again for your passion and interest in improving our documentation.

[jidanni]

Thanks @lee-dohm (Actually I am hoping they change the implementation. Then no documentation change would be necessary.)

[megbird]

@jidanni I agree this could be improved. Unfortunately in this repository, we only have control over how our content on docs.github.com is written 😄 I'm taking a look at your PR ⚡ thank you for your contribution and explanations!

[megbird]

thank you for your contribution and providing clarity around notifications. I suggested a better place for this content, and a little tweak for wording to mirror the related content. Let me know if you have any questions.

[megbird]

This is helpful clarification ✨ but it seems like it would be more beneficial in one of the lists that already exist, just to keep content all in one place. I suggest making it a bullet point in the "After you've blocked a user, they cannot:" list, close to the related information 😄

After you've blocked a user, they cannot:

• Send you any notifications, including by @mentioning your username
• Receive any notifications sent by you, including comments @mentioning their username

[jidanni]

＠megbird those are all great changes. I would just wait to see what direction @brentjo and @benbalter want to take this.

[janiceilene]

👋 @jidanni We have a process to ensure that pull requests are reviewed as quickly as we can, directly at-mentioning individuals will not get your pull request reviewed any more quickly and can actually slow the response due to people being distracted by notification noise.

@brentjo and @benbalter are not maintainers in this repository. You can add the changes @megbird suggested, as a maintainer of this repo, if you'd like to see an update to the docs.

[jidanni]

@janiceilene , I would love to add them. But whatever I press seems to mess things up. Perhaps you folks can add them for me. Thanks.

[github-actions]

This PR is stale because it has been open 7 days with no activity and will be automatically closed in 3 days. To keep this PR open, update the PR by adding a comment or pushing a commit.

[jidanni]

I wish there was a way to get through to the block designers to hear their opinions on all this.

[github-actions]

This PR is stale because it has been open 7 days with no activity and will be automatically closed in 3 days. To keep this PR open, update the PR by adding a comment or pushing a commit.

[jidanni]

Too bad.

[janiceilene]

@jidanni Thanks for your patience! Our small team is working our way through all of the contributions, so it could be a while before someone from the team has the bandwidth to make this change for you.

[github-actions]

This PR is stale because it has been open 7 days with no activity and will be automatically closed in 3 days. To keep this PR open, update the PR by adding a comment or pushing a commit.