Page MenuHomePhabricator

Enable default create/edit/move semi-protection for base userpages of registered users on enwiki
Closed, ResolvedPublic

Description

Summary of technical changes

The following technical changes are included based on the approval of this RfC:

  1. Semi-protection for editing and page moving should be applied by default to all base userpages on en.wikipedia, with the following stipulations:
    1. Default protection does not apply to user subpages, and
    2. Default protection does not apply to userpages of unregistered users
  2. Users with accounts that are not yet autoconfirmed or confirmed should be able to edit their own, semi-protected userpages.

Examples

  1. The PAGE User:Example should have forced semi-protection
  2. The PAGE User:Example/Sandbox should NOT be forced to semi-protected
  3. The USER User:Example should be able to edit User:Example, even if they do not have (editsemiprotected) access. {Some sort of 'editmyuserpage' override}
  4. The USER User:Example should not be able to edit [[User:Example]] if additional protections are applied - unless they have the appropriate other edit permissions.
  5. The PAGE User:NotARegisteredUser should not be automatically protected.
  6. The PAGE User:127.0.0.1 should not be automatically protected, regardless if 127.0.0.1 has ever edited.
  7. Users with (editsemiprotected) access should be able to edit userpages

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 28 2016, 7:50 PM
JJMC89 added a subscriber: JJMC89.Oct 28 2016, 9:51 PM
Restricted Application added subscribers: JEumerus, Matanya. · View Herald TranscriptOct 29 2016, 10:53 AM

As noted on the talk page, a plain reading of https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Protect_user_pages_by_default doesn't seem to find consensus to make such a drastic change. The option that received the most supports numerically was option 1 (no change), as far as I can tell.

Krenair added a subscriber: Krenair.

Yeah, this is not something MediaWiki allows us to do.

Dereckson added a subscriber: Dereckson.

Per MZMcBride comment here, and Andy Wang on the RfC talk page.

+Consensus-needed tag as it has been questioned

I've filled a task, T149484, to separate the development of the feature (there), and the en.wikipedia request of this feature (here).

andymw added a subscriber: andymw.Oct 29 2016, 5:31 PM
Zppix added a subscriber: Zppix.Oct 29 2016, 10:19 PM

Created subtask T149501

Maybe an edit filter can do this.

Maybe an edit filter can do this.

@MusikAnimal i know you at least used to manage filter whats your input on this?

The only problem will be the 5th point.

MusikAnimal added a comment.EditedOct 29 2016, 11:28 PM

Yes, we can do this with an edit filter quite easily, and that seems like best solution as I suspect there's a lot of work involved to get this functionality in MediaWiki core. I agree with others that there doesn't seem to be a clear consensus for this, though, and we definitely will need that.

Zppix added a comment.Oct 30 2016, 4:22 PM

Should we run an inital test to see if this infact would work as intented say like on wikitech or mw sites? @MusikAnimal

Should we run an inital test to see if this infact would work as intented say like on wikitech or mw sites? @MusikAnimal

I've created a log-only filter on enwiki at Special:AbuseFilter/803. It's true the 5th point (user pages of nonexistent user) may not be enforceable with the filter, and while we can enforce the 6th one (IP user pages), doing so would be somewhat expensive. I believe both are very much an edge case, and I find the appropriateness of creating a userpage for a nonexistent user on par with editing that of an existing user. Creating IP user pages is by itself is very rare, but the filter would still allow that IP user to create it. The only use case I can think is where one of our many anonymous patrollers might want to tag an IP user page as a "suspected to belong to User:Sockpuppet", but they can put that on the talk page.

MusikAnimal added a comment.EditedOct 30 2016, 7:51 PM

Filter is working great, so I've gone ahead and disabled it until we know what we're doing. Unconfirmed edits to someone else's talk page happens frequently, and indeed most of what I see is bad-faith and/or vandalism. There are some legitimate uses where an anonymous user, perhaps the actual user while logged out, is helping with a draft article they put on their user page. This is something we've already tried to deter, e.g. try creating a user page (example) and you'll see the edit notice encouraging creating a userspace draft instead of using their user page. That edit notice could probably use updating (telling them to use the Draft namespace, etc), but that's beside the point. All in all I think the edit filter solution will suffice, if we do have consensus to set it to disallow.

MusikAnimal added a comment.EditedOct 30 2016, 8:07 PM

More advantages to the edit filter over actual semi:

  • All disallowed edits are logged, so we're able to track abuse and good-faith attempts
  • We can show a customized friendly message, e.g. "Editing of another user's userpage is disallowed to prevent against abuse. If this is your userpage, please log in to edit"
  • We can alternatively issue a warning then allow them to save, or simply tag the edits. Doesn't have to be disallow.
  • We can still allow editing from privileged users who are locally unconfirmed, such as stewards, global-rollbackers, etc. (they may already be able to edit semi-protected pages, not sure)

Note some other wikis are already have similar filters, such as Korean Wikinews

Funcrunch added a comment.EditedOct 30 2016, 8:53 PM

More advantages to the edit filter over actual semi:

  • All disallowed edits are logged, so we're able to track abuse and good-faith attempts
  • We can show a customized friendly message, e.g. "Editing of another user's userpage is disallowed to prevent against abuse. If this your userpage, please log in to edit"
  • We can alternatively issue a warning then allow them to save, or simply tag the edits. Doesn't have to be disallow.
  • We can still allow editing from privileged users who are locally unconfirmed, such as stewards, global-rollbackers, etc. (they may already be able to edit semi-protected pages, not sure)

Note some other wikis are already have similar filters, such as Korean Wikinews

I like the idea of showing a friendly message, and logging to track how many of these edits are abuse vs good-faith.

ETA: I should note though that the closer of the RfC specifically said that the consensus was for semi-protection, and this filter option sounds like it would still allow very new accounts to edit (essentially, option 1.5 of the RfC). I do understand that the close is being questioned, and the admin has been pinged for clarification.

MusikAnimal added a comment.EditedOct 30 2016, 10:06 PM

ETA: I should note though that the closer of the RfC specifically said that the consensus was for semi-protection, and this filter option sounds like it would still allow very new accounts to edit (essentially, option 1.5 of the RfC). I do understand that the close is being questioned, and the admin has been pinged for clarification.

The filter is currently set to target unconfirmed users, so would effectively be the same as semi-protection

ETA: I should note though that the closer of the RfC specifically said that the consensus was for semi-protection, and this filter option sounds like it would still allow very new accounts to edit (essentially, option 1.5 of the RfC). I do understand that the close is being questioned, and the admin has been pinged for clarification.

The filter is currently set to target unconfirmed users, so would effectively the same as semi-protection

Thanks for the clarification. Though I like the advantages of a simple filter, a complication I could see is if someone did want to keep their own user page open to anonymous/new user edits. With default semi-protection, they would be able to request that an admin remove this restriction from their own user page. Would they be able to opt their own user page out of this filter?

Thanks for the clarification. Though I like the advantages of a simple filter, a complication I could see is if someone did want to keep their own user page open to anonymous/new user edits. With default semi-protection, they would be able to request that an admin remove this restriction from their own user page. Would they be able to opt their own user page out of this filter?

We could add support for some sort of null template, {{unprotected user page}} for instance, which when present on the page makes it open for editing. That of course would need to be well documented, and I suppose it's a bit hacky, but it'd work. Actual semi-protection is more suitable in terms of performance and the use case you present here, but at the loss of logging and a custom notice. I've no strong feelings on either solution, but I do believe it will take considerable time to get this into MediaWiki core, given both the engineering challenges and lack of consensus.

Samtar added a subscriber: Samtar.Oct 31 2016, 12:27 PM

@MusikAnimal Thanks for your work in writing up the filter and testing it out!

I agree that a filter is a better approach here in terms of implementation; there still appears to be some unknowns in terms of how easy it would be to change the code underlying page protection and otherwise. Using a filter also addresses concerns voiced during the RfC about these changes taking up programmer time that may be needed elsewhere. Logging is also a valuable feature that would allow tracking of the quality of edits being made.

The closing admin has responded here repeatedly regarding questions over consensus. Given their responses and that this discussion closed over a month ago, I'm removing the consensus-needed tag and recommending we move forward using a filter approach.

I_JethroBT closed this task as Resolved.Dec 1 2016, 4:10 AM
I_JethroBT claimed this task.

Filter was turned on today after updating the language on Wikipedia:User pages and developing an appropriate alert message when the filter is triggered.

Nemo_bis added a subscriber: Nemo_bis.

Not a matter of configuration.

andymw removed a subscriber: andymw.May 16 2017, 5:04 AM