cross-posted from: https://lemmy.blahaj.zone/post/7193618
The “free fediverses” are regions of the fediverse that reject Meta and surveillance capitalism. This post is part of a series looking at strategies to position the free fediverses as an alternative to Threads and “Meta’s fediverses”.
Are there any instances that aren’t free? Instances which run ads and tracking?
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 federating with meta doesn’t mean that the instances which allow federation with meta will be tracked more, right? Meta users are going to be tracked as much as meta users are going to be tracked. The old tricks that facebook used to do to track everyone with a facebook account everywhere on the net don’t really work any more in modern browsers and won’t ever work on an instance that doesn’t have a facebook “share this link” or “like button” integration.
Technically, if an instance did have those buttons and facebook users in older browsers used those instances, that would be tracked by meta, even if the instance itself didn’t federate 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 just wrote a comment explaining in detail how tracking works and why it wouldn’t work with lemmy. I suggest you read it or skim it first https://lemmy.world/comment/6404079
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?
If those instances choose to share data with Threads, you should not join those instances. Federating with threads shares “data” in the form of content, which is how the fediverse works. But this data is the content we are looking for - posts. The “data” you’re worried about being shared (tracking info, identifying info) won’t be shared. See the linked post for more details.
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.
I’ve got some bad news for you buddy: there’s defederating and there’s blocking. If meta or any other company wants to right now they can create a crawler for the entire fediverse, follow everyone and log everything. We have no evidence that people aren’t already doing this so I would assume that they are. Lemmy isn’t an isolated island, it’s a public internet-type software where content exists on the internet. Don’t want your content used by AI or linked to your pseudoanonymous lemmy account? Your only option is to join an instance that isn’t connected to the Internet (at least not publicly allowing access to accounts, something where all communities to community members only. Federation simply means that Threads users can’t interact with your instance and vice versa.
Please keep in mind that there are open source developers who understand that facebook is just another silly site (i.e., isn’t the internet, isn’t the gods of the internet). The only way this tracking nightmare you’re describing comes true is if Lemmy developers decide to make instances track users and ship that private tracking data to facebook.
As for “site A tracks users who interact with site A” yeah, that’s the internet for you.
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.
Federation isn’t complex. I explained this in the linked post. The one point I want to put across here is, if your instance decides to defederate from threads, your instance is still going to be tracked by meta and everyone else, and you probably won’t care because you haven’t in the past. It’s a different kind of tracking, not the 3rd party web-based tracking we’re used to when just visiting any site. There’s some exceptions to this which I’ve outlined in the linked post.
𝕯𝖎𝖕𝖘𝖍𝖎𝖙: 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.
But where will meta put its ads, and how can it filter what you see if you can’t (as a user of an instance blocking meta/threads/…) subscribe to meta instances?
I mean it’s just a hot mess, so I’m all for blocking those predatory psycopaths even if it theoretically isn’t needed in some cases.
Ask your same question about any other instance.
For example, what’s keeping me from setting up my own instance that just spams ads across every community? Answer: nothing.
What could owners of instances do to prevent seeing advertisements? Answer: defederate.
How much are users of instances that don’t defederate from my spam instance tracked? Answer: the same as any other site.
Tracking online works by communication with a client and server, ideally with identifying information. Everyone on the web has some identifying information, such as IP address and user agent. The problem is, IP addresses are shared with many people, the same as user agents. The only way to uniquely identify a user online is with cookies. Facebook used 3rd party cookies to track users who visted site A when site A has a image serve from facebook servers. Facebook gives the visitor a 3rd party cookie “You are now 93ga3490f” and logs that the cookie was served to visitor 93ga3490f on site A. That visitor then goes to site B and sees a facebook like image button, but this time when the user asks for the like button from facebook, the browser says “Hello, I am 93ga3490f requesting the facebook like button” and facebook records that 93ga3490f also visited Site B. Honestly this is still pretty useless until that user logs into their facebook account. At this point, the browser tells facebook, “Hello, I am 93ga3490f logging into facebook with email xyz@example.com” and facebook records xyz@example.com as visitor of Sites A and B (formerly user 93ga3490f.)
How does tracking work with federation? Answer: it doesn’t. Federation you can think of as a server subscribing to another server. You’re offline, and instanceXYZ downloads a copy of new content uploaded to instanceABC, since instanceABC and instanceXYZ are federated with one another. You go online, log onto your instance (instanceXYZ) and instanceXYZ serves you the downloaded content that it previously got from instanceABC. instanceABC doesn’t know you’ve viewed this, doesn’t know you’ve downloaded this. All instanceABC knows is that instanceXYZ copied this content for all of its users. The only way you can be tracked here is:
- instanceXYZ decides to track what it serves to you.
- OR instanceXYZ decides to include a facebook like / share button for each post AND you are using an outdated web browser to use lemmy AND you have a facebook account.
There are pay to join instances. Not many, but they exist.
There’s also at least one add supported Misskey instance
And of those pay to join instances, do we know they are tracking their users without their consent? That would be the only real issue here (tracking without consent)
Are there cross instances communities in Lemmy? How does that work?
Yes, I’d say Lemmy communities are cross-instance communities - people can join communities on a different instance than their account.
Lemmy communities work a bit weird when (de)federation gets involved.
By default, any community any server member is subscribed to gets mirrored to your home server. If your home server defederates/gets defederated, that local copy is still available. Local users can still post content, post comments, and have all kinds of interactions, the rest of the Fediverse just doesn’t know about it. It’s a bit like a “fork” in git/blockchain tech.
I don’t think you can subscribe to the local copy of a different server (although perhaps technically you could implement that relatively easily, I think?) but in a way any remote community you follow is “cross instance”.
Lemmy doesn’t implement supercommunities like Reddit does with subreddits (you can’t merge the “technology” communities of different servers under a single name), though that feature has been requested a bunch of times. That would be a solution where rather than following a bunch of different communities on different servers, you could merge a bunch of remote communities together under one single supercommunity that everybody can then follow, allowing for an intricate network of local communities that’s harder to break up (until, of course, said supercommunity starts removing subcommunities for whatever reason).
Meta’s fediverses probably also won’t be able to compete with Threads on this. Threads plan to make federation opt-in is the right thing to do from a privacy and safety perspective, but also means that people in Meta’s fediverses won’t be able to communiate with most of the people on Threads. And Meta has the option of adding communication between Threads and the billions of people on other networks like Instagram (which already shares the same infrastructure), Facebook, and WhatsApp. Longer-term, it seems to me that this is likely to be a huge challenge for Meta’s fediverses, but fediverse influencers supporting federating with Meta have various arguments why it doesn’t matter.
Is it really Meta’s fediverses, when communication between them and their alleged owner is fairly little and actively gatekept by their alleged owner?
no just like federating with mastodon.social doesn’t make your instance a part of the Gargron fediverse. Meta can’t control non-Meta instances that federate with them
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.
deleted by creator
How is Threads related to freedom? At best you can call these communities the “Threads-free” Fediverse.
I guess naming things become more complicated when you also include things like Foursquare and eventually Tumblr joining the Fediverse, but the Fediverse is as free in terms of moneys and freedom as it ever was. In fact, there’s a reason the"no big companies allowed" software licenses aren’t considered to be free software.
If I’m not free to join the Fediverse from the server of my choice, whether that’s mastodon.social or threads.net, is the Fediverse truly free?
If I’m not free to join the Fediverse from the server of my choice, whether that’s mastodon.social or threads.net, is the Fediverse truly free?
Joining the fediverse is just a matter of using a platform that implements ActivityPub (the protocol that lets servers communicate with each other. If Threads implements ActivityPub, it’s part of the fediverse, and the people on Threads can interact without any instance that chooses to federate.
However, instances don’t have to federate with Threads. That’s part of the freedom of the fediverse. If an instance admin decides that they don’t want to deal with an influx of hate, don’t want most of the content their uses see to be from Meta, or just don’t want to federate with a for-profit company that has an awful track record, they should be able to defederate. If a user of that instance really wants to see Threads content, they should be able to move to an instance that lets them, but defederation doesn’t make the fediverse or ActivityPub less free.
Of course, admins are free to federate, defederate, and ban as they like.
I just think tying definitions like “free” to specific instances is silly. There is no inherent freedom in blocking specific instances. Different terms like “non-commercial” or “tracking-free” would be much better descriptions of these corpo-defederating instances than “the free Fediverse”.
