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.

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.

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! Here’s how it looks:

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 ?

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).

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.”

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

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” 😎

Indeed, the entire point is that instances should decide for themselves – I say it multiple times in the article and I say it in the excerpt. If they think that you federating with Meta puts them at risk, then they should defederate. And yes, it says more about the instances making the decisions than it does about Meta – Meta’s hosting hate groups and white supremacists whether or not people defederate or transitively defederate.

It’s good feedback, thanks – I thought I had enough of explanation in the article but maybe I should put in more. Blocking Threads keeps Threads userws from being able to directly interact with you, but it doesn’t prevent indirect interactions: people on servers following quoting or replying to Threads posts, causing toxicity on your feeds (often called “second-hand smoke”); hate groups on Threads encouragiingtheir followers in the fediverse to harass people; and for people who have stalkers or are being targeted by hate groups Threads, replies to your posts by people who have followers on Threads going there and revealing information.

And complement the FediBlock tag with FediBacon! It’s got success written all over it!

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.

Thanks, I didn’t know that – I’ll update the post!

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.

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”.

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?

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.

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.