Add user preference to deactivate/delete user account
OpenPublic

Assigned To
None
Priority
Normal
Author
MZMcBride
Subscribers
Ankit-Maity, Teles, Trijnstel and 15 others
Projects
Tokens
"Dislike" token, awarded by Ricordisamoa."The World Burns" token, awarded by Ankit-Maity.
Reference
bz32815
Description

MediaWiki should have a user preference that allows users the ability to deactivate and/or delete their account. This option is available on nearly every major site and its absence on MediaWiki wikis is conspicuous and unacceptable.

Users don't care about referential integrity of the database or anything of the sort. They do care about the ability to disassociate themselves with an account whenever they want to. The current documentation on sites such as the English Wikipedia regarding account deletion is obscure, vague, and unhelpful. Regular users can understand a user preference and a confirmation page. They cannot understand needing to add obscure code to their user or user talk page (such as "{{db-user}}") or requesting an account rename (which is a bureaucratic nightmare on most wikis).

There are glaring usability problems in the current setup that should be addressed and resolved. Underlying wiki principles such as easy reversibility are also at stake. If it's so easy to create an account, surely destroying one should be equally easy.

Envisioned workflow (roughly):

  • user requests account deactivation at Special:Preferences
    • account is deactivated
      • block EmailUser functionality in both directions?
      • block posting to user's talk page?
      • block user from being able to edit/move/etc.?
    • after specified time, account is deleted
      • if account can't be deleted due to edits or log entries, account is renamed to a random string

Version: unspecified
Severity: enhancement
URL: https://en.wikipedia.org/wiki/Wikipedia:Courtesy_vanishing

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz32815.
MZMcBride created this task.Via LegacyDec 5 2011, 8:18 PM
bzimport added a comment.Via ConduitDec 5 2011, 8:28 PM

likelakers2 wrote:

No. This would easily allow spammers to use sockpuppets to avoid blocks much easier. If you want this on your own wiki, see [[mw:Manual:Preventing access#Removing_accounts]].

If anyone wants to reopen this, feel free to.

bzimport added a comment.Via ConduitDec 5 2011, 8:28 PM

likelakers2 wrote:

Wrong option.

demon added a comment.Via ConduitDec 5 2011, 8:33 PM

(In reply to comment #1)

No. This would easily allow spammers to use sockpuppets to avoid blocks much
easier. If you want this on your own wiki, see [[mw:Manual:Preventing
access#Removing_accounts]].

I think we can support deleting accounts in MediaWiki, even if it's disabled by default. It's a VERY VERY common question (how do I delete an account). There's zero reason not to support it rather than telling people to do it by hand but scaring them with "zomg database integrity!"

bzimport added a comment.Via ConduitDec 5 2011, 8:40 PM

likelakers2 wrote:

It can still allow a blocked user to delete their account, wait for their IP block to expire, and then create a new account. It will only encourage spamming by making it easier.

demon added a comment.Via ConduitDec 5 2011, 8:49 PM

(In reply to comment #4)

It can still allow a blocked user to delete their account, wait for their IP
block to expire, and then create a new account. It will only encourage spamming
by making it easier.

If you read what I wrote, you would see "disabled by default."

There are legitimate use cases for this.

brion added a comment.Via ConduitDec 5 2011, 8:53 PM

I'd prefer something like this to be *enabled* by default *and* available on Wikipedia.

What's the specific issue with blocks? Is it based on the concept that the blocks would disappear? (They shouldn't.) Or that the account should completely vanish from existence totally? (It shouldn't; it'd need to be kept for logs and other audit purposes, such as ... maintaining those old blocks.)

MZMcBride added a comment.Via ConduitDec 5 2011, 10:30 PM

(In reply to comment #4)

It can still allow a blocked user to delete their account, wait for their IP
block to expire, and then create a new account. It will only encourage spamming
by making it easier.

It would be fairly trivial (one line of code) to prevent blocked users from having the option to deactivate/delete their own account. There are a lot of logistical and technical problems to overcome to resolve this bug, but I don't see this particular point as especially problematic or difficult.

brion added a comment.Via ConduitDec 5 2011, 11:40 PM

Everyone should be able to deactivate their account; there's no reason that being blocked should prevent that. (If anything, I'd expect blocked accounts to be a very legitimate and possibly large subset of people who'd want to go ahead and close out their accounts, if they have no desire to come back after whatever dispute or unbecoming activity they were mixed up in.)

Krinkle added a comment.Via ConduitDec 5 2011, 11:51 PM

(In reply to comment #0)

  • block posting to user's talk page?

Although one could discourage it by hiding 'Add section' or perhaps even requiring a special user right [1], it should still be edit/move/deletable by sysops/stewards for administrative purposes and general wiki maintenance.

  • Krinkle

[1] A bit like 'edituserjs' and 'editusercss', there'd be something like 'editdeactiveateduserpages'

DanielFriesen added a comment.Via ConduitDec 6 2011, 12:29 AM

We let people edit the user pages of users that don't even exist. I don't see a good reason to block unrelated users from being able to touch the user's talk page.
This would just create an incentive for malicious users to register, shove spam on their talkpage, then deactivate their account so normal users can't blank the spam and mark the page for deletion.

demon added a comment.Via ConduitDec 6 2011, 12:33 AM

(In reply to comment #10)

We let people edit the user pages of users that don't even exist. I don't see a
good reason to block unrelated users from being able to touch the user's talk
page.
This would just create an incentive for malicious users to register, shove spam
on their talkpage, then deactivate their account so normal users can't blank
the spam and mark the page for deletion.

I think we can take off the tinfoil hat ;-) But I agree with the general sentiment that page editing/etc shouldn't be tied to this. That's what protection/deletion are for.

bzimport added a comment.Via ConduitDec 7 2011, 10:49 PM

likelakers2 wrote:

Actually, we technically don't allow editing the userpages of users that don't exist currently. This is the main problem with this, as it would defunct [[en:WP:CSD#U2|U2]] a lot. U2 is for userpages of '''non-existant users'''.

DanielFriesen added a comment.Via ConduitDec 8 2011, 1:10 AM

(In reply to comment #12)

Actually, we technically don't allow editing the userpages of users that don't
exist currently. This is the main problem with this, as it would defunct
[[en:WP:CSD#U2|U2]] a lot. U2 is for userpages of '''non-existant users'''.

Except, we do allow it.

I just created this userpage, on a User: that had the big red message saying the user didn't exist.
https://www.mediawiki.org/wiki/User:ThisUserDoesNotExist

WP social policy is irrelevant to this. We don't have a core restriction on the editing of userpages/usertalk for non-existent users. So we shouldn't have core code block users from editing a userpage/usertalk after the relevant user has deactivated their account.

MZMcBride added a comment.Via ConduitDec 8 2011, 9:11 PM

I'm wondering how much of this could be piggybacked on top of the HideUser functionality that already exists in MediaWiki core. Fundamentally (or ideologically, rather), there needs to be a decision about whether MediaWiki will allow account deactivation, account deletion, or (self-)account obfuscation (which is essentially what HideUser is).

Maybe an RFC is needed to gather input? I'm not sure.

bzimport added a comment.Via ConduitApr 27 2012, 2:39 PM

elenoftheroads wrote:

This will become more necessary if the EU succeeds in its aims (see http://www.crikey.com.au/2012/02/21/eu-privacy-laws-the-right-to-be-forgotten-is-not-censorship/) to give individuals the ability to request information be deleted when an account is closed. Although an editors contributions generally are released under CC-BY-SA, the law may not view usernames and userpages in that light.

Liuxinyu970226 added a subscriber: Liuxinyu970226.Via WebDec 27 2014, 1:19 PM
Ankit-Maity awarded a token.Via WebFeb 6 2015, 3:06 PM
Qgil added a subscriber: Qgil.

This task was mentioned in https://www.mediawiki.org/w/index.php?title=Outreach_programs/Possible_projects&oldid=1404823#Very_raw_projects as a possible candidate for Google Summer of Code or similar programs. Do you think it is a good candidate?

Qgil added a comment.Via WebFeb 11 2015, 1:44 PM

Wikimedia will apply to Google Summer of Code and Outreachy on Tuesday, February 17. If you want this task to become a featured project idea, please follow these instructions.

Qgil added a comment.Via WebFeb 16 2015, 11:26 PM

This task doesn't show a clear community consensus. Then again the debates are quite old. Is there a clearer opinion nowadays?

On the other hand, does this task really need a 3 month, full time internship to be completed? It looks like a simpler feature.

Qgil moved this task to Need Discussion on the Possible-Tech-Projects workboard.Via WebFeb 16 2015, 11:26 PM
Sumit added a subscriber: Sumit.Via WebFeb 17 2015, 8:53 AM
01tonythomas added a subscriber: 01tonythomas.Via WebFeb 22 2015, 4:17 PM
Ricordisamoa awarded a token.Via WebMay 1 2015, 11:29 PM
Ricordisamoa added a subscriber: Ricordisamoa.
Trijnstel added a subscriber: Trijnstel.Via WebMay 27 2015, 12:04 PM
Teles added a subscriber: Teles.Via WebMay 29 2015, 9:08 PM
Ankit-Maity added a subscriber: Ankit-Maity.EditedVia WebJun 3 2015, 2:37 PM

I would say the workflow go like this:

  • Account deactivated
    • Block all functionalities
    • If relogin within 30 days, reactivate the account
  • After 30 days, delete the account
    • Delete all log/edit filter entries related to the user.
    • Move all edits to a placeholder username (which is going to be the same for every deleted user).
    • Delete all user pages.

I believe that every user should have the "right to vanish". Even if spammers make sockpuppets, so what? We have autoblocks, don't we? And anyway, we have advanced heuristics (aka Recent Changes patrollers).
I believe this task's pros easily outweighs its cons.

Add Comment