Skip to content
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

Drafting FediThreat policies #2

Open
shleeable opened this issue Feb 21, 2025 · 1 comment
Open

Drafting FediThreat policies #2

shleeable opened this issue Feb 21, 2025 · 1 comment

Comments

@shleeable
Copy link
Collaborator

shleeable commented Feb 21, 2025

This kind of service requires STRICT rules that must be follows with consensus for all instances using the service:

Reference: I am going to use https://connect.iftas.org/library/ vocabulary to not re-invent the wheel.

Bad Actors can be different kinds of risk:

https://connect.iftas.org/library-category/content/ has a nice list of different kinds of bad content.
https://connect.iftas.org/library-category/behaviours/ has a nice list of different kinds of bad behaviours.

Some of these types of bad content and bad behaviour can be captured on this service.. others are harder to capture.

My instance is dedicated to mostly people, but I generally delete accounts I consider SEO/SPAM

EXAMPLE:

Image

A user called "123bcomstore" with "[email protected]" signed up and spammed... their IP was also associated with spammers from lots of other usernames/emails.

Image

I should be able to easily mark this IP as a 'HIGH Spam risk'.... as a catch all instead of focusing on the single bad username/email (we can do both).

We need to ask where the line is.... The local record store down the street from me is not SEO spam to me... but any "business" activity might be SEO spam to others.

So the next question is escalation... If a business opens one pixelfed account on one instance.. that's not SEO spam... but if the same business opens one pixelfed account on 15 instances. That would be SEO SPAM.

NEXT

Risk scores should influence the response

90% of detection for low/medium risk reports should result in human involvement to manually approve accounts that are flagged incase of false alarm.

The HIGH risk reports could maybe shot first and ask questions later as required.

My goal for this project would be an "upvoting" system for admins/mods to collaborate and mark the reports as true/false to order to build trust in the reports

but also, allowing for instances to add additional information as notes.

Instance X can ask FediThreat about an IP.. and it can get back a report

IP 1.1.1.1 has 3 reports

  • IP suspended by pixelfed.au 2025 (Note: SEO spammer)
  • IP suspended by pixelfed.com 2024 (Note: SEO)
  • IP suspended by pixelfed.social 2023 (Note: SPAM)
  • STOPFORUMSPAM: This IP is connected to 59 other reports.
@shleeable
Copy link
Collaborator Author

Good actors are invisible to us.

If people have instances in weird places, but nobody reports them to the mods {they don't abuse the fediverse}, there will be no need for their IP to show up anywhere near the service.

This is a very squeaky wheel only kind of deal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant