-
-
Notifications
You must be signed in to change notification settings - Fork 7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Delete account function? #109
Comments
What would be the implications of deleting an account from the technical perspective? It would be problematic, for example, if someone could immediately register a new account with the same username. Remote instances that may not be aware of the account's prior deletion would keep following the new, now impersonating account. So the username needs to stick around after deletion. Then every status by the user would be deleted, every deletion would need to be federated which might take a while (imagine deleting 40,000 statuses - you'd need to send the updated "deleted" status for every remote follower x 40,000). So this solution would be a soft delete then - as much information as possible is removed but basic structure and some pointers must be retained. So perhaps we could delete avatar, display name, bio, delete all statuses/media, unfollow everyone the account has been following, force all local users to unfollow it (cannot force remote accounts to unfollow though). Perhaps disable login on the account. That's quite a big task, isn't it |
For me as user it's not very interesting if this is a big task. I tested out your project, wanted to see how it is. It's not the great one and now I can't delete my data. I do not want you to keep data from me. |
@Gargron Ideally, OStatus would include a "delete" status, sendable to a server, which tells that server to (optionally, depending on server policy) mass-delete or mark-as-deleted any status from that user, so that you only need to send one update rather than one per status. |
Twitter lets this happen, but in Twitter's case handles are not the primary key (that is, Twitter knows that a new user with the same handle is not the same as the old user), so it's not too bad. What does GNU Social use as the primary key? If it's the handle, then I see the problem. |
There should definitely be a way to delete your account, from a data privacy perspective. I think it may even be a legal requirement in some countries to be able to leave a service. Most commercial services (Facebook, Twitter) seem to offer the option to deactivate your account, which hides all your content and gives you the option to one day return. Some then let you go further and remove your data from the platform permanently if you wish. For my part I opened an account on one instance before realising it was very localised to a country whose language I don't speak, then found there was no way to export to a different instance. I had to open a second account on the new instance, only to then find there is no way to delete my old account - which people can still find and follow. Very confusing. I also imagine many like the idea of an open source platform alternative to twitter, or other social platforms, that will give them full control over their own data. Right now we don't have that. |
Same here, as a user I would like to be able to have my account deleted. |
It'll definitely be needed in the future, in France it's an obligation for a service to provide its users with a way to access, modify and oppose any information stored on them (see Loi Informatique et Libertés du 6 janvier 1978). Maybe you can just deactivate the account for some period of time when the user asked to delete it so that the deletion has the time to propagate to the different instances. But as @TazeTSchnitzel commented, if the users are identified by their handle as the primary key, here resides the main problem... |
Absolutely needed. I'm not going to be using mastodon until I know there's some kind of delete account that I'll be able to use if needed. It's basic. |
I was invited for mastodon.network but then noticed I already created an account on mastodon.social last year. Same email address. So I'd like to delete my latest account (from mastodon.network) - assuming "federated timeline" means both Mastodons end up in the same "world". |
I agree with the general sentiment that this should be bumped up in priority. A lot of users are using this to avoid lock-in, so it's quite natural to expect a way to wipe your data from an instance you don't control if you decide to move to another one. |
Agree 100% about users coming here to escape lock-in. An option to export our data and then hide or permanently delete from Mastodon would be ideal. It would also be great if you could then choose to import it to a new instance if you wanted, or just keep it offline for your own use/delete it forever. |
Make the account locked; if the user doesn't return in 30 days, all the toots are deleted and the username becomes available again. |
Just a note on the actual propagation of a delete request across multiple instances. You will inevitably run into people who will modify their instances to ignore/deny requests to delete data. The motivations for this kinda thing are far ranging, see politwoops/reddit undelete/sleazy advertiser/data scientist/troll/internet archivist/etc. Whatever the reason though the solution proposed should take this in consideration. You also may have to deal with a similar issue in the future when very old instances suddenly come online after being down for months/years. |
@Spunkie There's absolutely nothing that can be done about that. In a federated system, all you can do is ask. |
@joshtriplett I agree, that's why I wanted to chimed in. People are comparing this to how delete works in centralized services like twitter. Personally I think account deletions should be handled internally as a migration to a global "deleted-account" account or into individual "deleted-account-101xxx" accounts. The original account username/email/bio/avatar/whatnot will be deleted but the actual toots and history will remain somewhat intact, and then you attempt to propagate that. At least on instances the account was not originally created on that is. I would think far less people/instances would object to this type of migration/anonymizing request than a simple request to delete all history. To further the mastodon is like email analogy. It would be great and all if gmail/hotmail/yahoo got together and planned a standard that let their users unsend(delete) emails between their services if it's still marked unread. But even if that happened, every other email provider would be under no obligation to respect those request for deletion. |
You can still delete an email address/account though any email provider. The emails will stay, but that address is going to bounce. Maybe people in this thread mean different things when they talk about deletion, hence the confusion. The questions of whether the handle should be freed afterwards or not, whether toots will be kept or deleted are beyond my understanding of how the system actually works behind the scenes. Maybe if this issue could be split into 2 or 3 covering each of these aspects it'd make it better to discuss each separately. |
I don't see what the big deal is. I had a Twitter account (@JIMDOG) and I deleted it back in 2012 in a fit of rage (long story). It was then picked up by some other guy. I regret giving up the name but it's too late now. If you go to Twitter and search for posts by @JIMDOG and scroll down, you'll see that posts on Aug 2nd 2012 and prior are all mostly about running. Those are all me... everything since Dec 2012 is the new @JIMDOG. Nothing I can do about it. So why wouldn't this be the same? |
I completely agree. The main technical things I think are to be able to (1)
disassociate yourself from the handle (2) delete personal profile data
associated with it (3) have the ability for you (or someone else) to reuse
that handle on another mastodon instance. I don't think it's plausible to
require that your previous toots become inaccessible - in the (in my view
not very accurate) email metaphor, I can't force my recipients to delete
all the emails I sent them.
…On 7 April 2017 at 10:58, jimdogx ***@***.***> wrote:
I don't see what the big deal is. I had a Twitter account ***@***.***
<https://github.com/JimDog>) and I deleted it back in 2012 in a fit of
rage (long story). It was then picked up by some other guy. I regret giving
up the name but it's too late now. If you go to Twitter and search for
posts by @JIMDOG <https://github.com/JimDog> and scroll down, you'll see
that posts on Aug 2nd 2012 and prior are all mostly about running. Those
are all me... everything since Dec 2012 is the new @JIMDOG
<https://github.com/JimDog>. Nothing I can do about it. So why wouldn't
this be the same?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#109 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AZsofHRdyydIwMi_SOMUj6mKvwFgwoDXks5rtk8ggaJpZM4Kfrqg>
.
|
@planet4589 : the email comparison isn't good, because emails are private. A better and accurate comparison is with content you published on a website. You definitively can ask the owner of a website to delete the content you published on her website, because you own the copyright of your toots. Unless you agreed to specific terms of service or published your toots under a free license, the owner has to delete your content, or you can sue them. It may be unpractical and excessive to go that far, yet it's important for instance providers to note that the law is by default on the side of the person who wants to leave the service. Users should be provided with an option to require automatically all the federated instances to delete their content, because doing it manually is virtually impossible. It means that there is a high cost of leaving, which is a disservice to the growth of the project. |
What about a key created with each account that must signs every toot ? A new account have a different key so it's not the same for followers and they can be alerted. |
As far as I understand I can manually delete my toots, one by one, as things stand (correct me if I'm wrong). Having the option to delete them automatically when you delete your account, or hide and/or download a copy of them...is a choice about how much control Mastodon wants to give users over their data and the deletion/deactivation options. Somewhere along the way you may also need a legal disclaimer if you can't ever delete your toots. Lots of policy questions that need to be answered before working out how to implement, ones I can think of are:
At a minimum there need to be a way to 'close' your account and 'remove' yourself from the handle. What that means in practice however...depends |
I agree with the view that the user should be able to delete their toots from the instance, remove all follows/followers, and delete their local profile permanently, releasing the username for someone else to take if they want. I like the idea of being able to export your toots/media before you go, too, though I question the feasibility and usefulness of importing it to another instance. It's nice to have it for yourself though. I think it would make sense to do something to notify remote instances that the user no longer exists. The remote instance can do what they like with that information - default for Mastodon should probably be delete the user's profile and any cached federated toots from them. Other GNUsocial instances might do nothing, or just flag the cached profile as inactive. I think that's OK as long as users are given the right messaging that their posts may remain cached by external instances (or any service that prowls public timelines). Private posts can probably be assumed deleted since they were never federated. |
My preference would be for my name to be replaced with "abandoned" (with the option of replacing the bio with "moved to [address]"), and for it to automatically delete all my posts, remove my avatar, unfollow everyone, and post a single "this account has been deleted" post. That way no one can pretend to be me, it notifies my followers that I'm gone, it gives people a way to find my new presence if I want, and I don't have to go through and delete my thousands of posts one by one. |
Slight tangent, but raises another key point in that social media identity theft and trolling takes on a whole new level of complexity when someone can take your username and photo on every other instance to your original one. Username squatting on other instances could also make it impossible for you to switch instances and keep the same name if you ever get targetted. Any way around this or to guard against it? This feeds into this debate because I think services like Twitter will shut down accounts purporting to be someone else and then give the handle to the person in question (usually a celebrity or politician). If we don't have any way to delete accounts the system could be open to abuse. |
HI, I know this is mainly a technical discussion but -as I just made the request to the admin of my instance- I was pointed to this discussion. BTW. I agree with dhardy92 (above): why not create a public/private key for every user and use that key to sign all transactions. Kristoff |
With the addition of private toot federation, some form of remote delete request is essential. |
If you're administering an instance and need to completely delete an account on the local instance (for legal reasons, to deal with name squatting, etc.), you can run the following: RAILS_ENV=production bundle exec rails c |
@thesk8ingtoad thank you for this - tried it and works, however if you click on a mention of the deleted user from another user, the deleted user profile still opens - yet you can't follow them! I checked again with: and they are not found on the system - so maybe that's a bug? |
@saggel I don't seem to be able to reproduce the behavior you describe. I tried creating two test users and having test user B mention test user A several times before deleting test user A. I get a 404 error when clicking on mentions of deleted users rather than an empty page. Did you run both the Account.destroy and User.destroy commands? |
@thesk8ingtoad what happens if you search for the deleted users? User.find_by!(email: 'deleted@useremail.com') they are not there! |
@saggel did you also make sure to run the Try
To do both (if you haven't already deleted users)
(note—I haven't tried this. test it on a dummy instance first) |
@nightpool yep - that did the trick!!! Now everything is sorted, the user doesn't appear on search results and the mentions are not linked to the user profile! Thank you very much!!! |
I'm glad the administrators have figured out a way to delete users from their instance, but when will users be able to delete their own account? |
@ajanvier same requirements are listed on current EU law. http://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1493967534436&uri=CELEX:32016R0679 Law text
|
this needs to be made a higher priority. it's getting to the point where we're seeing admins less active or abandoning instances, and users should not be expected to delegate this level of control of their accounts to absent admins, or admins who end up being untrustworthy or hacked. (I'd also like to reiterate the legal requirement, and "just ask the admin to do it" really isn't going to cut it as anything more than an immediate bandaid for the very immediate future.) i've got an account on an instance that appears to be losing the admin's interest, and is a few versions behind with no response from the admins, and while i'm okay with waiting awhile to see what happens, it's getting to the point where i'm thinking about when i should worry that the admin doesn't have control of a server any more, or if there will ever be a point when there are security concerns as a result of an instance/server being a few versions behind. i understand this is more complex than i can fully appreciate as an end-user who doesn't code, but that doesn't change the fact that this is an incredibly important fundamental need and something users deserve. a potential first step might be (again, i say this as a non-coder) the ability for a user to remove their data from a server in one fell swoop, with the understanding that toots that have been propagated out into the fediverse may not be recalled (this is not unlike sending an email to someone and then deleting the email account: the emails don't disappear, but i can't reply to or look up that account once it's been deleted). a username could be frozen and never reused, or reused only after a set period of time (a month, 6 months, whatever). that doesn't necessarily meet all the requirements of the EU's right to disappear, but i reiterate the email account example. a user @yahoo.co.uk's email account doesn't recall and delete all previously sent emails, but they can certainly delete the actual account and everything hosted by that domain. |
I did not examine the security model of inter-instance communication yet but I would like to make a warning: a "remote delete" function has better to be very secure! Any weakness in the way it is authenticated and authorized will be exploited for a denial-of-service attack (attacking the account of a guy I don't like by sending lying deletion requests). |
Also (and it does not seem it was mentioned yet), I think it would be a bad idea to keep the username forever after the deletion: it would allow people to "freeze" a name by registering in every possible instance, then deleting the account. (A grace period of, say, 30 days, would be OK.) |
Adding in @Hoodiek 's discussion on discourse about this feature. |
Amazing! :) Thank you! <3 |
Thank You for Clarifying we really need that function!!! I will now recommend to all my friends! |
Change empty playlist message
* added notification cleaning drawer * bugfix * fully implemented set operations for notif cleaning * i18n for notif cleaning drawer & improved logic slightly. Also added a confirm dialog * - notif dismiss "overlay" now shoves the notif aside to avoid overlap - added focus ring to header buttons - removed notif overlay entirely from DOM if mode is disabled * removed comment * CSS tuning - inconsistent division lines fix
use-custom-scss
add TrendTag function and API
Fix a bug that registration settings about qiita cannot be updated
Serialize text-less statuses as '.' over OStatus (fixes mastodon#7856) (mastodon#8126)
…ript fix PreserveOldLayoutForExistingUsers
I am sorry for commenting on such an old issue, but I was hoping for a bit of clarification: Is the account deletion currently implemented in such a way that the username and the email are freed? If yes, how is that done, since the website currently warns you that the username and email will be unusable forever? If it's not yet implemented in such a way, when is it expected to be? |
@ifohancroft Because of the risk of impersonation, we do not expect to ever allow a username to be reused, except in the case of manual admin intervention. |
Thank you! I feared I might get such a reply. |
Where is that function or when comes it?
The text was updated successfully, but these errors were encountered: