Am collecting Mastodon server software feature requests - specifically for moderation enhancement that might be helpful as #Threads federates in.
Looking for those that can be doable inside a month or two timeframe, and that don't need #ActivtyPub spec to change first. (Which takes time)
See what you think of this list: and add any others you think fit to me in the comments.
https://docs.google.com/document/d/1bz0nl2SG-_CqJ7uqJvUskwXWXvXGFnpSJdafEiWWDD0/edit?usp=sharing
Recommendations for how Mastodon and other Fedivese solftware needs to evolve to deal with Threads
@tchambers, these are from the "Recommendations" section at the end of [Threat modeling Meta, the fediverse, and privacy (DRAFT)](https://privacy.thenexus.today/fediverse-threat-modeling-privacy-and-meta/#developers) -- the main text discusses the rationale (although, it's a draft).
* "Privacy by default": Set defaults so that people start with stronger privacy protections, and can then choose to give it up. For example, make "Authorized Fetch" the default setting, and ensure documention explains it well.
* Develop processes and tooling for blocking Meta instances and all instances that federate with them. For example, extend nodeinfo to have a field with an instance's policy towards Meta (transitively block, block but federate with instances that federate with Meta domains, federate with Meta domains). Investigate solutions for blocklists Meta and federating-with-Meta domains (taking into account that there are likely to be a huge number of them hosted on different domains), and for allow-lists for instances that don't share data with Meta
* Investigate shifting to allow-list federation, and look at alternative approaches like "approval first" federation.
* Reduce the number of public pages and the amount of data in them, including supporting private profiles, increasing use of non-public visibility like local-only posts, investigating new visibility levels like "viewable only to people logged into instances that don't federate with Meta", differentiating between what's shown at different levels of visibility, and (potentially) requiring login to view unlisted statuses
* Provide a usable way for instances and individual users to protect all profiles, timelines, statuses, images, etc from anonymous access.
* Provide control for individuals and sites to determine whether RSS feeds are available, and implement an option to remove unlisted statuses from RSS feeds
* Educate people on (and potentially package) existing processes and tools for IP Blocking, integrate with suspend/limit federation-level processes and infrastructure, and potentially develop new tools and look for ways to address downsides.
* Look at potential app-based dataflows and potential counter-measures, possibly including allow- and block-lists for apps as well
* Pursue funding from anti-surveillance-capitalism companies, civil society groups, governments, and crowdfunding to allow more detailed analysis, design, and rapid implementation of privacy and safety features – and ensure that the funding is directed in a way that increases equity and diversity.
* Press the project leaders to prioritize privacy and safety in their planning. If they don't, consider voting with your feet and creating a fork that prioritizes privacy and safety (as well as equity, usability, onboarding and all the other issues that need to be prioritized).
@thenexusofprivacy @fediverse @fediversenews @tchambers
Do I understand the second point correctly that the intention is isolate all instances federating with #threads from all instances not fecerating with #threads? Meaning, the goal is a hard split of the #fediverse?
Meaning, everybody (like me) who wants to be able to follow people from #threads will loose the ability of following people from "anti-#threads" instances?
@folkerschamel Yes you understand that idea correctly. Hundreds of instances have made it perfectly clear they don't want anything to do with Meta. With today's software, that's very likely to be needed to protect people who are at risk. Eugen's response in the blog post was disingenuous (or perhaps he just doesn't understand the issue).
Of course, software can evolve, but the extent of changes that are needed -- and the analysis that's needed to make sure they really do plug all the holes -- is unlikely to be completed in the timeframe Tim's talking about.
So yeah, it's very likely that you'll have to choose between following people on Threads or following people on instances who want nothing to do with Threads. Your desire to follow people there doesn't outweigh others' perspectives that they don't want to be exposed to something they consider risky and toxic.
I think your last paragraph has some important distinctions related to instance admins versus their own users if they defederate.
When this kind of thing comes up so many people focus on instance level blocking and moderation, that makes decisions for users, instead of ways of empowering users to shape their own experiences based on their own perspectives.
So when you talk about choosing between following which group of people, it just makes me think of how that might really translate to following the groups of users who have been allowed by their instances to participate more fully in the Fediverse system, forcing those users to choose as well, and it just sounds like a big old mess to me.
If we focus on empowering users instead then that does a lot to unwind those tricky social dynamics.
@volkris @thenexusofprivacy @folkerschamel While I’m in agreement with empowering users humans are complex and humans run the instances. There are admins completely against Meta, however hypocritical some stances may be. While a bad experience for the users, users are able to migrate to another instance and or self host. There’s not going to be much room for middle ground
Oh, my whole point is that empowering users IS the middle ground.
ActivityPub is sadly lacking in the ability of users to migrate between instances, even overlooking all of the issues involved in the positives for having instances in the first place, the communal aspect of it.
So, should the admin expose their users to Meta? Should they close it off? Meh, middle ground is letting each user choose what experience they want.
@thenexusofprivacy @folkerschamel
@volkris When you take the realities of today's software into account, though, that's not a middle ground -- people who want nothing to do with Meta are still exposed in some ways. Here's one example. Nobody's analyzed it all deeply, so there are almost certainly others. https://privacy.thenexus.today/just-blocking-threads-isnt-enough/
Agreed that ActivityPub allows the original instance to capture idenitity (which as @ricmac points out in https://thenewstack.io/threads-adopting-activitypub-makes-sense-but-wont-be-easy/ is why Meta loves it) but even so moving accounts could be a lot better than it is today so let's hope Meta's arrival spurs some improvements!
@thenexusofprivacy @volkris @ricmac @dame
This article is (again) based on a widespread misunderstanding how #activitypub works.
Private data #meta is famous for collecting is not shared via #activitypub. If you join #threads, then you give them a lot of private data. If your account is on #mastodon and you communicate with #threads users, then #meta doesn't get any data it can aleady fetch today.
That's the same mistake Eugen made in his blog post. For on thing, it's not just public data that's a potential privacy issues. Why just blocking Meta's Threads won't be enough to protect your privacy once they join the fediverse](
https://privacy.thenexus.today/just-blocking-threads-isnt-enough/) includes an example where followers-only posts, which are not public data, can reveal information to anti-trans hate groups (who are active on Threads).
And, there's no reason everything that's currently public needs to stay public. The fuller threat model talks about that, although it's kind of buried -- it's the section on [Attack surface reduction and privacy by default](https://privacy.thenexus.today/fediverse-threat-modeling-privacy-and-meta/#asr-and-pbd). There's certainly room for progress here and it'd be helpful no matter what Meta decides to do so hopefully a good outcome will be dev teams prioritizing these kinds of improvements. We shall see.
I think the problem is that people are comparing against a reality that doesn't exist and never has.
It's not like Threads joining is going to wreck some system that preserved privacy. There IS no system that preserves privacy right now. Meta can ALREADY vacuum up so much of this information if it wants to, as can anybody else, whether or not it decides to join and federate.
So it's not a choice between privacy versus allowing Threads on. There is no choice of privacy here. So that's a false dichotomy.
And that users today don't realize how unprivate the system is today is itself a problem that has nothing to do with Meta. That people believe this is the choice goes to show that they are uninformed about how there is no choice of privacy, goes to show how they believe the system is private when it really isn't.
@volkris I see it differently. Today's low bar of privacy and other aspects of safety can be improved, and many people want it to be. Focusing on the shift from Meta is a good opportunity both to raise the priority of those changes -- and to educate people about the privacy issues today.
@folkerschamel @ricmac @dame