Page MenuHomePhabricator

Allow users to restrict specific users from editing their own user page and subpages thereof
Open, Needs TriagePublic

Description

Problem to solve

User pages are collaborative spaces often used for creating to-do lists, collections of helpful links or tools, and snippets of copy-and-paste wikitext. Many userpages are also curated by the associated user account to share autobiographical information, either in an encyclopedic format or in a more personal and social format. This information, coupled with the fact that the page is associated with their username, is a part of the user's identity.

Vandalism to user pages are not standard content vandalism, they are a form of personal attacks designed to hurt or humiliate the subject of the userpage. Patrolling the AbuseFilter logs shows some horrendous personal attacks to illustrate the types of hurtful messages.

After a lengthy conversation on ENWP and a vote on FRWP, an AbuseFilter (#803 on ENWP) was enabled that prohibits IPs and newly registered accounts from editing the base user pages of all other accounts by default, individual users can override this with a special template if they wish. User talk pages were not touched. In the discussion stronger protection limits were proposed, but ultimately rejected due to the scale of the solution.

However, sometimes unwanted edits can come from a user who is above the autoconfirmed threshold. Admins can impose interaction bans or manually protect the page on behalf of the user, but this requires a public conversation.


Possible solution

Provide users with a tool that allows them to prohibit specific usernames from editing their userpage and subpages. This could take the model of the Notifications Mute or Direct Email Mute features, or manifest as something different entirely, such as an admin-controlled per-page blocking feature.


Related tasks

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 20 2017, 7:51 PM

Thanks for the ping. Makes sense to me for a user to be able to bar individual users (other than admins) from their user page and subpages. As I argued in my userspace protection RfC, user pages are not part of the encyclopedia, so the "encyclopedia that anyone can edit" argument for leaving them completely open (by default) really doesn't hold water from my perspective.

Would this tool require a new RfC before development though? I've seen the (often rude) pushback against the WMF on the Community Health Initiative page, so I anticipate more grumbling on this...

TBolliger added a comment.EditedSep 20 2017, 8:57 PM

Would this tool require a new RfC before development though? I've seen the (often rude) pushback against the WMF on the Community Health Initiative page, so I anticipate more grumbling on this...

Yes, certainly, 100%. This feature (or anything under the Mute epic ticket (T164542) will not be developed without on-wiki consultation on both Meta and English Wikipedia.

I acknowledge this feature will be very contentious, and I actually believe that T2674: Allow users to be blocked from editing a specific article or all articles inside a namespace to allow for admins to set this protection or T176270: Allow users to restrict which user groups can edit their own user page, talk page and subpages thereof will more likely see the light of day on ENWP. But this functionality might be useful for other smaller wikis. Still worth considering and exploring.

Restricted Application added a subscriber: MGChecker. · View Herald TranscriptFeb 20 2018, 5:48 PM
Xaosflux updated the task description. (Show Details)Apr 13 2018, 2:36 PM
Xaosflux added a subscriber: Xaosflux.

@ Anti-Harassment I may be interested in trying to develop such an extension. Would the anti-harassment team be willing to do any needed review for it do be deployed?

@DannyS712 This seems like something that would need community approval. Rather get it first before getting into the technical work.
From Anti-Harassment team's perspective, this work has been deprioritized currently. It's actually a pretty old task so I think it would need revisiting the use cases that prompted the need for such an extension.
I would recommend against picking up this task, @DannyS712 until we are absolutely sure people will benefit from the work that goes into it.