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

Suspending an account should not delete it #6954

Open
ThibG opened this Issue Mar 29, 2018 · 23 comments

Comments

Projects
None yet
6 participants
@ThibG
Collaborator

ThibG commented Mar 29, 2018

Currently, suspending an account purges its contents completely, even though this is not clearly stated.

Account suspensions and content/following/followers purging should really be two very separate steps for reasons stated in https://octodon.social/@CobaltVelvet/99766921921908947

This feature requires displaying that an account is suspended, and a way to federate that information to other instances. To my knowledge, ActivityPub does not specify a way to do that.


  • I searched or browsed the repo’s other issues to ensure this is not a duplicate.
  • This bug happens on a tagged release and not on master (If you're a user, don't worry about this).
@wxcafe

This comment has been minimized.

Show comment
Hide comment
@wxcafe

wxcafe Mar 29, 2018

Contributor

👍

Contributor

wxcafe commented Mar 29, 2018

👍

@ThibG

This comment has been minimized.

Show comment
Hide comment
@ThibG

ThibG Mar 29, 2018

Collaborator

(Removed the “fit for beginners” tag as it clearly needs some work on the protocol side of things)

Collaborator

ThibG commented Mar 29, 2018

(Removed the “fit for beginners” tag as it clearly needs some work on the protocol side of things)

@wxcafe

This comment has been minimized.

Show comment
Hide comment
@wxcafe

wxcafe Mar 29, 2018

Contributor

hmm? I don't think so, it could be a simple fix in the admin panel?

EDIT: didn't see the end of your message. We could probably have the account appear deleted but not actually delete the data.

Contributor

wxcafe commented Mar 29, 2018

hmm? I don't think so, it could be a simple fix in the admin panel?

EDIT: didn't see the end of your message. We could probably have the account appear deleted but not actually delete the data.

@ThibG

This comment has been minimized.

Show comment
Hide comment
@ThibG

ThibG Mar 29, 2018

Collaborator

That would only work locally, you have to federate that information. The information currently being federated on suspension is the complete deletion of the account.

EDIT: (which causes the deletion of any information on that account from the remote servers, and is clearly not what we want to do here)

Collaborator

ThibG commented Mar 29, 2018

That would only work locally, you have to federate that information. The information currently being federated on suspension is the complete deletion of the account.

EDIT: (which causes the deletion of any information on that account from the remote servers, and is clearly not what we want to do here)

@wxcafe

This comment has been minimized.

Show comment
Hide comment
@wxcafe

wxcafe Mar 29, 2018

Contributor

ah. yes.

Contributor

wxcafe commented Mar 29, 2018

ah. yes.

@ThisIsMissEm

This comment has been minimized.

Show comment
Hide comment
@ThisIsMissEm

ThisIsMissEm Apr 1, 2018

Contributor

Yeah, we've gotten caught out on this with Switter, where we thought suspension just disabled a user, and were completely caught out when we found out it deleted everything straight away. I was thinking for account deletion we should publish out to the network that the account is deleted, but keep the information in the local instance database for some predefined time range, in case there was a malicious action taken by that user.

(We basically had this happen and then couldn't discuss afterwards what happened as all related content was completely gone)

Contributor

ThisIsMissEm commented Apr 1, 2018

Yeah, we've gotten caught out on this with Switter, where we thought suspension just disabled a user, and were completely caught out when we found out it deleted everything straight away. I was thinking for account deletion we should publish out to the network that the account is deleted, but keep the information in the local instance database for some predefined time range, in case there was a malicious action taken by that user.

(We basically had this happen and then couldn't discuss afterwards what happened as all related content was completely gone)

@stephenburgess8

This comment has been minimized.

Show comment
Hide comment
@stephenburgess8

stephenburgess8 Apr 8, 2018

Contributor

The information currently being federated on suspension is the complete deletion of the account.

I believe it makes sense for the toots of a suspended user to show up as deleted, even if they are only soft deleted on the server. The most crucial part of this request is to not destroy the user data upon suspension, but to disable it (soft delete). This will allow the user’s data to be restored if a suspension is reversed. It will also allow admins to look back on what happened to trigger the suspension. If a user’s account is restored after suspension, other instances will have to go back to get the old toots. This is inconvenient, true. However the more important value right now is simply no longer deleting the content.

Here are a couple relevant parts of the code, which hopefully linking to will help someone else fix this functionality a little eaiser. I believe this solution will be in the Ruby, but maybe a flag needs to be set on the call from the HAML. I am not a Ruby dev so I am not able to provide a code solution for this one. I will be curious to see what the solution will be for this one. Thanks.

https://github.com/tootsuite/mastodon/blob/master/app/services/suspend_account_service.rb#L17

https://github.com/tootsuite/mastodon/blob/master/app/views/admin/accounts/show.html.haml#L116

https://github.com/tootsuite/mastodon/blob/master/app/controllers/admin/reports_controller.rb#L47

Contributor

stephenburgess8 commented Apr 8, 2018

The information currently being federated on suspension is the complete deletion of the account.

I believe it makes sense for the toots of a suspended user to show up as deleted, even if they are only soft deleted on the server. The most crucial part of this request is to not destroy the user data upon suspension, but to disable it (soft delete). This will allow the user’s data to be restored if a suspension is reversed. It will also allow admins to look back on what happened to trigger the suspension. If a user’s account is restored after suspension, other instances will have to go back to get the old toots. This is inconvenient, true. However the more important value right now is simply no longer deleting the content.

Here are a couple relevant parts of the code, which hopefully linking to will help someone else fix this functionality a little eaiser. I believe this solution will be in the Ruby, but maybe a flag needs to be set on the call from the HAML. I am not a Ruby dev so I am not able to provide a code solution for this one. I will be curious to see what the solution will be for this one. Thanks.

https://github.com/tootsuite/mastodon/blob/master/app/services/suspend_account_service.rb#L17

https://github.com/tootsuite/mastodon/blob/master/app/views/admin/accounts/show.html.haml#L116

https://github.com/tootsuite/mastodon/blob/master/app/controllers/admin/reports_controller.rb#L47

@ThisIsMissEm

This comment has been minimized.

Show comment
Hide comment
@ThisIsMissEm

ThisIsMissEm Apr 8, 2018

Contributor

TLDR: I think "suspend" is not the correct language, and that alone causes majority of issues. Further more, we need to create a proper "suspension" mode split from "deleted", and implement "soft-deletes".

A quick fix for now would be to change the language, i.e., "delete" instead of "suspend", I feel like this change alone would prevent a lot of accidental deletes until we can create a proper "suspend".


The main question here is what is meant by the action, to me:

  • silence: akin to a shadowban, the user is still able to post content, but the visibility of their interactions is limited.
    • I think shadowbanned accounts should see the full public timelines, even if their interactions on those statuses would not show up in mentions or the public timeline
  • suspend: user cannot log in, and their content is not available for public consumption
    • this potentially is just for a given timeframe, which is useful for putting users in a "timeout" corner.
  • delete: user account and all their content is deleted, preferable with a soft-delete, where by content can be restored within a given timeframe.

That's what I think most people would understand these actions to mean, however, Mastodon combines suspend and deleted into one, which is what catches administrators out. Sure, it is noted in the "Adminstration Guide", however, the language in the administration panel is just not clear nor natural.

Typically I think people want to reach for "suspend" as in what I described, and rarely want to reach for "deleted", but in the case where they do reach for deleted, it should simply be a soft-delete with a time-frame for recovery.

For other content, such as statuses and lists, we should add soft deletion, where content is kept locally after a user deletes it. This would enable moderators and administrators to do retrospectives on potential abuse or social engineering attacks which lead to certain actions being taken. Sure, it'd increase storage overheads, but it's worth it in my opinion for the safety and moderation aspects.


In the future, I think we need the following for accounts, statuses, and lists:

  • soft delete: remove content from public visibility (including counters), purge from remote servers, retained locally for a given timeframe for admin retrospective
  • hard delete: current behaviour, this is the case for when you need to remove something in an entirely destructive manner (e.g., removing content that should've never been published)

Soft deletes would be the default for when a user deletes an account, status or list. When an admin deletes a status, I think it too should be done with a soft delete.

Techwise, it would be possible to use the discard gem to perform soft-deletes. We'd also need to deal with the counter caches, as the rails-native counter caches that we use at the moment don't work with soft deletes, an alternative would be to use Counter Culture.

Contributor

ThisIsMissEm commented Apr 8, 2018

TLDR: I think "suspend" is not the correct language, and that alone causes majority of issues. Further more, we need to create a proper "suspension" mode split from "deleted", and implement "soft-deletes".

A quick fix for now would be to change the language, i.e., "delete" instead of "suspend", I feel like this change alone would prevent a lot of accidental deletes until we can create a proper "suspend".


The main question here is what is meant by the action, to me:

  • silence: akin to a shadowban, the user is still able to post content, but the visibility of their interactions is limited.
    • I think shadowbanned accounts should see the full public timelines, even if their interactions on those statuses would not show up in mentions or the public timeline
  • suspend: user cannot log in, and their content is not available for public consumption
    • this potentially is just for a given timeframe, which is useful for putting users in a "timeout" corner.
  • delete: user account and all their content is deleted, preferable with a soft-delete, where by content can be restored within a given timeframe.

That's what I think most people would understand these actions to mean, however, Mastodon combines suspend and deleted into one, which is what catches administrators out. Sure, it is noted in the "Adminstration Guide", however, the language in the administration panel is just not clear nor natural.

Typically I think people want to reach for "suspend" as in what I described, and rarely want to reach for "deleted", but in the case where they do reach for deleted, it should simply be a soft-delete with a time-frame for recovery.

For other content, such as statuses and lists, we should add soft deletion, where content is kept locally after a user deletes it. This would enable moderators and administrators to do retrospectives on potential abuse or social engineering attacks which lead to certain actions being taken. Sure, it'd increase storage overheads, but it's worth it in my opinion for the safety and moderation aspects.


In the future, I think we need the following for accounts, statuses, and lists:

  • soft delete: remove content from public visibility (including counters), purge from remote servers, retained locally for a given timeframe for admin retrospective
  • hard delete: current behaviour, this is the case for when you need to remove something in an entirely destructive manner (e.g., removing content that should've never been published)

Soft deletes would be the default for when a user deletes an account, status or list. When an admin deletes a status, I think it too should be done with a soft delete.

Techwise, it would be possible to use the discard gem to perform soft-deletes. We'd also need to deal with the counter caches, as the rails-native counter caches that we use at the moment don't work with soft deletes, an alternative would be to use Counter Culture.

@ThibG

This comment has been minimized.

Show comment
Hide comment
@ThibG

ThibG Apr 8, 2018

Collaborator

@stephenburgess8 there are multiple issues with issuing a deletion to the federation:

  • The account's toots will be erased from remote instances, thus making it appear “empty” if it is brought back online. Public/unlisted toots will get fetched again if someone interacts with them, though.
  • Private toots/direct messages from that account are lost forever for remote instances, as there currently exist no mechanism to fetch them.
  • Following/followed lists are going to be cleared on remote instances, leading to “shadow followers” and broken following relations. I don't think that can be easily fixed.
Collaborator

ThibG commented Apr 8, 2018

@stephenburgess8 there are multiple issues with issuing a deletion to the federation:

  • The account's toots will be erased from remote instances, thus making it appear “empty” if it is brought back online. Public/unlisted toots will get fetched again if someone interacts with them, though.
  • Private toots/direct messages from that account are lost forever for remote instances, as there currently exist no mechanism to fetch them.
  • Following/followed lists are going to be cleared on remote instances, leading to “shadow followers” and broken following relations. I don't think that can be easily fixed.
@ThisIsMissEm

This comment has been minimized.

Show comment
Hide comment
@ThisIsMissEm

ThisIsMissEm Apr 8, 2018

Contributor

@ThibG couldn't we just republish those events as if they'd happened in current time?

Contributor

ThisIsMissEm commented Apr 8, 2018

@ThibG couldn't we just republish those events as if they'd happened in current time?

@ThibG

This comment has been minimized.

Show comment
Hide comment
@ThibG

ThibG Apr 8, 2018

Collaborator

@ThisIsMissEm I don't think so… for following/followed, you will have to deal with manually-accepted follow requests. For previous toots, it could be a lot, it's unreasonable to re-push them. In all cases, re-publishing things is going to result in a lot of noise (traffic, notifications).

Or maybe I didn't understand your suggestion.

Collaborator

ThibG commented Apr 8, 2018

@ThisIsMissEm I don't think so… for following/followed, you will have to deal with manually-accepted follow requests. For previous toots, it could be a lot, it's unreasonable to re-push them. In all cases, re-publishing things is going to result in a lot of noise (traffic, notifications).

Or maybe I didn't understand your suggestion.

@ThisIsMissEm

This comment has been minimized.

Show comment
Hide comment
@ThisIsMissEm

ThisIsMissEm Apr 8, 2018

Contributor

Hm, yeah. This really needs to be something supported at protocol level of ActivityPub then.

Contributor

ThisIsMissEm commented Apr 8, 2018

Hm, yeah. This really needs to be something supported at protocol level of ActivityPub then.

@ThibG

This comment has been minimized.

Show comment
Hide comment
@ThibG

ThibG Apr 8, 2018

Collaborator

Yeah, that's why w3c/activitystreams#466 has been opened. IIRC, it will be discussed on the next SocialCG meeting: https://www.w3.org/wiki/SocialCG/2018-04-11

Collaborator

ThibG commented Apr 8, 2018

Yeah, that's why w3c/activitystreams#466 has been opened. IIRC, it will be discussed on the next SocialCG meeting: https://www.w3.org/wiki/SocialCG/2018-04-11

@ThisIsMissEm

This comment has been minimized.

Show comment
Hide comment
@ThisIsMissEm

ThisIsMissEm Apr 24, 2018

Contributor

@ThibG Was there any follow up to this post the meeting on the 11th April?

Contributor

ThisIsMissEm commented Apr 24, 2018

@ThibG Was there any follow up to this post the meeting on the 11th April?

@nightpool

This comment has been minimized.

Show comment
Hide comment
@nightpool

nightpool Apr 24, 2018

Collaborator
Collaborator

nightpool commented Apr 24, 2018

@nightpool

This comment has been minimized.

Show comment
Hide comment
@nightpool

nightpool Apr 24, 2018

Collaborator

I'm tempted to mark this as a duplicate of #5760 because that's the real change we need here (with maybe a rake/sidekiq task to clean old stuff up if people want) and I don't think adding more complicated user-facing or protocol-facing behavior is the right way to go.

(EDIT: nevermind, I thought that was an issue, not a pull request. still I think that's the right implementation path)

Collaborator

nightpool commented Apr 24, 2018

I'm tempted to mark this as a duplicate of #5760 because that's the real change we need here (with maybe a rake/sidekiq task to clean old stuff up if people want) and I don't think adding more complicated user-facing or protocol-facing behavior is the right way to go.

(EDIT: nevermind, I thought that was an issue, not a pull request. still I think that's the right implementation path)

@ThisIsMissEm

This comment has been minimized.

Show comment
Hide comment
@ThisIsMissEm

ThisIsMissEm Apr 24, 2018

Contributor

Delete is still different from Suspend; I think there needs to be a way to say "hide all of this account from all federated instances", and then a way to revert that

Contributor

ThisIsMissEm commented Apr 24, 2018

Delete is still different from Suspend; I think there needs to be a way to say "hide all of this account from all federated instances", and then a way to revert that

@nightpool

This comment has been minimized.

Show comment
Hide comment
@nightpool

nightpool Apr 24, 2018

Collaborator

I'm not sure I understand. What does "hide" mean in this situation? Why not just Delete { Actor } and Undo { Delete { Actor } } if you need to undo the suspension?

Collaborator

nightpool commented Apr 24, 2018

I'm not sure I understand. What does "hide" mean in this situation? Why not just Delete { Actor } and Undo { Delete { Actor } } if you need to undo the suspension?

@ThibG

This comment has been minimized.

Show comment
Hide comment
@ThibG

ThibG Apr 24, 2018

Collaborator

Ah, it's a shame that this hasn't been discussed during this meeting :/

@nightpool broadcasting the deletion of a suspended account will still break a lot of things, should that account be unsuspended in the future, cf. #6954 (comment)

I still think displaying such accounts as suspended (e.g. like twitter does) and federating that information is reasonable and way better than the broken and misleading behavior we currently have.

Collaborator

ThibG commented Apr 24, 2018

Ah, it's a shame that this hasn't been discussed during this meeting :/

@nightpool broadcasting the deletion of a suspended account will still break a lot of things, should that account be unsuspended in the future, cf. #6954 (comment)

I still think displaying such accounts as suspended (e.g. like twitter does) and federating that information is reasonable and way better than the broken and misleading behavior we currently have.

@nightpool

This comment has been minimized.

Show comment
Hide comment
@nightpool

nightpool Apr 24, 2018

Collaborator

@ThibG

broadcasting the deletion of a suspended account will still break a lot of things, should that account be unsuspended in the future

This is an implementation detail. Whether remote servers choose to delete the account and refetch the content later (which there is a mechanism for, using HTTP signed requests, mastodon just doesn't use it) or soft-delete and keep the account around for some sort of "grace period" is not something I feel comfortable Mandating from a spec standpoint.

Collaborator

nightpool commented Apr 24, 2018

@ThibG

broadcasting the deletion of a suspended account will still break a lot of things, should that account be unsuspended in the future

This is an implementation detail. Whether remote servers choose to delete the account and refetch the content later (which there is a mechanism for, using HTTP signed requests, mastodon just doesn't use it) or soft-delete and keep the account around for some sort of "grace period" is not something I feel comfortable Mandating from a spec standpoint.

@ThibG

This comment has been minimized.

Show comment
Hide comment
@ThibG

ThibG Apr 24, 2018

Collaborator
Collaborator

ThibG commented Apr 24, 2018

@joyeusenoelle joyeusenoelle referenced this issue Apr 26, 2018

Open

Add new account state: Locked #7273

1 of 2 tasks complete
@rixx

This comment has been minimized.

Show comment
Hide comment
@rixx

rixx May 29, 2018

A temp fix would be to rename the "suspend user" and "perform full suspension" buttons to "delete user" and maybe show a warning on hover that this will also delete all statuses posted by that user. Could we please have this? Even as a somewhat experienced admin I was just trusting the language of the button and was not aware that suspension == deletion of account and all toots until a few months ago.

(Also, making the button red would help a lot.)

rixx commented May 29, 2018

A temp fix would be to rename the "suspend user" and "perform full suspension" buttons to "delete user" and maybe show a warning on hover that this will also delete all statuses posted by that user. Could we please have this? Even as a somewhat experienced admin I was just trusting the language of the button and was not aware that suspension == deletion of account and all toots until a few months ago.

(Also, making the button red would help a lot.)

@ThisIsMissEm

This comment has been minimized.

Show comment
Hide comment
@ThisIsMissEm

ThisIsMissEm May 30, 2018

Contributor
Contributor

ThisIsMissEm commented May 30, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment