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.

likelakers2 wrote:

Wrong option.

(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!"

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.

(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.

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.)

(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.

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.)

(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.

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

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.

(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.

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'''.

(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.

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.

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.

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?

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.

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.

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.

No, no, no. It makes no good in a wiki to delete all logs. You want to hide that he renamed the Village_Pump to VillageOnWheels? That he uploaded files? What about his contributions? Are we expecting him to free them into Public Domain? What when we want to make sense of a history with multiple deleted accounts quarreling with each other?

Now, I would agree that we could have a "preference option" that is a bit of candy for explaining the problems or requesting a rename wihout requiring "arcane" templates.

If you vanish the users, then how can we attribute the users, considering that mediawiki provides CCL by default and CCL requires Attribution in any licenses?

This is a message posted to all tasks under "Need Discussion" at Possible-Tech-Projects. Outreachy-Round-11 is around the corner. If you want to propose this task as a featured project idea, we need a clear plan with community support, and two mentors willing to support it.

This is a message sent to all Possible-Tech-Projects. The new round of Wikimedia Individual Engagement Grants is open until 29 Sep. For the first time, technical projects are within scope, thanks to the feedback received at Wikimania 2015, before, and after (T105414). If someone is interested in obtaining funds to push this task, this might be a good way.

Hi!
I am interested in knowing more about this project.
Thanks!

Still no consensus, and no known mentors. I think it is better to remove it from Possible-Tech-Projects until someone wants to lead the way back as a mentor. Sorry @Haritha28 ...

It would be best if this function was created, however, with the blocked users and the banned users deleting accounts to circumvent their blocks, they should be locked into their account so they cannot sign out or delete. Also, to prevent errors, all contributions must be assigned to an identifier. The following can occur:

1. The user cannot use the same username.
2. All of their pages will be tagged for speedy deletion.
3. The above cannot take effect for 30 days.

This will prevent errors and also ensure that users do not circumvent their blocks.

In T34815#3184888, @UpsandDowns1234 wrote:

they should be locked into their account so they cannot sign out or delete

To clarify, you imply that based on... "something" (what?) the MediaWiki software would make the user 'end up' in the user's previous locked account? Or how to interpret your sentence? Because any user can sign out of an account at any time, if the user deletes corresponding cookies in the user's web browser.

In T34815#1333827, @Ankit-Maity wrote:

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.

In T34815#1582184, @Platonides wrote:

No, no, no. It makes no good in a wiki to delete all logs.

Agreed that log entries themselves should not be deleted. The integrity of a page's history should remain in tact, including important events like renames. However, what we can do is (from the public perspective) disassociate them from the user in question.

I don't think we would need a placeholder username for this, rather, we can use the fact that MediaWiki nowadays recognises the concept of a user record being "hidden". For example, when a revision is deleted (e.g. archived/hidden from public view), the database still has a user_id reference, but it is never made visible to the end-user in favour of a placeholder message indicating that the user name was hidden. The change itself, subject page, and timestamp can remain public.

I propose that account deactivation is essentially a programmatic way to apply the "username" variant of revision-delete to all one's own edits and log entries. This could be done from the job queue similar to how renames happen.

Account deactivated:

• Hide username from all contributions and log entries. This means queries by user (Special:Log, Special:Contributions) will yield 0 results for the username. Queries by target will still yield results but with username hidden (e.g. page history, or log entries about a page or acting on a different user).
• Delete user page, user talk page, and subpages thereof.
• Lock and hide user account (User::isLocked, User::isHidden).

I don't think blocking is necessary. On the other hand, it seems in MediaWiki core there is no way to lock or hide a user, only auth plugins can trigger this flag. As such, even if this feature would be an extension, unless we use a block, we'd have to depend on CentralAuth, which seems undesirable. On the other hand, the extension could provide a hook that defaults to using a block, but CentralAuth could make it prettier by using lock/hiding instead. CentralAuth would have to be hooked either way, to propagate the change to all wikis. (Unless we want to partial/per-wiki deactivation.)

Bit concerned that deleting the user talk page could be used to evade/reduce scrutiny. Also, what happens to a deactivated account if it tries to edit?

In T34815#3189197, @JEumerus wrote:

Bit concerned that deleting the user talk page could be used to evade/reduce scrutiny. Also, what happens to a deactivated account if it tries to edit?

Locked accounts cannot log in, much less perform edits.

This is rather interesting to read because there's a lot of discussion and back and forth when there really is a simple answer.

Just install the EditAccount extension globally on Wikimedia Foundation wikis.

The only reason why the extension is flagged as unstable is because users with the editaccount userright can edit the email and password of any other user, and therefore can technically take over accounts. The good news is that the editaccount userright is not assigned to any user group by default. Users without this permission cannot access Special:EditAccount, but rather they can access Special:CloseAccount and Special:DisableAccount which lets them lock and disable their own account.

So, if we install this extension, but do not assign the editaccount userright to any group (other than maybe official WMF Staff), users can close their own accounts securely.

For end users, all that extension stuff is not in their hands, hence only a solution in the wikimedia core can help reliably. Example use case leading me to this ticket: On some sites (not wikimedia ones) I have 2 users because of historical reasons, e.g. 2 wikis were merged and in both I had an account. I simply want do merge my two accounts into one or alternatively deactivate/delete one of the two, so it's having no login, edit or whatsover functionality. I simply do not want to have to care about the disposed account any more and even after leaking passwords, that account cannot be taken used by bad boys for any action.
I'm for sure not the only person having such situation, so please add some solution into the core in order to keep the user base of wikis clean & reflecting the reality. Thank you :)

I still think the close my account extension is the solution

@UpsandDowns1234: Please see T166858#3483799 and followups if you'd like to help.

Simply we can just do so:

• Remove the user row from user table. Now MediaWiki will treat the account as unregistered
• Change the actor_name to something like "Deleted user #123123" so histories and logs now shows the anonymized name, and (optionally?) actor_user to null
• Some table (e.g. user_groups, user_properties) now contains rows that make no sense, and can simply be removed
• Now the user is deleted for good

For non-Wikimedia wiki, this provides a simple way to remove e.g. (1) spam/vandalism only account and (2) account closed on GDPR request.

Does some extensions assumes the existence of a user_id? Check and fix them