Today almost no instances run ads (misskey is as far as I know the only platform that's got support for ads) and Threads is the only one that does tracking. I'm using "free fediverses" the way https://freefediverse.org/index.php/Main_Page does -- instances that reject federation with Meta.

You do realize that instances federating with Threads will share data with Threads, and that Meta's supplemental privacy policy specifically says that they'll use all activity that federates to meta for tracking and ad targeting, right?

So for example, if you're on an instance that federates with Threads, and somebody on Threads is following you, all of your posts -- including your followers-only posts -- will get tracked by Meta. Or if somebody who boosts your post and they've got followers on Threads, your post will be tracked by Meta. Or if you like, boost, or reply to a post that originated on Threads, it gets tracked my Meta. And these are just the most obvious cases. What about if somebody on an instance that's not Threads replies to a Threads post, and you reply to the reply? It depends on the how the various software implements replies -- ActivityPub allows different possibilities here. And there are plenty of other potential data flows to Meta as well.

Of course they're still just at the early stages of federation so it's hard to know just how it'll work out. Individually blocking Threads might well provide a lot of protection. But in general, instances which federate with Meta will almost certainly be tracked significantly more than instances that don't.

I can't speak for others but yes, I want a fediverse that doesn't have white supremacists and fascists.

Yes, I'd say Lemmy communities are cross-instance communities - people can join communities on a different instance than their account.

On Lemmy? Certainly not. But on other fediverse software, there are followers-only posts, direct messages, local-only posts ... none of it's encrypted, but still it's not public.

A very good idea! https://startrek.website/ took this approach, it'd be intersting to check in with them to see what they learned.

They don't, at least not from your instance.

Fediblockhole does something along those lines for on Mastodon ... not sure if there's an equivlaent in the Lemmy world.

There have been other waves, it's just that once they get shut down everybody loses interest and moves on. The PR for the one of the changes Mastodon just made was implemented in May 2023 after the Doge spam wave. And here's a June 2019 post talking about exactly the same kind of attack: "The problem we are experiencing is the spammer signing up on random open instances and sending spam remotely."

To get feedback! I often send out drafts to newsletter subscribers and post them on Mastodon and in the !thenexusofprivacy@lemmy.blahaj.zone community ... I got a lot of good feedback on this one which is incorporated in the revised version.

𝕯𝖎𝖕𝖘𝖍𝖎𝖙: If those instances choose to share data with Threads, you should not join those instances.

Also 𝕯𝖎𝖕𝖘𝖍𝖎𝖙: Federating with threads shares “data” in the form of content

I appreciate all the time and energy you're putting into the comments here, but what it comes down to is that you're not concerned about the difference between the federation scenario -- where this data is given to Threads under an agreement that explicitly consents to giving Meta the right to use the data for virtually whatever they want -- and the situation today -- where Meta and others can do the work to non-consensually scrape public data on sites that don't put up barriers.

We're not going to convince each other, and we've both got enough walls of text up that at this point neither of us are going to convince people reading the thread who aren't already convinced, so let's save ourselves the time and energy and leave it here.

Yes, you described what you see as the difference between data and "data" clearly. And I described what I see as the implications clearly. If anybody's still reading the thread, they can make their own conclusions.

It’s less of an agreement and more of a protocol.

Threads Supplemental Privacy Policy begs to differ that there's not an agreement here.

My point is that defederating from meta doesn’t stop meta from tracking you online.

I never claimed it did. It eliminates one path of consensually sharing data (or "data", in your terms) with Meta.

In terms of your list, my perspective is that a server that federates with Threads is part of Meta's ecosystem -- #1 in your list. You don't seem to see it that way, and that's what we're not going to convince each other about.

Not yet, as far as I know, although there are some groups of instances whose admins and mods have a shared chat room and cooperated on blocklists which has some of these aspects.

Very much agreed that part of the problem relates to scale -- and, great analogy! It's an interesting thought experiment: if each school had an Lemmy instance, how would they work together to host communities and make it easy for people (in all the schools) to find the communities they're interested in? If they each had a Mastodon instance, how would they share blocklists? And so on.

And great point about the different dynamics between large instances and smaller / more focused instances. There's always a question of which communities an instance sees itself as in service to -- and similarly there's always a question of which instances and communities the team developing the software is in service to.

Yes, at least on Lemmy. It's the icon with two boxes.

It's true, but the time pressure is likely to be used to try to get a weak "compromise" bill through.

I had shared the draft version here a few weeks ago, and this incorporates some of the feedback -- including "This goes against everything the Fediverse stands for" 😎

Agreed that there isn't one particular model that's right or wrong for everybody, and that a split is likely -- a region like today's fedi and that welcomes Threads, and a more safety-focused region (with more blocking, a more consent-based federation).

Great example of how there isn't any one right answer here, it's different for different instances. Can I quote this in the "What will instances do? Opinions differ!" section of https://privacy.thenexus.today/should-the-fediverse-welcome-surveillance-capitalism ?

Thanks! Here's how it looks:

Thanks, glad you think they're reasonable. I don't see it as using ActivitiyPub implying consent; it's more that ActivityPub doesn't provide any mechanisms to enforce consent. So mechanisms like domain blocking, "authorized fetch", and local-only posts are all built on top of ActivityPub. I agree that many people want something different than ActivityPub currently provides, it'll be interesting to see how much the protocol evolves, how far people can go with the approach of building on top of the protocol, or whether there's shift over time to a different protocol which has more to say about safety, security, privacy, and consent.

Thanks for the feedback -- and thanks for reading them despite the bristling. I couldn't come up with a better way to put them ... I know they'll cause some people to tune out, but oh well, what can you do.

I don't think these solutions are inherently unscalable, it's more that there hasn't ever been a lot of effort put into figuring out how to make things scalable so we don't have any great suggestions yet. I wrote about this some in The free fediverses should focus on consent (including consent-based federation), privacy, and safety (the article is focused on instances that don't federate with Threads, but much of it including this section is true more generally):

There aren't yet a lot of good tools to make consent-based federation convenient scalable, but that's starting to change. Instance catalogs like The Bad Space and Fediseer, and emerging projects like the FIRES recommendation system. FSEP's design for an"approve followers" tool, could also easily be adapted for approving federation requests. ActivityPub spec co-author Erin Shepherd's suggestion of "letters of introduction", or something along the lines of the IndieWeb Vouch protocol, could also work well at the federation level. Db0's Can we improve the Fediverse Allow-List Model? and the the "fedifams" and caracoles I discuss in The free fediverses should support concentric federations of instances could help with scalability and making it easier for new instances to plug into a consent-based network.

(The post itself has links for most of these.)

Thanks for the tipoff on having to turn off the VPN, it's not at all intentional -- and it's not a good look for a site with privacy in its name! I'll try to figure out what's going on, it's pretty vanilla Ghost / nginx hosted on a Digital Ocean droplet so not immediately obvious.

And yeah, it'll be interesting to see how well the messaging you for approval works out in practice. As you could say it could look like phishing; and even if it's fine when just one app is doing it, it'll be annoying if there are hundreds. Also, there's a Mastodon setting to silently ignore DMs (and I think other platforms have similar options as well). And for Bridgy Fed, it would be great to have a mechanism that works symmetrically between the fediverse and Bluesky ... but Bluesky doesn't have DMs. Tricky!

I should probably mention something about being a good ally in that section, that's a good suggestion. That's not the main message I'm trying to convey though, I really do mean it as a warning to cis guys to be careful. These firestorms are tiresome for everybody, ould we please just not? Also btw sometimes particularly unpleasant for whoever sets them off. But maybe there's a better way to word it.

Right, I'm on Lemmy because I want to stay in my echo chamber. 🤣 🤣 🤣

This is great, thanks so much for taking the time to do it! I've been thinking of moving my Ghost blog/newsletter to Wordpress to take advantage of the fediverse integration, and one of the things that was holding me back is that I couldn't find a post like that that also includes the plugins and recommended settings.

I'll be importing my content (there are various utilities to turn the Ghost JSON export into an importable XML file). Any idea of that imported content will federate, or will it just be treated like old blog posts and not federate?

Great point, I should be more explicit in the article. On Lemmy, it would look like a couple of things:

• today, another instance's request to federate is accepted unless it's explicitly blocked. This means that bad actors can get away with stuff until they're discovered and blocked (although it makes it easier for good actors to federate). Consent-based federation turns that around: a request to federate isn't accepted unless it's approved. One way an instance admin could decide whether or not to approve a request is to look at FediSeer to see what other instances are saying about the requestor.

• at the individual level, it would mean that people would start out by participating in local communities (and maybe even just seeing posts from their instance, not sure about that), and could then choose to have their posts federated out

Here's the definition I gave for term in the first article i the series:

"Meta's fediverses", federating with Meta to allow communications, potentially using services from Meta such as automated moderation or ad targeting, and potentially harvesting data on Meta's behalf.

Thanks, I didn't know that -- I'll update the post!

Meta is a company whose business model depends on exploiting the data it gathers, and its privacy policies are carefully written to give it as much flexibility as possible. It's true that if you're on an instance that federates with Threads you're assuming that risk. If you compare their language to a policy that's written with a goal of privacy -- like eu.social's the differences are clear.

Please stop putting words in my mouth.

OK, then, speak for yourself: do you see instances that federeate with Threads as being part of Meta's ecosystem?

Yep. But, even though I didn't suggest it, I didn't explicitly say that it didn't mean global blocklists. So I clarified it, and added a footnote with more detial.

As Instance-level federation decisions reflect norms, policies, interpretations, and (sometimes) strategy discusses, opinions differ on the definition of "bad actor." So the best approach is probably going to present the admin of a new instance with a range of recommendations to choose between based on their preference. Software platforms should provide an initial vetted list (along with enough information for a new admin to do something sensible), and hosting companies and third-party recommenders should also be able provide alternatives.

Today, I've gone to a lot of trouble to have fediverse accounts today, and accounts on other enviroments that aren't as toxic and hostile as Facebook ... I still have a Facebook account. It's necessary to keep in touch with some family members. It's valuable for activism -- meet people where they are. It's the best place to find out about music events. There are some friends and former colleagues that it's the best way to keep in touch with. etc etc I wish those things weren't the case, but they are. So I have an account but limit my engagement -- these days I rarely post except for activism, private messages, and occasionally resharing posts that people are trying to get the word out about. There's still a lot of value in keeping most of my activity off there.

And I still have a Twitter account despite all its issues. A lot of reproductive justice and abolitionist organizers are still there. It's better than any other social network for getting first-hand views of Palestinians. A lot of Black Twitter is still there. There are some friends and former colleagues that it's the best way to keep in touch with. It's potentially still useful for activism purposes. etc etc. So I have an account but limit my engagement -- these days I rarely post except for retweeting, DMs, and stuff that I don't care if it's public. There's still a lot of value in keeping most of my activity off there.

And some reproductive justice and abolitionist organizers have left Twitter and gone to Threads. Threads is likely to be useful for activism purposes. Over time there are likely to be friends and former colleagues that it's the best way to keep in touch with. I'm sure other etc etc's will evolve. So I have an account but limit my engagement. There's still a lot of value in keeping most of my activity off there.

And Meta's fediverse is likely to be useful for activism, and there are likely to be people there that I don't have any way to keep in touch with. Also, it's a great audience for The Nexus Today. I already have accounts there so don't expect to give them up. So I have an account but limit my engagement.

It's a classic double-bind. Being able to staying in an environment that some people find isn't safe enough to stay in is a form of privilege; but then again, feeling like I have to stay in an anti-LGBTQIA2S+ environment where I feel constrained as to what I can say publicly and my data's being exploited is a form of oppression -- and so is the expectation that I should have to give up on all these valuable things just because I want to spend most of my time in an pro-LGBTQIA2S+ enviroment. So, there aren't any perfect answers.

Thanks for the detailed explanation. I agree that it depends on whether "Meta's ecosystem" is defined as including "ActivityPub federated instances which do not block ActivityPub data from going to Meta”. I do, and I originally said that "you don’t seem to see it that way." You objected that I was putting words into your mouth ... but after your last post I'm pretty sure that I accurately described your position: your definition of "Meta's ecosystem" only includes sites that help Meta do their tracking, and you had previously said don't consider federating data there as tracking.

Like I said, we're not going to convince each other. I understand your position and why you think that way, I just disagree. It's true that defederating from Threads while still federating with instances that use Meta's services doesn't help, it's true that federating with Threads just sends them the data that goes to other ActivityPub instances, it's true that Google's also a threat -- this is all part of why I frame things in terms of surveillance capitalism, not just whether or not to federate with Threads. We just come to different conclusions about the privacy impact of defederating from Threads. Restating our arguments another time won't change anything.

And in any case, that's not even the reason that most instances are defederating from Threads! Concern about harassment from hate groups there is a much bigger deal. So, as interesting as this conversation is, is it really a good use of our time?

I totally agree that there isn't a lot of privacy on the fediverse today -- in fact I even say that in the article and link off to recommendations for how to improve things. But also I think there's a huge difference between the situation on the fediverse where there's no privacy because developers haven't prioritize it and with Meta, where their model is focused on exploiting data that they've acquired without consent and they've repeatedly broken privacy laws (although to be fair they break other laws too, not just privacy).

And it's true, many people don't care about privacy, and many more care some but it's not important eough to them to make it their primary reason for choosing a social network. But a lot of people do care, at least to some extent, so the free fediverses will be a lot more appealing to them if they improve privacy. And even though I think privacy by itself won't the major driver for most people who choose the free fediverses, improving privacy also works well with that I think will be the major drivers -- like safety, pro-LGBTQIA2S+ focus, and (for people who want nothing to do with Meta) highlighting the core differences from Meta.

Circles' approach is certainly interesting, I remember looking at it when they did their kickstarter. Did it go forward? It looks like their blog hasn't been updated since 2021.

Fediverse software has followers-only posts, direct messages, local-only posts … Mobilizon and Streams even have private groups.

For new instances, the easiest thing is to start with the list of an instance that the kind of moderation you agree with. If I were starting up an instance in the Lemmy world, I might go with the current federation list of lemmy.blahaj.zone or beehaw.org (although others might make differnet choices), in the Mastodon world I might use awoo.space as a starting point.

There's certainly a need for tools to make this more scalable. "Recommended lists" are a likely next step; there isn't much software support for this yet, but it's similar enough to blocklists that they're also fairly straightforward; it would be up to the new instance admin to decide how many to inspect or whether just to trust the list. And tools are also needed to address the challenge in the other direction: how do existing instances decide whether or not to accept the request? Instance catalogs like fediseer can help. Another possibility that I mention and link to in the article is "letters of introduction"; federations of instances (which I'll talk about in the next installment) are another.

A website like that would be very helpful. A lot of people I talk to think that unlisted gives more protection than it actually does (they're used to how it behaves on YouTube where it's harder to discover), don't realize that it's still likely to get indexed by Googe et al even if they haven't opted in to search engines (because their post may well appear in a thread by somebody who has opted in), don't understand the limited protection of blocking if authorized fetch isn't enabled, don't realized that RSS leaves everything open etc.

Yes, I think in terms of protecting data generally, not just from Meta but also data brokers, Google, and other data harvesters -- as well as stalkers. Meta's a concrete and timely example so it's a chance to focus attention and improve privacy protections, both for instances that don't federate and for instances that do. I agree that most (although not all) of the information Meta can get from federating they already can by scraping and they certainly could scrape (and quite possibly are already scraping) most if not all profiles and public and unlisted posts on most instances, and so could everybody else ... it's a great opportunity to make progress on this. https://privacy.thenexus.today/fediverse-threat-modeling-privacy-and-meta/ has more about how I look at it.

Specifically in terms of data that flows to Threads through federating that isn't otherwise easily scrapable today, three specific examples I know of are

• followers-only posts for people who have followers on Threads, or who have approve followers turned off
• some unlisted posts from people who have opted out of discovery and search engine indexing that aren't visible today (i.e. haven't been interacted with via a boost or reply by somebody who has opted in). it's very hard to predict how many of these there are; it's not just posts that are boosted by somebody who has followers on threads, it also relates to how replies are retrieved
• identifying information in replies to followers-only posts by people who have followers on Threads. This can flow to Threads even if the original poster has blocked Threads (because blocking information doesn't get inherited by replies)

That said this isn't based on a full analysis so there may well be other paths. As far as I know the draft privacy threat model I did last summer is the deepest dive - And the software is buggy enough in general that it wouldn't surprise me if there are paths that shouldn't exist.

In terms of concerns about tracking others have about federating ... like I say for most people this isn't the top concern. To the extent it is about data going to Threads, for a lot of people it's about consent and/or risk management, full stop. They do not want to give Meta or accounts on Threads easy access to data from their fediverse account, even if Meta can get it without consent now (and even if they have some other Meta accounts). There's also a lot of "well Eugen said it's all fine", and especially from techies a lot of "well they can scrape it all anyhow, whatever" and "everything is public anyhow on social networks".

That's good to see -- seems like they've made a lot of progress. I'll check it out!

That's not how I see it. It's completely parallel to Facebook and Twitter: there's value for being on those platforms, it's not hypocritical to be there while at the same time criticizing them and pointing out the safety risks. And I've never said that being on Threads -- or being on an instance that federates with Threads -- isn't worth the compromise, I've consistently said that it's something that everybody has to decide for themselves. I have criticized instance admins who have deciding to federate with Threads without discussing with their users, without involving LGBTQIA2S+ people in the decision, or while inaccurately minimizing or ignoring the risks to LGBTQIA2S+ people on their instance for federating with Threads; in my view, they aren't acting in line with their stated values. And I've predicted that many LGBTQIA2S+ are likely to move as a result. But when instances like infosec.exchange have had discussions with their users -- or instances like hachyderm.io that have LGBTQIA2S+ representation in leadership -- have said they're federating, I haven't criticized them.

As for what is and isn't oppression, people outside a community often have different views than people inside a community. And, people who put a high value on privacy have different views of the tradeoffs that are required to participate in society today. I know people who have lost their entire social life because they won't be on Facebook, people who have lost job opportunities because they're not on LinkedIn, people who been physically harmed or had their mental health affected as a result of being on Facebook because they felt they had to be there for family reasons. So I'm sorry that you're offended that they (and I) see that as a form of systemic oppression but that doesn't change how I'd describe it.

It's not that I think that most people will (or should) reject a public internet. In fact I don't even think most people will reject surveillance capitalism-based social networks. As I say in the article "many people who make their home in the free fediverses (including me!) are likely to have other accounts for now – on Threads, or in Meta's fediverses – just as many do today on Facebook, Instagram, Xitter, TikTok, LinkedIn, and other surveillance capitalism social networks." As you say, small business owners and artists will want the broadest possibility for their work; and there are lots of other situations where that's what people want.

And I wouldn't frame the choice between (a) and (b) the way you do. With queer and trans people, I'd frame it as an opportunity to have an account on a smaller pro-queer social network that's gone to great lengths to insulate itself from hate groups like Libs of TikTok, and a choice of whether their other account is better on Threads or in Meta's fediverses. With progressive or leftist people, I'd frame it in terms of being on a social network that's not actively working with white supremacists, fascists, and authoritarians. With people who hate Facebook / Instagram / etc, I'd phrase it in terms of being as far away from Meta as possible. And so on ...

Some will say "two accounts? I think not! And there's a lot of stuff on Threads that's valuable for me, so I'm not interested." Oh well. But most people already have a bunches of accounts on various social networks -- none of which are particularly queer-friendly, all of which work with white supemacists, fascists, and authoritarians -- so (if signup is easy, the software's easy to use, if it's well-moderated and they don't have to deal with harassment, if there are enough interesting people there, etc etc etc) won't be averse to one more.

Also, why do you think most people want social networking to be an inherently public activity? Look at the most popular social network. Facebook gorups are extremely popular. Facebook supports friends-only posts and viritually everybody I know uses them at least part of the time. Facebook events allow posts that are only visible to people attending the event. The list goes on ... And it's not just Facebook. Reddit has private subreddits. Twitter has private profiles. Most fediverse microblogging software has local-only posts. Heck even Mastodon has followers-only posts. So, I'd say it's the other way around. Most people want social networking to be a mix of public and private activity.

No, as the article says at the very beginning, it's that I think a big reason that fediverse isn't growing is its failure to deal with safety.