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
Well I think I am just not so quick to embrace deficiencies in the software of the moment. I would like to see improvements in the software, hopefully improvements that wouldn't actually take all that long to implement.
Surely UIs can be updated in a matter of weeks, not years, to give users more power instead of relying on administrators making those choices for swaths of users.
I'm just not so ready to give up on users having control of their experiences, especially in this environment where so many people are complaining about other platforms that they have left because of administrators taking that power over users.
@volkris 💯 on improving the software -- the recommendations section of [Threat modeling Meta, the fediverse, and privacy](https://privacy.thenexus.today/fediverse-threat-modeling-privacy-and-meta/#recommendations) has an initial list of changes that would be valuable -- for instances that federate with #Threads _and_ for instances that don't. But a lot of them have been requested by #Mastodon users since 2017-2018, and some may require #ActivityPub spec evolution, so don't hold your breath on weeks rather than years
In terms of choice, the way I look at it, if and when Meta does in fact federate (still an open question), people will probably have four choices:
1) communicate with their friends on Meta (from their acount on an instance that federates with Meta)
2) have an account on an instance that federates with Meta, but block Meta as individuals.
3) have an account on an instance that blocks Meta but doesn't transitively block instances that federate with Meta.
4) have an account on an instance that transitively blocks Meta and instances that federate with it. This is the safer than the other options.
Different people will make different choices. People who want to use their fediverse account to communicate with or follow people on Insta will tend choose #1 unless they think there are significant downsides. People who actively don't want that can choose between 2, 3, or 4 .
People who want nothing to do with Meta are likely to choose the safer option of transitive defederation so a lot of people want to choose 4 as the safest option -- at least until there's a thorough analysis of privacy risks, and other risks too. And who knows how long that will take, and for that matter how likely is it that Meta will actually cooperate enough to allow a thorough analysis. Unless and until that happens, a lot of people will choose to be on instances that transitively defederate.
@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.
@thenexusofprivacy @volkris @ricmac @dame
Be careful, followers-only posts is also public data. It doesn't provide you real privacy. Already now in the #mastodon #fediverse. Never trust any system that followers-only posts are private data on #mastodon.
For real private conversation use something like #signal.
@thenexusofprivacy @volkris @ricmac @dame
I think is this a very important to communicate correctly the fundamental difference between joining #threads (you give #meta your private data) versus #federating, i.e. communicating with people on #threads from your #mastodon account (#meta doesn't get any data which isn't public already).
There's a lot of fear wandering around based on simply conflating these two things.
For example, the matisse sample in your article is the first, not the second.
@thenexusofprivacy @volkris @ricmac @folkerschamel There also needs to be a clear understanding of what data users have given Meta access to. I see people point to the Data nutrition labels but not add context. I can’t speak on Android but I know on iOS many items on that list require user permission
@dame yes, although I assume you have to grant all the permissions if you want to use the app.
I agree that the nutrition labels were being decontextualized: Insta and FB (and Twitter and every other commercial social network app) ask for much the same permissions -- and also if you're using a different app (or the web interface) to connect to an instance that federates with Meta, Threads' app policy doesn't apply. But then again without knowing what data Meta will collect via federation (because there aren't details yet), and knowing their business model is "collect as much data as possible" and they've frequently done it without consent, it's not unreasonable to assume they'll try to collect all data covered in the nutrition label even from people who aren't running the app.
@thenexusofprivacy @dame @volkris @ricmac
That's a technical misunderstanding, see my post above.
I really think it is important to not conflate these fundamentally different things.
@folkerschamel I agree it's important not to conflate the privacy risks of using the app with the privacy risks of federating. The article is only about the risks of federating, not the app.
@thenexusofprivacy @dame @volkris @ricmac
The article is conflating it. For example, the eye-catcher "matisse" intro has nothing to do with federating.
@folkerschamel It's interesting that's your reaction. By contrast I've heard from quite a few people who fully understand that Mistress Matisse is talking about something that happened on Facebook, and that federation will be with Threads, and still say "yeah that kind of stuff that Zuckerberg does is exactly why I want to be on an instance that blocks anything associated with Meta."
So thanks for the feedback, but opinions differ.
@thenexusofprivacy @dame @volkris @ricmac
That's not an opinion, but about what is factually correct or false.
It's a technical misunderstanding (or conspiracy theory) that #meta can "collect all data covered in the nutrition label even from people who aren't running the app".
@folkerschamel That's true, but nowhere in my article does it say that.
Thank you for the conversation, but at this point we're both repeating the same points. Security experts I've talked to think my presentation is accurate. You obviously see things differently, which is fine, but saying it again and again doesn't make it any more persuasive.
@thenexusofprivacy @dame @volkris @ricmac
You may revisit your trust in your understanding of what these security experts have told you.😉
The matisse thing is from your article, and the quote is from https://mastodon.social/@thenexusofprivacy@infosec.exchange/110719427022748574.
@volkris @ricmac @folkerschamel @thenexusofprivacy You do not need to approve all that appears on the data nutrition label to use the app. If found to be accessing any of that data without having been granted permission would violate Apple’s App Store policy.
@dame oh okay, thanks, good to know. If I had a burner iPhone I'd install it just to see what the actual permission flow is like.
At any rate I certainly agree that the discussion of the app is decontextualized -- it's not what I was talking about in the shorter article and I barely even mention apps in the longer threat model (baically just "apps are also a possible threat vector, analysis is needed").
@folkerschamel That's a misundersanding. Followers-only posts are *not* public data.
They're not encrypted, so they're not secret, but that's a different thing.
@thenexusofprivacy @volkris @ricmac @dame
Followers-only data are public in that sense that they are shared with other servers which the original server does not control and cannot trust. Assuming that such data us secure is a self-deception, in the same way as obfuscation is only fake security.
Whatever wording we use, it's a fundamental property of the #fediverse, whether #threads joins it or not.
Use #signal for private data.
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.
@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!
@dame @folkerschamel