432614 - Offer a "Delete Account"-feature for users

Status: VERIFIED FIXED

(addons.mozilla.org Graveyard :: Administration, enhancement)

Description

[Martin Arndt]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050606 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050606 Minefield/3.0pre

Up to now, there's no way of deleting an account by yourself (except you mail the admins which is surely not a practical way)..

Additionally, some countries (like Germany for example) request service-providers to offer a way to their users so that the entire account can be delete if the user wants that.

Reproducible: Always

Steps to Reproduce:
1. Go to https://addons.mozilla.org/
2. Login
3. Click "My Account"
Actual Results:  
No option for deleting the account

Expected Results:  
A link or button "Delete account"

Comment 1

[Dave Garrett]

This sort of thing is rather uncommon for services with free accounts, as it's not really useful.  There's usually nothing worth deleting here, and if there is then we probably don't want that deleted so as to leave it for the other users.  (i.e. name for reviews, remaining add-ons, etc.)  You should be able to delete your add-ons and related files, but that's about it.  Additionally, implementing this would begin a steady stream of idiots complaining that they deleted their accounts...  Sorry, I just don't see the need.

If everyone deleted their old unused accounts, that would free up some used usernames, but realistically that ain't happening.  ;)

Comment 2

[Martin Arndt]

Well, all good points, but most websites offer this - even Firefox/Thunderbird offer an option to uninstall itself and delete my profile (yes, it's on my personal computer - but after all, it's still a profile/an account :))

And accidentally deleting your account can be prevented by a confirmation-mail one has to receive and click the link within the mail.. ;)

Lastly, it's very simple to implement such an option - so for the user's convenience, I'm still in favor of it.. :)

Comment 3

[Dave Garrett]

(In reply to comment #2)
> Well, all good points, but most websites offer this - even Firefox/Thunderbird
> offer an option to uninstall itself and delete my profile (yes, it's on my
> personal computer - but after all, it's still a profile/an account :))

Profiles are not accounts.  Big difference between a few of your files and an account on a server.  And, I dispute your assertion of "most"; some do, but not that many, especially with regard to these sort of light-use free sites that don't have much to delete.  You usually just have to abandon things if you don't want it anymore.  (maybe change your password to some random string, to lock it)  Admittedly, I agree, this isn't ideal.

> And accidentally deleting your account can be prevented by a confirmation-mail
> one has to receive and click the link within the mail.. ;)

There'd still be people dumb enough out there, but fair point.

> Lastly, it's very simple to implement such an option - so for the user's
> convenience, I'm still in favor of it.. :)

It's best to never assume something is "simple" unless you're the one going to implement and test and maintain it yourself.  :p

I say it's just not worth it without some more pressing reason, but then again that's just my opinion.  My guess is that it'll probably just be considered too low of a priority to bother with.  Maybe some day when AMO is fully featured and bug free...  ;)

Comment 4

[Martin Arndt]

I'm waiting for that day then.. ;)
(Although - except the broken pw-reset-thing - I didn't recognize any bugs so far.. :D)

Comment 5

[Basil Hashem [:baz]]

I'm going to revive this as I'm seeing more and more account deletion requests without any ability for us to do anything with these requests. Since account owners on AMO are associated with potentially many other objects (data in other tables), e.g. reviews, add-ons, versions, etc.. I suggest we scope this to the most common use case, a non-add-on author requesting account deletion.

Also, in chatting with our attorneys/paralegals it appears that we may need to implement this in order to comply with EU laws about "opt in"/registration. They are going to give me a full opinion in a couple of weeks.

So, here is my suggestion for a simple solution (rather than the full cascaded delete).

- Provide an admin interface to delete a user account
- Only allow the delete to take place if the user account is associated with no add-ons (e.g. can't be an author, viewer, etc..)
- Prompt to confirm if user reviews exist and confirm that they will be deleted
- Delete any reviews associated with the user
- Delete any developer replies associated with the user reviews being deleted
- Ensure we continue to maintain referential integrity on our AMO system (I'm not completely familiar with the schema, so please ask away if there is other data associated by user)

Nominating for 3.5.1

Comment 6

[Martin Arndt]

(In reply to comment #5)
> Also, in chatting with our attorneys/paralegals it appears that we may need to
> implement this in order to comply with EU laws about "opt in"/registration.
> They are going to give me a full opinion in a couple of weeks.

I already said that within the bug's description.. ;)
German (and EU, too) laws force service providers to offer an "delete all data associated with my name"-feature..

> So, here is my suggestion for a simple solution (rather than the full cascaded
> delete).
> 
> - Provide an admin interface to delete a user account
> - Only allow the delete to take place if the user account is associated with no
> add-ons (e.g. can't be an author, viewer, etc..)
> - Prompt to confirm if user reviews exist and confirm that they will be deleted
> - Delete any reviews associated with the user
> - Delete any developer replies associated with the user reviews being deleted
> - Ensure we continue to maintain referential integrity on our AMO system (I'm
> not completely familiar with the schema, so please ask away if there is other
> data associated by user)

I wouldn't delete all comments, reviews, etc. - Instead, I'd like to suggest that the comment and its author's name remain, but all other data (username, password, mail address, etc.) gets deleted.

That way, (useful) comments/reviews are still available after the user turned away from AMO (or changed his/her username) - surely the best for both, AMO users and the user in question him-/herself..

Comment 7

[Dave Garrett]

(In reply to comment #6)
> (In reply to comment #5)
> > - Prompt to confirm if user reviews exist and confirm that they will be deleted
> > - Delete any reviews associated with the user
> > - Delete any developer replies associated with the user reviews being deleted
>
> I wouldn't delete all comments, reviews, etc. - Instead, I'd like to suggest
> that the comment and its author's name remain, but all other data (username,
> password, mail address, etc.) gets deleted.
> 
> That way, (useful) comments/reviews are still available after the user turned
> away from AMO (or changed his/her username) - surely the best for both, AMO
> users and the user in question him-/herself..

I emphatically agree. Reviews, discussions, etc. are not part of the user account, they're things created _with_ the user account. Postings like these become public upon submission. (not sure exactly what the privacy policy is for this offhand) A deletion should delete the account and just leave a stub for these things, as suggested. If we'd like to wipe a little extra, the name could be removed and the reviews/discussions could then be listed as from "(account deleted)" thereafter. You could probably do this lazily by literally creating an account named "(account deleted)" and then simply moving all posts into it upon any account deletion.

If you do wish to implement a deletion feature then you really should (at least eventually) allow for deletions of full accounts with add-ons. Those are the users that could have a real need to delete their accounts, as they're the ones with something actually in their accounts to delete.

Comment 9

[Fred Wenzel [:wenzel]]

Un-duping, as this is the user-facing option, and bug 444003 covers admin deletion.

Comment 10

[Fred Wenzel [:wenzel]]

Attachment: (User-facing) account deletion

Wil, do you mind taking a look at this patch? It should be quite straightforward.

Notes:
- I did not forget l10n. I would like you to look at the wording etc. and comment if it's all right, then I'll localize it before check-in.
- Let me know if the "checkbox" UI is acceptable.
- Note that the code only takes care of reviews before the account deletion. If the user is an add-on author, they are prompted to change that. However, if they have, for example, filled out the t-shirt request form at some point, deletion will fail and they are prompted to contact amo-admins.

Once this patch lands, I will be able to wrap an admin interface around it (bug 444003).

Comment 11

[Dave Garrett]

The patch doesn't handle discussions. If users are going to be able to start deleting accounts once this is pushed, their old discussions should be anonymized too. As far as I know, they're still sitting around somewhere and need to be dealt with for when the discussions system is re-enabled. (bug 428139) Once the system is re-enabled, it'll need this anyway.

Comment 12

[Fred Wenzel [:wenzel]]

(In reply to comment #11)
> The patch doesn't handle discussions.

True -- since there are no discussions yet, I cannot anonymize data structures that I don't know yet. Certainly, that will have to be part of the discussions redesign.

Comment 13

[Fred Wenzel [:wenzel]]

Attachment: "Anonymous" user, ID 0

Sorry, forgot to attach the SQL that needs to be run for this to work: This adds an anonymous user with the ID 0.

Comment 14

[Dave Garrett]

Is there anything in place that would prevent a person from logging in as this user 0? If not, that'd probably be good to add.

Comment 15

[Dave Garrett]

Might I also suggest setting `firstname` to 'Account deleted' so the purpose of this stub account is shown if a user views its user profile. (i.e. clicks the name on one of the anonymized reviews)

Comment 16

[Dave Garrett]

A couple more issues to build upon:

1) As per comment 2 and comment 3, I think email confirmation would be appropriate for this. Users are idiots, and anything we can do to slow down permanent things like deletion would be good. I'm not completely opposed to just having a checkbox for confirmation, but then again I'm not the one who would field the complaints from confused users.

2) There's a spam risk I just thought of here:
  1. create an account
  2. spam to all hell
  3. delete account
  4. all spam is now anonymous

If a full user deletion feature is added for admins to delete spam accounts, this would render that ineffective. I don't expect this to be done frequently, but it is a possible exploit. Maybe log the re-assigned review IDs somewhere with this user ID so they could be looked up by an admin?

Comment 17

[Fred Wenzel [:wenzel]]

(In reply to comment #16)
> 1) As per comment 2 and comment 3, I think email confirmation would be
> appropriate for this.

Maaaybe. I am not convinced yet that even email confirmation keeps somebody from deleting their account if they don't want to get it.

> 2) There's a spam risk I just thought of here:

Very good point. In that case, we would need to approach this differently: The "delete account" feature would remove all personal identification from the account (email, name, etc.) but keep the IDs intact: Only the admin tool would be able to actually and completely *remove* an account (incl. attaching reviews to an anonymous user).

Wil, what do you think?

Comment 18

[Fred Wenzel [:wenzel]]

(In reply to comment #14)
> Is there anything in place that would prevent a person from logging in as this
> user 0? If not, that'd probably be good to add.

Yes: The password field is empty, and there's no MD5 hash that maps to an empty string.

Comment 19

[Wil Clouser [:clouserw]]

(In reply to comment #17)
> (In reply to comment #16)
> > 1) As per comment 2 and comment 3, I think email confirmation would be
> > appropriate for this.
> 
> Maaaybe. I am not convinced yet that even email confirmation keeps somebody
> from deleting their account if they don't want to get it.
> 
> > 2) There's a spam risk I just thought of here:
> 
> Very good point. In that case, we would need to approach this differently: The
> "delete account" feature would remove all personal identification from the
> account (email, name, etc.) but keep the IDs intact: Only the admin tool would
> be able to actually and completely *remove* an account (incl. attaching reviews
> to an anonymous user).
> 
> Wil, what do you think?

That sounds fine with me.

I think having email confirmation is overkill.  We could prompt the user for their password when deleting the account though.

Comment 20

[Dave Garrett]

(In reply to comment #19)
> I think having email confirmation is overkill.  We could prompt the user for
> their password when deleting the account though.

Sounds like a good compromise to me. We don't want users deleting already logged-in accounts without some kind of confirmation that it's theirs. Just make sure password autocomplete doesn't fill it in so users have to actually type in their password again.

Comment 21

[Fred Wenzel [:wenzel]]

All right: I will make another patch with the following key features:
- "deleting" an account does not delete the user ID and does not re-map any comments etc. but it marks a user account as "deleted" (will be a new field) and removes all personal information.
- add-on authors still won't be allowed to do that until they are not associated with any add-ons anymore
- confirmation will need both a checked box "I know this is not reversible" and entering their password.

Comment 22

[Fred Wenzel [:wenzel]]

(Note to self:
- make sure devs can't pick deleted accounts as add-on authors then
- make "account deleted" string localizable)

Comment 23

[Fred Wenzel [:wenzel]]

Attachment: SQL for a "deleted" flag

This is the SQL for a "deleted" flag in the users table.

Comment 24

[Fred Wenzel [:wenzel]]

Attachment: SQL: set email NULL in place of a deleted flag

Ah, I forgot to allow the "email" field to become NULL. Since it has a UNIQUE index on it, we will set it to NULL for all deleted users. That can serve as a deleted flag, so no need for an additional field.

Comment 25

[Fred Wenzel [:wenzel]]

Attachment: User account deletion (anonymize only)

As agreed, here's the patch that anonymizes the user account only. That will eventually allow admins to delete that account with all associations, if necessary.

Comment 26

[Fred Wenzel [:wenzel]]

(In reply to comment #24)
> SQL: set email NULL in place of a deleted flag

Just a heads-up; if you run this on a prod. database on your local machine, you may want to grab a coffee. Or lunch. And dinner. It almost took two hours for me.

Comment 27

[Dave Garrett]

This new patch still has the "deleted" flag added to "config/sql/remora.sql".

Also, the "modified" time should probably be updated here. (or is that automatic?)

Comment 28

[Fred Wenzel [:wenzel]]

(In reply to comment #27)
> This new patch still has the "deleted" flag added to "config/sql/remora.sql".

Thanks! I missed that.

Wil: I removed it. Please review the patch minus that detail.

> Also, the "modified" time should probably be updated here. (or is that
> automatic?)

Yup, Cake does that automagically.

Comment 29

[Wil Clouser [:clouserw]]

Comment on attachment 341270 [details] [diff] [review]
User account deletion (anonymize only)

I think it looks good with the change Dave mentioned.  Also, "anonymized" isn't a word.  I'd suggest replacing "...they will be anonymized." with something like "...they will no longer be associated with you."

Comment 30

[Dave Garrett]

(In reply to comment #29)
> Also, "anonymized" isn't a word.

Of course it's a word. It's just a relatively new word. ;) Nonetheless, "...they will be unassociated with your account" or something may explain things to users better.

Comment 31

[Fred Wenzel [:wenzel]]

(In reply to comment #29)
> (From update of attachment 341270 [details] [diff] [review])
> I think it looks good with the change Dave mentioned.  Also, "anonymized" isn't
> a word.

anonymize. Dictionary.com. Webster's New Millennium™ Dictionary of English, Preview Edition (v 0.9.7). Lexico Publishing Group, LLC. http://dictionary.reference.com/browse/anonymize (accessed: October 02, 2008).

In your face! ;)

Nonetheless, in the interest of the user, I'll go ahead and change it to your suggestion.

Comment 32

[Wil Clouser [:clouserw]]

Preview Edition?  No 'd' on the end?  What are you trying to pull, wenzel?

Comment 33

[Dave Garrett]

How about the real definition of what "is a word":
http://www.google.com/search?q=anonymize gets 398,000 hits
Usage dictates what the "real" words are, not dictionaries.

Thus endith this pointless tangent. :)

Comment 34

[Dave Garrett]

(In reply to comment #32)
> No 'd' on the end?

And "anonymized" gets 3,080,000 hits.

(last bugspam, I swear)

Comment 35

[Fred Wenzel [:wenzel]]

(In reply to comment #32)
> No 'd' on the end?

Well obviously, dictionaries contain verbs, not all their derivatives...

(In reply to comment #33)
> Thus endith this pointless tangent. :)

*nod* aaaaaall right.

Comment 36

[Justin Scott [:fligtar]]

arbitrarily

Comment 37

[Fred Wenzel [:wenzel]]

Checked in, including en_US l10n: r18846.
l10n pushed out to other locales in r18848. Will contact localizers shortly.

Also added the SQL from attachment 341269 [details] to the wiki. It needs to be run before deploying this.

Comment 38

[Stephen Donner [:stephend] Not actively reading bugmail]

Should I file a separate bug for non-existent contact string in:

"If you have additional questions, please contact %1$s for assistance.", which appears on https://preview.addons.mozilla.org/en-US/firefox/users/delete when you try to delete an account which has associated add-ons, or is that part of localization?  (Seems to me, if so, it'd already be in en-US, no?)

Comment 39

[Stephen Donner [:stephend] Not actively reading bugmail]

(Oh, or maybe preview needs the world-famous Apache restart to pick up gettext() changes?)

Comment 40

[Fred Wenzel [:wenzel]]

(In reply to comment #38)
> Should I file a separate bug for non-existent contact string in:
> 
> "If you have additional questions, please contact %1$s for assistance."

Thanks for pointing that out! I put the "sprintf()" calls in the wrong spot *oops*. Anyway, fixed in r18874.

Please try again after a little while when preview has picked it up. Sorry about that.

Comment 41

[Stephen Donner [:stephend] Not actively reading bugmail]

Should we target bug 458763 for 4.0.2, or is it safe to verify this bug in isolation, and deal with that one later?

Comment 42

[Fred Wenzel [:wenzel]]

From what I found out so far, the two bugs are not related: I experience the same behavior with JS disabled on the user edit page :( So while it's probably okay to verify this one, the other one is quite unpleasant and I am tending to delay 4.0.2 until we fix it, as it seems to be a general problem.

Comment 43

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using https://preview.addons.mozilla.org/en-US/firefox/users/delete; I tested with JavaScript both enabled and disabled, and the account I deleted was no longer valid at the login page.

I also tested the acknowledgment checkbox functionality, as well as an invalid password submission.