Updates for October and November

Project statuses, applications, and volunteer updates.

For all those who'd been wondering about FSEP and where it's at, @nivenly have just published an update: FSEP is on hold, pending the return of the original maintainer, or until a new maintainer can be found:

https://nivenly.org/blog/2023/11/14/updates-for-october-and-november/#federation-safety-enhancement-project-fsep

#FSEP #moderation #TrustAndSafety

Updates for October and November

Project statuses, applications, and volunteer updates.

If FSEP were brought to me at work I would have had to sit down with the author across multiple revisions and break it apart into a series of smaller proposals to make it workable, and even then there are several parts of it that I don't think would make it into the mastodon mainline regardless.

But all of those elements require a lot more design and a lot more than what is contained in the somewhat short FSEP proposal.

I've already spent a lot of words on #FSEP, as have others.

4/

Given this behavior _any_ attempt to implementing a rapidly updating blocklist that you automatically import (be it run by #IFTAS or through #FSEP or something else) is _very likely to be abused_ and it is _going_ to cause problems even absent abuse cases.

People keep acting like this is up for debate?

We have literally decades of precedent here. It's going to happen.

My hardline: the _only_ ethical and responsible approach here is to _fix that first_ and tread carefully until then.

5/

There are several ways to handle apparent conflicts of interest.

For example:

* You can _disclose_ the conflict and acknowledge it. I maintained my criticism of the #FSEP proposal here in part because it didn't disclose the relationship between the author of the proposal and TBS.

* You can have another group or entity that has a lower stake in the question make the decision or be able to overrule the decision. This is how, e.g., nonprofits work

5/

Between #IFTAS and #FSEP and #Fediseer let's also look at another threat model that I think people don't fully appreciate with #blocklists

How much do you trust the blocklist source—not its upstreams, but the actual place you get it from—to do what they are telling you it does?

How much do you trust the maintainer to not perform a MitM attack?

How much do you trust others who have access?

If a MitM attack _were_ performed, how would you know about it? How would you catch it? How quickly?

1/

I want to find a solution to #moderation tools like #fediblockmeta inadvertently advertising content they oppose. I want to design a safety tool different in execution from #fsep and #fediseer.
I'm introducing an idea called #fediflags, where servers can moderate servers blindly, based off info supplied by the moderated server itself. Has a server ever asked another to BE suspended, or to have their media rejected? Well, with this they can, to ALL applicable servers.

@hrefna Honestly a lot of the same questions asked on #FSEP discussion NEED to be asked of this #IFTAS one too. Using a Mastodon App installed by admin bypasses the need to get it into Mastodon "core", so the technology angle is somewhat sorted, but as we've seen with any denylist project the important questions are about governance, audits, receipts, repeals process, etc. all things not covered in this presentation.

If you happen to find a comments area I'd be interested :)

I think there's some conflation between two separate purposes/use cases for #blocklists that we should probably talk about explicitly.

If the goal is something you are going to share with friends or with others in your social circle, or whatever then it's perfectly fine that your social circle doesn't like sex-positive things and that that's not important to you.

But if you then propose to make it the default blocklist for everyone (#FSEP), we need to have a conversation about that fact.

But what this means is that when we create tools to facilitate "better blocklist sharing" we need to acknowledge how that effort takes away from other potential solutions in this space.

Like as it is currently written, I'm pretty sure that the #FSEP proposal will not be mergeable into the #mastodon code base—they will balk at the increased centralization.

But there are a thousand small features could help, or could provide more value from the blocklists themselves, or lowering the costs.

5/