Suspending an account should not delete it

[ClearlyClaire]

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]

👍

[ClearlyClaire]

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

[wxcafe]

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.

[ClearlyClaire]

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]

ah. yes.

[ThisIsMissEm]

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]

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]

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.

[ClearlyClaire]

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

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

[ClearlyClaire]

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

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

[ClearlyClaire]

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]

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

[nightpool]

It does not look like that issue got discussed at that meeting, because there was no one there to talk about it.

…

On Tue, Apr 24, 2018 at 10:03 AM Emelia Smith ***@***.***> wrote: @ThibG <https://github.com/ThibG> Was there any follow up to this post the meeting on the 11th April? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6954 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAORV_ZOSpA4lj4jQhy3nMU2tD62su-bks5trzCmgaJpZM4TAMx_> .

[nightpool]

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]

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]

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?

[ClearlyClaire]

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]

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

[ClearlyClaire]

Re-fetching the follow relations? You could do that I guess, but you'll run into a lot of corner cases with “locked” accounts. Also, good luck figuring out the difference between a legitimate follow and something a malicious server would want you to add. I don't think we are suggesting the introduction of a “grace period” into the protocol, but just an additional message that says “this account has been suspended”, indicating that interactions might fail, that statuses from this account should be hidden, and that this account might be unsuspended at a later date. Le 24 avril 2018 16:28:11 GMT+02:00, nightpool <notifications@github.com> a écrit :

…

@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 keep the account around for some sort of "grace period" is not something I feel comfortable Mandating from a spec standpoint. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #6954 (comment)

[rixx]

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]

I agree with this change, although, wouldn't like to call it a temporary fix. Any action that results in a loss of data should be clearly indicated.

…

On 29 May 2018, at 5:00 pm, Tobias Kunze ***@***.***> wrote: 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.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6954 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB4a47lF-L_AEPCP8ODN0a68FAplyBQks5t3WKggaJpZM4TAMx_>.

[deutrino]

Part of the problem is that the word "suspend" is the wrong word to describe a total scorched-earth wipe of everything related to the account. This issue could be left open for another year or two with plenty of 🤔 over protocol details, or the function could be named something other than "suspend" (which implies an action which is undoable), and that would be an improvement.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[deutrino]

This is still badly misworded.