Mastodon: Make remote reports show the user who sent the reports

[Laurelai]

Right now it doesnt and since remote reporting has been implemented its at least on my instance been used for nothing but frivolous reports, using the anonymity as a means of harassing me. Knowing who is sending them will allow me to suspend those users from my instance without having to suspend their whole instance

---

• [x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[nightpool]

Deanonymizing the remote user would be a huge privacy concern. I think requiring the remote mods to "forward" the original report (instead of users being able to do it without oversight) would be a good compromise here. (this was how the feature was originally proposed)

[Laurelai]

Its not a major privacy concern since any user on a remote instance can, without their admins knowledge or approval send remote anonymous harassment to any instance admin/mod team. The reality is that this privacy is being abused to cause harm. The privacy concerns have to give way to the safety of others in this case.

I dont deserve anonymous harassment just so some hypothetical person can feel marginally safer. users on my instance have to send me reports locally with their usernames on them, if its not a privacy concern for them its not a concern for remote users.

Whoever decided that being able to send instance admins anonymous comments was a good idea didnt think this through.

[Hasimir]

Hang on, how come an instance admin can't set a policy of their own terms under which a report will be accepted?

What's wrong with an admin being able to set a policy to only accept identified reports from remote instances and if the reporter is notified of this before clicking submit then they can either choose to click the button or speak to their own instance's admin to forward it on their behalf?

[0xa]

Reports can't be sent only remotely, so if someone harasses you through reports their admins will have seen it. (or they're ignoring reports, and at this point you may as well want to block the whole instance)
Keeping that in mind, I think anonymizing remote reports is an extremely important feature that could protect naive users from potentially hostile instance admins.

I think it would be best to let mods/admins decide to forward an anonymized report or not, as they surely would be in the best position to decide whether or not it makes sense depending on their relations in the fediverse. (and if it's going to be sent as "from the instance", we may as well let them check it before it gets forwarded)

[Laurelai]

Instance admins should have the ability at least to disable receiving remote reports yes? Because as it stands right now someone can hypothetically make a bunch of accounts on many instances and flood someone with frivolous reports. Someone could even automate it with a bot. Someone eventually will.

[0xa]

Yes, I'd like to see that as an option along with silence/suspension of an instance, like the one to reject media but for reports. (and suspension should probably also block remote reports, i'm not sure of the current behavior since it was added later)

Having each instance's staff make a first validation of reports before forwarding would also greatly help by filtering out the spam at the source, so I'd much rather we do that _instead of_ exposing the original reporter's identity.

[Laurelai]

Or at the very least an option to click called "reject future reports from this user" and i wont have to see who they are.

[Cassolotl]

If admins are required to approve the anonymous forwarding of a report to another admin, that would cut out reportspam from instances with good or inattentive admins. It would also make it socially a little easier for the receiving admin to start a dialogue, like, "hey I see you approved a report to me, let's talk about that." (Is there an easy way to DM another admin from the report UI, like "reply to this admin by DM"?)

Are admins even aware at the moment when a report they receive from their own instance has been forwarded to another admin in their name? If a report says "this report was also anonymously sent to the admin of [instance]", it could help the admin in situations where they're not sure whether or not to ban. "Oh wow, they also sent this to some other poor admin? Okay, I'm suspending them."

"Reject future reports from this user [or instance]" seems like a great idea too.

I do think reports should stay anonymous, but I agree that it is very open to abuse.

[ThisIsMissEm]

Is there an easy way to DM another admin from the report UI, like "reply to this admin by DM"?

I think this would be a really good idea; Perhaps we can do federation of the Reports / Report Notes? That way the discussion happens inline, and actions that are taken on either instance are federated, so we can see "Target Instance silenced the user" on the source instance, for example.

[ThisIsMissEm]

I also agree with the idea of the admin/moderator approved forwarding of reports, rather than just automatically forwarding them.

[ThisIsMissEm]

Could we perhaps send an "identity" as a salted hash of the users handle? i.e., for a report created by me on switter, the report would be sent with:

class Account

# snip ...

  def user_identifier
    OpenSSL::HMAC.hexdigest(OpenSSL::Digest.new('sha256'), Rails.application.secret_key_base, local_username_and_domain)
  end

# snip ...

end

That way the remote instance can prevent accepting new reports from a given user on a remote instance, without actually knowing who the user is on the remote instance.

We may want to use code like this for getting the secret_key_base value: https://github.com/plataformatec/devise/blob/master/lib/devise/secret_key_finder.rb

[fsnk]

I remember @nightpool's comments in the discussion about federating anonymous abuse reports; they totally predicted how the system would be abused.

As I see it, the main problem with the current anonymized reports system on the recipient end is that it leaves me as an admin with no middle ground tools between just suffering abuse report spam or suspending an entire instance because I can't suspend the remote user account. It's like I have to choose either letting you punch me repeatedly or else drop a bomb on your city. The latter will stop the former, but it's probably disproportionate and there's a whole lot of unnecessary collateral damage.

Part of the problem is it seems like some admins may be loathe to make judgment calls on whether their users are abusing the anonymous nature of the report system to harass other users or other instances. There may also be times when an admin is unavailable to deal with the issue. Many instances are small, and run as hobbies, and humans have lives. They have families, and vacations, they get sick, or they have pressing deadlines at work -- and a lot of abuse reports spam can be generated in a short period of time. (I expect we'll see bots doing this shortly, now that it's been exposed as a viable attack vector.)

Obviously I think inter-admin communication and cooperation is the best option but the ability to just suspend remote reports on a per instance basis seems like a good compromise when remote admins are, for whatever reason, unwilling or unable to handle the attack from their end.

But just the ability to suspend reporting from a given instance doesn't fix the problem, because it also suspends the ability of the other users on those servers to report legitimate problems to you.

Because the decentralized nature of the fediverse means a handful of bad actors can create a few accounts on multiple - even many instances, and use them to send a low volume of spam reports from each instance which can fly under the radar of the local admin but become a flood on the receiving server. Add to that they can report multiple users on the remote instance, further camouflaging their reports on the local servers as legitimate. And if you can automate torrent spam, you can automate this kind of attack.

This means an admin could have to potentially contact hundreds of other admins individually with the specific details and then wait while those admins research on their end and decide how to deal with the accounts causing the problem. All while just dealing with an influx from dozens of servers, or else suspending them. Right now, with suspending federation being the only self-defense, this would be a really good way to force another server to self-isolate.

Of course another problem is currently the admin interface is inadequate for handling anything in batch, which means every single report has to be manually cleared. (This was evident in the recent spam account problems also.)

If the anonymous nature of the federated abuse report system becomes in itself an abuse enabling feature, maybe it's time to rethink it. An abuse report system that ends up ignored because it's full of unstoppable spam is worse than no abuse report system, because it creates the illusion that there's a working system in place.

It seems like there are a lot of issues, and I don't know what the solutions are, but there are some good ideas in this discussion.

[Laurelai]

I told people that report harassment was a thing and to do something about it. Now it happened because of a celebrity. People now know they can report harass admins. Please fix this.

[Gargron]

The solution still isn't "Make remote reports show the user who sent the reports"

Because if you unknowingly report someone to evilnazi.town without realizing, you'll become their target. In fact, in the situation you are referring to, people were blaming Wil for reporting them, but they had no way of knowing if it was Wil. It didn't stop them from assuming, but the situation couldn't have been better if they'd seen who it really was. The people who thought that those people were crossing a line would become targets also.

2.5.0 includes a quick fix for a start: Duplicate reports (i.e. if another unresolved report about the same user exists) no longer generate e-mail notifications, and all staff users get a preference to disable e-mail notifications for reports altogether (finally)

From this point forward (2.6 roadmap) we will add report source blacklisting (i.e. no more reports from a certain local user, or certain remote domain), improve reports overview UI to add more batch operations and display a per-account summary instead of having 40 reports about the same user scattered all over the page. Also, adding a moderation API

[nightpool]

I still think it's really important to make remote report federation subject to local admin approval

[fsnk]

I think @nightpool has a point. Maybe that could be a per server option also, instead of a binary on/off setup we could use whitelisting/greylisting/blacklisting of reports, depending on the source server.

Like: accept all reports from server example.com / accept admin forwarded reports from server example.com / reject all reports from example.com

[fsnk]

A note about the suggestion to add "DM" to reports: our abuse handling policy is that we do not use Mastodon for this kind of conversation _at all_. Besides the privacy concerns and the possibility of accidentally blasting the discussion publicly across the network if someone fat fingers the visibility setting, the messaging setup isn't suited to keeping important conversations together and in a prominent place where they're easily referenced and searched.