WordPress.org

Making WordPress.org

Opened 3 months ago

Closed 3 months ago

Last modified 3 months ago

#5578 closed defect (fixed)

Profiles should not display details for banned users

Reported by: Ipstenu Owned by: dd32
Milestone: Priority: normal
Component: Support Forums Keywords:
Cc:

Description

When a user is banned, especially for spam, we generally do the following:

  1. Wipe the bio
  2. Delete the URL
  3. Normalize the display name

The reason for this is that those are generally where people spam (or decide to be ... impolite in the brief time between a warning an a banning).

It would be easier all around if the profile on the forums (i.e. https://wordpress.org/support/users/dd32/ ) did the following when banned:

  • Display Name (instead, just show the user ID)
  • Profile, Forum Role, Title, (show nothing)
  • Member Since, Topics Started, Replies Created, Reviews Written (maybe show nothing??)

I say maybe on that last run since ... that doesn't really matter in the long run.

Also I'm willing to be talked out the forum role, though right now it shows 'Banned' which may be objectionable to some people in a mood.

Change History (10)

#1 @dd32
3 months ago

Wipe the bio
Delete the URL

Hiding it seems reasonable, like profiles.w.org does for blocked users.

Normalize the display name

Does this mean resetting it to the user nicename/login? That seems reasonable to remove any custom First/Last/Nickname added.

Display Name (instead, just show the user ID)

Is the display name significant here? These pages should be noindexed, so I'm not sure that gains much, other than for

Profile, Forum Role, Title, (show nothing)

Agreed.
I'm not sure the Forum Role field should be shown anyway normally, it doesn't seem like much of a benefit other than flagging Moderators. Maybe we should just show it if the viewed user has Mod capabilities?

Member Since, Topics Started, Replies Created, Reviews Written (maybe show nothing??)

I'm not sure blanking these benefits anyone much? It's not like these are private details or going to contain anything sensitive?

#2 @Ipstenu
3 months ago

I should point out... this is a 50-50 help us/help the banned person thing.

So yes, making this hidden helps US mitigate people saying horrible things, but it also helps us SAVE those people. It's easier to help someone come back from a phenomenally terrible day where they go off the rails, if the evidence of their mistake isn't quite so glaring. And a number of people do realize "Oh my word, I've been a prat!" and come back with a sincere apology. I really want to keep the door open, rather than have someone go "Huh, NotOtto has been going off, I'm going to look at their profile ... wow. What a horrible human!" It's the same reason we archive their posts. It's not for us as much as them.

Does this mean resetting it to the user nicename/login? That seems reasonable to remove any custom First/Last/Nickname added.

Yes, resetting it to the nickname to prevent someone from making their display name "Buy Viagra!"

Is the display name significant here? These pages should be noindexed, so I'm not sure that gains much, other than for

That relates to the above people making their name something dumb and/or offensive (like "Otto Really Sux"). Not being indexable doesn't matter all that much if I can click on a profile link from a post. (this matters for users having bad days more than spammers)

I'm not sure blanking these benefits anyone much? It's not like these are private details or going to contain anything sensitive?

It shouldn't, and like I said, really doesn't matter. But I put it there in case you saw something I didn't :D

#3 @dd32
3 months ago

In 10584:

Support Forums: Remove some details from the support profile overview for blocked users.

See #5578.

#4 @dd32
3 months ago

In 10585:

User Tweaks: Use the user nicename for blocked users, rather than the contents of the display_name field which may be set to something not display friendly.

See #5578.

#5 @dd32
3 months ago

In 10586:

User Tweaks: Add BuddyPress support.

See #5578.

#6 @dd32
3 months ago

In 10588:

User Tweaks: Fix a typo in the buddypress code in r10586.

See #5578.

#7 @dd32
3 months ago

  • Owner set to dd32
  • Status changed from new to accepted

I think the raft of commits above should be enough to consider this fixed.

Can someone go through and confirm that is the case? :)

#8 follow-up: @Ipstenu
3 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

That looks great! I do wonder if we should change the gravatar to blank out (Mystery Person), but ... that tends to be far less abused at the moment. We can close this and then if it becomes an issue, make a new one.

#9 @dd32
3 months ago

In 10589:

User Tweaks: Avoid some PHP Notices in the BuddyPress code, as the displayed user functions may be called with no displayed user.

See [10588], [10586].
See #5578.

#10 in reply to: ↑ 8 @dd32
3 months ago

Replying to Ipstenu:

I do wonder if we should change the gravatar to blank out (Mystery Person), but ... that tends to be far less abused at the moment.

I considered quickly adding that, until I saw the 40 lines of code to determine what/who/where the avatar to display is..

If it becomes an issue, abusive/spam/obscene gravatars are probably against the Gravatar ToS, or at least should be marked as higher than G-rated, and the Gravatar support team will probably take action, or, in the rare case of this being a thing the email can be changed.

Note: See TracTickets for help on using tickets.