I can't speak for others but yes, I want a fediverse that doesn't have white supremacists and fascists.
thenexusofprivacy
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.
They don't, at least not from your instance.