thinking about "nuke my account" feature

[josh]

I'm thinking about adding a new feature that would allow you to irreversibly delete almost all your account data - any beta testers ?

It will be somewhat labor intensive to test, but I'll do that. Actually, I wanted to discuss exactly what the feature would do, and how it would be accessible and stuff.

As you may know, we shouldn't actually delete the main account record with the username, because if we did, then another user might sign up with the same username, and then might get sensitive email messages intended for the previous holder of the username, and I just can't get caught up in that.

But it's another thing to delete all the Address records, the watchwords, the trusted senders, the eaten message log, etc., leaving only what's necessary to prevent a double sign-up.

Questions I have -

1. should the password data be left alone? It's one-way encrypted, of course, but it is a remnant of what the User did. It can't be blank, but it could be set to something random, provided that process was really good so that someone couldn't ever figure out what it was.

2. should the account be administratively disabled? That would sort of take care of the password problem, because even if someone else did manage to log in, the account would still never be able to pass any email through. But if the password is left alone and the account is not disabled, then the original user could come back and start using the account again, which might be a good idea.

2.5 I guess another approach would be to create a new table of retired usernames, and put the username in that table, then actually delete the User record, and modify the sign-up code to check the retired usernames table to prevent a double sign up. This would make it difficult if someone really really wanted to start using their account again, of course. And to me, that seems like a possibility - you remember a service you were using and now you're locked out, and if you could just get that one password reset email... you know.

3. should the user be forced to receive all the account information that's about to be deleted in XML form (as you can currently do by clicking on an obscure link in advanced mode)? Should this be optional?

4. I'm sort of clueless on the actual use case and expectations for how the user interface flows, with warnings, etc. It all has to be translated into all those languages, too, of course.

5. anything else? Is this even a good idea?

[SysKoll]

I don't see a use case that would require this feature, but maybe other people would like to chime in?

[ragingdragon]

I can imagine wanting to use this feature .. though on a smaller scale .. I've created a couple of test email ids and I don't want to have to see them .. even in hidden list .. Also, if I feel my account gets cluttered, I might want to clear the complete list and just start from scratch .. and manage the emails as they start flowing in .. Other than that, your ideas might make sense for someone trying to get rid of his account completely to hide his behaviour .. but it can never be truly hidden since if the account is reactivated, the emails might start flowing in again ..

[josh]

I can imagine wanting to use this feature .. though on a smaller scale .. I've created a couple of test email ids and I don't want to have to see them .. even in hidden list .. Also, if I feel my account gets cluttered, I might want to clear the complete list and just start from scratch .. and manage the emails as they start flowing in .. Other than that, your ideas might make sense for someone trying to get rid of his account completely to hide his behaviour .. but it can never be truly hidden since if the account is reactivated, the emails might start flowing in again ..

Yeah, I have to admit, a lot of the limitations on the service are because I don't want to have to answer a whole lot of support emails from people who aren't understanding things (like why their deleted addresses keep showing back up). Sounds selfish, and it is, but then it's worth thinking about how many services like this have come and gone, and I have to believe that a heavy support burden would be enough to scare a lot of people off (and perhaps it has), so maybe it's enlightened selfishness? Heh.

[ragingdragon]

Well sadly its true. And I would much rather have this service running than have it try to be perfect. Appreciate it!

[gourmet]

I don't see a use case that would require this feature, but maybe other people would like to chime in?

I might like to rotate my temp accounts. So I would use account for an year, and then destroy it and open new one. One option is to abandon the old account, but killing it would be more efficient, especially if data realted to it is removed. Another thing is that it could bounce messages (?!?), because I personally consider not bouncing messages as kind of design flaw, which just causes additional burden to servers. These are just my thoughts.

I'm using some other mail forwarding services now to "rotate accounts", so that history is deleted and there's no clear connection between addresses I have been using.

[VanguardLH]

If the point of this new feature is to kill an account rather than abandon it (which means new messages through non-zeroed aliases will still get forwarded), why not just make use of the existing Prefix function. When I had accounts that I wanted to close but because there was no "close account" function, I would enter a string on characters as the Prefix that would likely never get used by any sender. The prefix has to exist on all incoming e-mails; else, they get discarded. So I would specify something like "##$$--dead-account--$$##" as the prefix. No e-mails are going through any newly auto-generated aliases in that account. I did also have to go through all existing aliases and zero them out (and optionally mark as hidden).

So it seems a "kill account" feature could simply specify a non-blank Prefix value that was randomly generated by SG to block any further e-mails being accepted by an SG account for new aliases (those that would be created anew with the arrival of the incoming e-mail). The "kill account" feature might also include character(s) in the Prefix string that users would not normally be allowed to enter. If they entered the special kill characters then they would get an error saying those weren't available. Only the "kill account" function could insert those special characters into the Prefix string. The "kill account" feature would also have to disable all old or existing aliases by zeroing out their "remaining messages" count (and optionally marking them as "hidden"). The account continues to exist (to avoid new users from usurping accounts for prior users) but no new e-mails will be accepted (they don't have the Prefix string in them) and no e-mails can pass through any existing aliases (as those had their use-count zeroed out).

I can do all that manually (set Prefix to non-zero unlikely string and zero out existing aliases) but it would be handy and more reliable to have a script automate the task, especially if the
account has hundreds of existing aliases so I don't have to zero them all out one by one myself.

I wouldn't bother altering the password to the SG account. It's possible someone decides to backtracks and wants to revive an old SG account. If they can still log into it, they could blank out the Prefix string to go forward with that old previously-abandoned account. If the account isn't going to get physically purged from the database but instead is let around, might as well as make it possible for its prior user to re-login should they later change their mind.

[gourmet]

1. should the password data be left alone?
2. should the account be administratively disabled?
2.5 I guess another approach would be to create a new table of retired usernames.
3. Should the user be forced to receive all the account information that's about to be deleted in XML form.
5. Is this even a good idea?

1. No, it should be deleted. Afaik, if account is nuked, only data remaining after nuke should be the account name, and status which tells that account is nuked. This information can be also used to prevent account recreation.
2. Yes, done is done, and that's it, no way to recover is the right way.
2.5. That's minor technical detail. It doesn't matter how the information is stored, it's just that it's stored. Is it same table, with flag, or separate table, doesn't really make any difference.
3. No? Why? If they want to nuke the account and agree with it, then that's it, having XML dump is nice option, but it's really pointless to force it.
5. Yes, I like it. It's better than abandonin accounts that might be later abused if password is discovered or the forwarding address is assigned by email provider to someone else etc.

If the point of this new feature is to kill an account rather than abandon it (which means new messages through non-zeroed aliases will still get forwarded), why not just make use of the existing Prefix function.

No, it isn't nearly same thing at all. As well you could set your account to forward to some random address at mailinator, but it isn't same thing either.

[VanguardLH]

If the point of this new feature is to kill an account rather than abandon it (which means new messages through non-zeroed aliases will still get forwarded), why not just make use of the existing Prefix function.

No, it isn't nearly same thing at all. As well you could set your account to forward to some random address at mailinator, but it isn't same thing either.[/quote]

Well, then, please elucidate to the rest of us what is expected to be the effect of killing an account?

How would a killed account behave differently for new e-mails sent to it versus an account with a non-blank prefix that is never used in those new e-mails along with a zero use-count for all old aliases? Nothing. Both methods result in eating those newly received e-mails.

How would a killed account prevent a prior user from resuming use of SG under a different account versus that same user returning to using the same old SG account? Nothing. SG is used in either scenario to handle aliases.

Since this will be a new feature, prior users will continue using their old habits in managing their SG account. If they abandoned them before, you really think they are going to bother logging in later to kill the account? Even Microsoft knows that rare few of its users re-login to kill old accounts versus just abandoning them. Adding a "kill account" option isn't going to change the number of abandoned accounts. However, with Hotmail, if you delete an account, you have a grace period to come back to reactivate it should you change your mind. Your suggestions means the account goes dead and remains that way, similar to how Gmail works on cancellation. Of course, no one ever changes their mind even about account deletion.