Please allow closed accounts to be archived on the local pod for the podmin (unless the user specifically requests complete deletion of account). When I close an account, I can’t access it at all anymore, even on my own pod. I would like for it to not be completely deleted, rather archived (still shows ‘this account has been closed’ for other users, but not for podmins and moderators).
Reason/Justification: Podmin may need to access posts and information on the account for investigative purposes in the future. User may request download of their contents AFTER closing their account but BEFORE deleting their account.
I’m afraid I’m not in agreement with this. One of diaspora*s key offers is ownership of personal data. While that’s by no means perfect, we should definitely not build in any features that work against this.
If there are genuine potential threats to podmins from deleted data, that is something we should look at and think of ways to address, but I don’t think this can be the solution to that problem.
I do know of a podmin who recently received threats about legal action over now-deleted data, but I also know that such threats are usually hot air. I advised them to ignore it and nothing came of it. There are more or less above-board lawyers out there who will send out threatening letters in the hope of some people being frightened into a monetary settlement. In that way this is little more than a scam, and I don’t know whether one could legally be held accountable for data that one no longer has.
You could of course fork the code and change it for your own pod, but if you do, I think you should (a) make it VERY clear to all your users and prospective users that their data will not be deleted when they ask for it to be deleted, and also that you should remove any diaspora* branding and make clear that, although your node runs a fork of diaspora*s code and federates with all other pods, your node is NOT a diaspora* pod.
On your past point, I can’t see any circumstance under which a user would actually want to close their account but not to delete their data. This is something that Facebook does surreptitiously, and that is a matter of consternation to many people who want to delete their Facebook data; and it really is against diaspora*'s philosophy. So I don’t see any call for a separate ‘close [but don’t delete]’ option in the user settings. There is a strong warning before someone closes their account that their data will be deleted as a result, and I think there’s also a prompt to download their data before they close their account.
I’m on sabattical, but got this email so I’ll respond this way.
I fully understand and agree with Diaspora*'s position on privacy and security, and this idea in no way deters from that position. If this feature were to be put in place, users should be notified of this, and agree to it if they are already members. New members would see this in plain sight upon creating their accounts, for which there should be an option to opt out of this in the settings.
The biggest reason I’m even bringing this up is due to security measures on my own end as an administrator. So far I haven’t had any reason to require any such necessary measures; however, that doesn’t remove the justification of the measure itself. It’s quite difficult for me as a systems administrator to narrow down exactly who is responsible for any detrimental actions on my pod if, when I go to their account, I, the Systems Administrator, can’t even see their profile page. Even I as the SA and owner of the pod have zero recall on what this person did, who they are, what they’ve posted…anything. In fact, all I DO have is in my user list itself a mention of their possible username and maybe a hint at their email address.
I’ll leave this with a single point which I hope resonates with anyone who gives a rip about the security of their own systems. This measure of completely deleting an account upon closing it does wonders for the security and privacy of the end user, but absolutely and totally screws over the security and protection of the pod owner themselves. If anything were to happen on my pod, I’d be utterly and completely incapable of actually dealing with it in such a way that would ensure the safety of the rest of my members. There are two parties at play here, not just the end user. We surely need to take that into perspective. I reiterate, my goal here isn’t to violate anyone’s privacy, and never was, never will be. Surely there is a way to do this in which every party can agree?
Lack of information for me as the systems administrator means I can’t properly protect my pod from potential threats, such as DDoS (as I could protect against a specific IP address, but then I would have no way to see if there was a specific user on my pod who initiated the attack if their IP happens to be associated with said attack). If a member publishes incriminating content on my pod, since it’s hosted in the USA, I am thereby responsible for such content, and I’d also like to have the ability to hold such persons accountable [i.e. child pornography, DOX information, online harassment and threats of violence, etc.]
If you backup your database, uploaded content, and logs (which anyone who “gives a rip about the security of their systems” should be doing), you get access to all the information you would from saving a user’s deleted account data (and if I hacked your system, I could probably delete any backup of the account you created), and protections from attacks that didn’t involve the deletion of a user’s account, and the more likely reasons data would be lost that aren’t malevolent.
I do continuous offsite database backups using postgres streaming, and hourly backups of uploaded user content. What can I get from capturing deleted accounts that I cannot get from backups?
So, here’s the thing. diaspora* is built on the principles of giving users the control over their data, and implementing any kind of data retention would be a violation of exactly that principle. For us to implement something like that, we’d need a very good reason to do so, and so far, I haven’t seen one.
I’m having a really hard time thinking about a scenario where an attacker would first create an account, then close it, then proceed with attacking the pod. Let alone attack the pod with the same IP they used to use diaspora with. Especially in the case of a DDoS, the very nature of a DDoS is the source of attack being distributed over multiple hosts, and no person in the right mind would run an attack from an IP they’re actually using for something. I doubt the usefulness of user data in that case.
Well, first: no, you are not. Not at all. You are responsible if you fail to act on illegal content after it has been reported to you, but there is zero obligation to proactively monitor all activity to spot illegal actions. More over, deleting contents actually resolves any legal action, unless a governmental entity asked you to provide user details, or have straight up seized data/hardware. In the first case, if the user has deleted data, too bad, but not your issue either. To be vulnerable to obstruction of justice charges, they’d have to come up with a proof that you manually deleted the contents in question, which you didn’t do. And in the second case, if the seized hardware does not contain viable information, then they seized the hardware too late, but that’s also not your issue.
There are few cases where you’d be legally required to retain data at all, and those cases would be situations where you, for example, host a pod for government officials, or if your pod is used by a publicly traded company to exchange company information. These cases are not what diaspora* is designed for, so, uh, I’d rather stick to our principles then.
Thanks for the feedback guys!!