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

Closed
ForzaSFerrari opened this Issue Oct 25, 2016 · 54 comments

Comments

Projects
None yet
@ForzaSFerrari

ForzaSFerrari commented Oct 25, 2016

Where is that function or when comes it?

@Gargron

This comment has been minimized.

Show comment
Hide comment
@Gargron

Gargron Oct 26, 2016

Member

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

Member

Gargron commented Oct 26, 2016

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

@ForzaSFerrari

This comment has been minimized.

Show comment
Hide comment
@ForzaSFerrari

ForzaSFerrari Oct 27, 2016

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.

ForzaSFerrari commented Oct 27, 2016

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 Gargron added the enhancement label Nov 2, 2016

@joshtriplett

This comment has been minimized.

Show comment
Hide comment
@joshtriplett

joshtriplett Nov 12, 2016

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

joshtriplett commented Nov 12, 2016

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

@hikari-no-yume

This comment has been minimized.

Show comment
Hide comment
@hikari-no-yume

hikari-no-yume Nov 22, 2016

Contributor

It would be problematic, for example, if someone could immediately register a new account with the same username.

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.

Contributor

hikari-no-yume commented Nov 22, 2016

It would be problematic, for example, if someone could immediately register a new account with the same username.

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.

@Shadician

This comment has been minimized.

Show comment
Hide comment
@Shadician

Shadician Apr 5, 2017

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.

Shadician commented Apr 5, 2017

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.

@mvdwoord

This comment has been minimized.

Show comment
Hide comment
@mvdwoord

mvdwoord Apr 5, 2017

Same here, as a user I would like to be able to have my account deleted.

mvdwoord commented Apr 5, 2017

Same here, as a user I would like to be able to have my account deleted.

@ajanvier

This comment has been minimized.

Show comment
Hide comment
@ajanvier

ajanvier Apr 5, 2017

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

ajanvier commented Apr 5, 2017

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

@planet4589

This comment has been minimized.

Show comment
Hide comment
@planet4589

planet4589 Apr 6, 2017

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.

planet4589 commented Apr 6, 2017

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.

@mackaaij

This comment has been minimized.

Show comment
Hide comment
@mackaaij

mackaaij Apr 6, 2017

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

mackaaij commented Apr 6, 2017

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

@kaishin

This comment has been minimized.

Show comment
Hide comment
@kaishin

kaishin Apr 6, 2017

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.

kaishin commented Apr 6, 2017

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.

@Shadician

This comment has been minimized.

Show comment
Hide comment
@Shadician

Shadician Apr 6, 2017

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.

Shadician commented Apr 6, 2017

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.

@Oreolek

This comment has been minimized.

Show comment
Hide comment
@Oreolek

Oreolek Apr 7, 2017

Make the account locked; if the user doesn't return in 30 days, all the toots are deleted and the username becomes available again.

Oreolek commented Apr 7, 2017

Make the account locked; if the user doesn't return in 30 days, all the toots are deleted and the username becomes available again.

@Spunkie

This comment has been minimized.

Show comment
Hide comment
@Spunkie

Spunkie Apr 7, 2017

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 commented Apr 7, 2017

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.

@joshtriplett

This comment has been minimized.

Show comment
Hide comment
@joshtriplett

joshtriplett Apr 7, 2017

@Spunkie There's absolutely nothing that can be done about that. In a federated system, all you can do is ask.

joshtriplett commented Apr 7, 2017

@Spunkie There's absolutely nothing that can be done about that. In a federated system, all you can do is ask.

@Spunkie

This comment has been minimized.

Show comment
Hide comment
@Spunkie

Spunkie Apr 7, 2017

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

Spunkie commented Apr 7, 2017

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

@kaishin

This comment has been minimized.

Show comment
Hide comment
@kaishin

kaishin Apr 7, 2017

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.

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.
I would like to have a way to "deactivate" an account in an instance, as I way to let others know that I am no longer interested in being mentioned using that handle/instance. The same way I can just remove my email address from an email provider or server and senders will know when they try to reach me using that address.

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.

kaishin commented Apr 7, 2017

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.

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.
I would like to have a way to "deactivate" an account in an instance, as I way to let others know that I am no longer interested in being mentioned using that handle/instance. The same way I can just remove my email address from an email provider or server and senders will know when they try to reach me using that address.

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.

@jimdogx

This comment has been minimized.

Show comment
Hide comment
@jimdogx

jimdogx Apr 7, 2017

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?

jimdogx commented Apr 7, 2017

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?

@planet4589

This comment has been minimized.

Show comment
Hide comment
@planet4589

planet4589 Apr 7, 2017

planet4589 commented Apr 7, 2017

@jeanbaptisteb

This comment has been minimized.

Show comment
Hide comment
@jeanbaptisteb

jeanbaptisteb Apr 9, 2017

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

jeanbaptisteb commented Apr 9, 2017

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

@dhardy92

This comment has been minimized.

Show comment
Hide comment
@dhardy92

dhardy92 Apr 9, 2017

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.

dhardy92 commented Apr 9, 2017

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.

@Shadician

This comment has been minimized.

Show comment
Hide comment
@Shadician

Shadician Apr 9, 2017

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:

  • Can you delete or deactivate an account handle?
  • Can you delete your toots?
  • Can you export and save a copy of your toots for your own use?
  • Can you deactivate and later return to an account?
  • Can you restore your account/toots if you change your mind at any point?
  • Can you move your toots data and/or handle to another instance? (how do you redirect people?)
  • Once you leave the service can someone else take over your account with the same handle?

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

Shadician commented Apr 9, 2017

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:

  • Can you delete or deactivate an account handle?
  • Can you delete your toots?
  • Can you export and save a copy of your toots for your own use?
  • Can you deactivate and later return to an account?
  • Can you restore your account/toots if you change your mind at any point?
  • Can you move your toots data and/or handle to another instance? (how do you redirect people?)
  • Once you leave the service can someone else take over your account with the same handle?

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

@wolfteeth

This comment has been minimized.

Show comment
Hide comment
@wolfteeth

wolfteeth Apr 10, 2017

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.

wolfteeth commented Apr 10, 2017

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.

@Cassolotl

This comment has been minimized.

Show comment
Hide comment
@Cassolotl

Cassolotl Apr 10, 2017

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.

Cassolotl commented Apr 10, 2017

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.

@Shadician

This comment has been minimized.

Show comment
Hide comment
@Shadician

Shadician Apr 10, 2017

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.

Shadician commented Apr 10, 2017

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.

@on1arf

This comment has been minimized.

Show comment
Hide comment
@on1arf

on1arf Apr 11, 2017

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.
May I add that -from a user perspective- people do have the "right to be forgotten".

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

on1arf commented Apr 11, 2017

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.
May I add that -from a user perspective- people do have the "right to be forgotten".

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

@Draky50110

This comment has been minimized.

Show comment
Hide comment
@Draky50110

Draky50110 Apr 20, 2017

So will there be an account deletion possibility or never ?

Draky50110 commented Apr 20, 2017

So will there be an account deletion possibility or never ?

@velw

This comment has been minimized.

Show comment
Hide comment
@velw

velw Apr 22, 2017

This is a priority. Users mustn't be expected to put their data into a system if they have no way to remove that data. This has been a basic concept in data protection legislation for a very long time.

Respecting requests to delete user data on request should be a requirement to remain within a federated network of instances. Even if it's not automatic, it should be possible for users to flag "misbehaviour" by an instance so that it can be removed, like a bad node in a Tor network that threatens to undermine the security of the whole endeavour. Instance administrators could re-code any functionality - if the network is to be trusted and safe there has to be some mechanism to discourage that.

velw commented Apr 22, 2017

This is a priority. Users mustn't be expected to put their data into a system if they have no way to remove that data. This has been a basic concept in data protection legislation for a very long time.

Respecting requests to delete user data on request should be a requirement to remain within a federated network of instances. Even if it's not automatic, it should be possible for users to flag "misbehaviour" by an instance so that it can be removed, like a bad node in a Tor network that threatens to undermine the security of the whole endeavour. Instance administrators could re-code any functionality - if the network is to be trusted and safe there has to be some mechanism to discourage that.

@expenses

This comment has been minimized.

Show comment
Hide comment
@expenses

expenses Apr 22, 2017

Contributor

@velw

This is a priority. Users mustn't be expected to put their data into a system if they have no way to remove that data. This has been a basic concept in data protection legislation for a very long time.

Agreed.

Respecting requests to delete user data on request should be a requirement to remain within a federated network of instances.

You can't force every instance to not federate with instances that do not respect this policy though.

Even if it's not automatic, it should be possible for users to flag "misbehaviour" by an instance so that it can be removed, like a bad node in a Tor network that threatens to undermine the security of the whole endeavour.

I think the Tor analogy is flawed, as this isn't really a security thing. Can't users do this already, by pointing out federated instances that don't respect their instance's policy to admins?

Instance administrators could re-code any functionality - if the network is to be trusted and safe there has to be some mechanism to discourage that.

I feel that this mechanism is already there with 'bad' instances being blocked by all the major ones. I don't really think that the Ostatus federation has to be some super trusty network, it's better that instances are allowed to break things and be messy - they just get blocked.

If you mean things like an instance being created that archives every toot it receives, I can understand why that would be a problem, but you can't really stop those sorts of things from existing - anyone can use the screenshot key and save your stuff forever.

Contributor

expenses commented Apr 22, 2017

@velw

This is a priority. Users mustn't be expected to put their data into a system if they have no way to remove that data. This has been a basic concept in data protection legislation for a very long time.

Agreed.

Respecting requests to delete user data on request should be a requirement to remain within a federated network of instances.

You can't force every instance to not federate with instances that do not respect this policy though.

Even if it's not automatic, it should be possible for users to flag "misbehaviour" by an instance so that it can be removed, like a bad node in a Tor network that threatens to undermine the security of the whole endeavour.

I think the Tor analogy is flawed, as this isn't really a security thing. Can't users do this already, by pointing out federated instances that don't respect their instance's policy to admins?

Instance administrators could re-code any functionality - if the network is to be trusted and safe there has to be some mechanism to discourage that.

I feel that this mechanism is already there with 'bad' instances being blocked by all the major ones. I don't really think that the Ostatus federation has to be some super trusty network, it's better that instances are allowed to break things and be messy - they just get blocked.

If you mean things like an instance being created that archives every toot it receives, I can understand why that would be a problem, but you can't really stop those sorts of things from existing - anyone can use the screenshot key and save your stuff forever.

@velw

This comment has been minimized.

Show comment
Hide comment
@velw

velw Apr 22, 2017

You can't force every instance to not federate with instances that do not respect this policy though.

Correct. There should be a flagging mechanism for instances that do wish to respect the policy.

I think the Tor analogy is flawed, as this isn't really a security thing.

When users can't control their data, it's a security thing.

Can't users do this already, by pointing out federated instances that don't respect their instance's policy to admins?

Can they?

I feel that this mechanism is already there with 'bad' instances being blocked by all the major ones.

Is it? Where can I look to see that?

I don't really think that the Ostatus federation has to be some super trusty network,

Fair enough. But don't expect widespread adoption.

it's better that instances are allowed to break things and be messy - they just get blocked.

That's... exactly what I suggested.

velw commented Apr 22, 2017

You can't force every instance to not federate with instances that do not respect this policy though.

Correct. There should be a flagging mechanism for instances that do wish to respect the policy.

I think the Tor analogy is flawed, as this isn't really a security thing.

When users can't control their data, it's a security thing.

Can't users do this already, by pointing out federated instances that don't respect their instance's policy to admins?

Can they?

I feel that this mechanism is already there with 'bad' instances being blocked by all the major ones.

Is it? Where can I look to see that?

I don't really think that the Ostatus federation has to be some super trusty network,

Fair enough. But don't expect widespread adoption.

it's better that instances are allowed to break things and be messy - they just get blocked.

That's... exactly what I suggested.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 23, 2017

Maybe I missed it, but GNU social is able to delete accounts. This must really be a priority.

ghost commented Apr 23, 2017

Maybe I missed it, but GNU social is able to delete accounts. This must really be a priority.

@wolfteeth

This comment has been minimized.

Show comment
Hide comment
@wolfteeth

wolfteeth Apr 24, 2017

With the addition of private toot federation, some form of remote delete request is essential.

wolfteeth commented Apr 24, 2017

With the addition of private toot federation, some form of remote delete request is essential.

@thesk8ingtoad

This comment has been minimized.

Show comment
Hide comment
@thesk8ingtoad

thesk8ingtoad Apr 28, 2017

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
User.find_by!(email: 'name@example.com')
Account.destroy(account_id) [use the number returned for Account id above]
User.destroy(user_id) [use the number returned for User id above (may not match account id)]

thesk8ingtoad commented Apr 28, 2017

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
User.find_by!(email: 'name@example.com')
Account.destroy(account_id) [use the number returned for Account id above]
User.destroy(user_id) [use the number returned for User id above (may not match account id)]

@saggel

This comment has been minimized.

Show comment
Hide comment
@saggel

saggel Apr 30, 2017

@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:
User.find_by!(email: 'deleted@useremail.com')

and they are not found on the system - so maybe that's a bug?

saggel commented Apr 30, 2017

@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:
User.find_by!(email: 'deleted@useremail.com')

and they are not found on the system - so maybe that's a bug?

@thesk8ingtoad

This comment has been minimized.

Show comment
Hide comment
@thesk8ingtoad

thesk8ingtoad May 2, 2017

@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 commented May 2, 2017

@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?

@saggel

This comment has been minimized.

Show comment
Hide comment
@saggel

saggel May 2, 2017

@thesk8ingtoad what happens if you search for the deleted users?
I get them as a result of the search, although when I use:

User.find_by!(email: 'deleted@useremail.com')

they are not there!

saggel commented May 2, 2017

@thesk8ingtoad what happens if you search for the deleted users?
I get them as a result of the search, although when I use:

User.find_by!(email: 'deleted@useremail.com')

they are not there!

@nightpool

This comment has been minimized.

Show comment
Hide comment
@nightpool

nightpool May 2, 2017

Collaborator

@saggel did you also make sure to run the Account.destroy code? It looks like it was improperly specified above, so probably not.

Try

account = Account.find_local!(username)
account.destroy

To do both (if you haven't already deleted users)

account = Account.find_local!(username)
account.user.destroy
account.destroy

(note—I haven't tried this. test it on a dummy instance first)

Collaborator

nightpool commented May 2, 2017

@saggel did you also make sure to run the Account.destroy code? It looks like it was improperly specified above, so probably not.

Try

account = Account.find_local!(username)
account.destroy

To do both (if you haven't already deleted users)

account = Account.find_local!(username)
account.user.destroy
account.destroy

(note—I haven't tried this. test it on a dummy instance first)

@saggel

This comment has been minimized.

Show comment
Hide comment
@saggel

saggel May 2, 2017

@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!!!

saggel commented May 2, 2017

@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!!!

@Paradoxumical

This comment has been minimized.

Show comment
Hide comment
@Paradoxumical

Paradoxumical May 4, 2017

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?

Paradoxumical commented May 4, 2017

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?

@MattiJarvinen-BA

This comment has been minimized.

Show comment
Hide comment
@MattiJarvinen-BA

MattiJarvinen-BA May 5, 2017

@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

A data subject should have the right to have personal data concerning him or her rectified and a ‘right to be forgotten’ where the retention of such data infringes this Regulation or Union or Member State law to which the controller is subject. In particular, a data subject should have the right to have his or her personal data erased and no longer processed where the personal data are no longer necessary in relation to the purposes for which they are collected or otherwise processed, where a data subject has withdrawn his or her consent or objects to the processing of personal data concerning him or her, or where the processing of his or her personal data does not otherwise comply with this Regulation. That right is relevant in particular where the data subject has given his or her consent as a child and is not fully aware of the risks involved by the processing, and later wants to remove such personal data, especially on the internet. The data subject should be able to exercise that right notwithstanding the fact that he or she is no longer a child. However, the further retention of the personal data should be lawful where it is necessary, for exercising the right of freedom of expression and information, for compliance with a legal obligation, for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller, on the grounds of public interest in the area of public health, for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes, or for the establishment, exercise or defence of legal claims.

(66) To strengthen the right to be forgotten in the online environment, the right to erasure should also be extended in such a way that a controller who has made the personal data public should be obliged to inform the controllers which are processing such personal data to erase any links to, or copies or replications of those personal data. In doing so, that controller should take reasonable steps, taking into account available technology and the means available to the controller, including technical measures, to inform the controllers which are processing the personal data of the data subject's request.

(67) Methods by which to restrict the processing of personal data could include, inter alia, temporarily moving the selected data to another processing system, making the selected personal data unavailable to users, or temporarily removing published data from a website. In automated filing systems, the restriction of processing should in principle be ensured by technical means in such a manner that the personal data are not subject to further processing operations and cannot be changed. The fact that the processing of personal data is restricted should be clearly indicated in the system.

MattiJarvinen-BA commented May 5, 2017

@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

A data subject should have the right to have personal data concerning him or her rectified and a ‘right to be forgotten’ where the retention of such data infringes this Regulation or Union or Member State law to which the controller is subject. In particular, a data subject should have the right to have his or her personal data erased and no longer processed where the personal data are no longer necessary in relation to the purposes for which they are collected or otherwise processed, where a data subject has withdrawn his or her consent or objects to the processing of personal data concerning him or her, or where the processing of his or her personal data does not otherwise comply with this Regulation. That right is relevant in particular where the data subject has given his or her consent as a child and is not fully aware of the risks involved by the processing, and later wants to remove such personal data, especially on the internet. The data subject should be able to exercise that right notwithstanding the fact that he or she is no longer a child. However, the further retention of the personal data should be lawful where it is necessary, for exercising the right of freedom of expression and information, for compliance with a legal obligation, for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller, on the grounds of public interest in the area of public health, for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes, or for the establishment, exercise or defence of legal claims.

(66) To strengthen the right to be forgotten in the online environment, the right to erasure should also be extended in such a way that a controller who has made the personal data public should be obliged to inform the controllers which are processing such personal data to erase any links to, or copies or replications of those personal data. In doing so, that controller should take reasonable steps, taking into account available technology and the means available to the controller, including technical measures, to inform the controllers which are processing the personal data of the data subject's request.

(67) Methods by which to restrict the processing of personal data could include, inter alia, temporarily moving the selected data to another processing system, making the selected personal data unavailable to users, or temporarily removing published data from a website. In automated filing systems, the restriction of processing should in principle be ensured by technical means in such a manner that the personal data are not subject to further processing operations and cannot be changed. The fact that the processing of personal data is restricted should be clearly indicated in the system.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost commented May 21, 2017

@jmfcodes

This comment has been minimized.

Show comment
Hide comment
@jmfcodes

jmfcodes Jun 1, 2017

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.

jmfcodes commented Jun 1, 2017

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.

@bortzmeyer

This comment has been minimized.

Show comment
Hide comment
@bortzmeyer

bortzmeyer Jun 2, 2017

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

bortzmeyer commented Jun 2, 2017

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

@bortzmeyer

This comment has been minimized.

Show comment
Hide comment
@bortzmeyer

bortzmeyer Jun 2, 2017

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

bortzmeyer commented Jun 2, 2017

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

@mal0ki

This comment has been minimized.

Show comment
Hide comment
@mal0ki

mal0ki commented Jun 4, 2017

@Gargron Gargron referenced this issue Jun 13, 2017

Merged

Account deletion #3728

4 of 4 tasks complete

@Gargron Gargron closed this in #3728 Jun 14, 2017

@Cassolotl

This comment has been minimized.

Show comment
Hide comment
@Cassolotl

Cassolotl Jun 14, 2017

Amazing! :) Thank you! <3

Cassolotl commented Jun 14, 2017

Amazing! :) Thank you! <3

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jun 15, 2017

Thank You for Clarifying we really need that function!!! I will now recommend to all my friends!

ghost commented Jun 15, 2017

Thank You for Clarifying we really need that function!!! I will now recommend to all my friends!

alpaca-tc pushed a commit to pixiv/mastodon that referenced this issue Jun 15, 2017

yipdw pushed a commit to yipdw/mastodon that referenced this issue Aug 1, 2017

Improved notifications cleaning UI with set operations (#109)
* 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

takayamaki pushed a commit to takayamaki/mastodon that referenced this issue Aug 31, 2017

takayamaki added a commit to takayamaki/mastodon that referenced this issue Nov 16, 2017

Merge pull request #109 from fvh-P/trendtag
add TrendTag function and API

tomoasleep added a commit to tomoasleep/mastodon that referenced this issue Jun 5, 2018

Merge pull request #109 from tomoasleep/fix/registration-form
Fix a bug that registration settings about qiita cannot be updated

Kirishima21 pushed a commit to Kirishima21/mastodon that referenced this issue Aug 20, 2018

Merge pull request #109 from YoheiZuho/master
Serialize text-less statuses as '.' over OStatus (fixes #7856) (#8126)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment