Comment on The free fediverses should emphasize networked communities
thenexusofprivacy@lemmy.blahaj.zone 1 year agoYes, 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.
dipshit@lemmy.world 1 year ago
Threads is a company and it needs a legal document to describe how the social media site operates. A website needs to copy and distribute content in order to show content. Federated websites need to copy and distribute content from other federated servers and their own server in order to show content. This is how lemmy.world and blajah.zone can speak as if we are on the same server. Each fediverse should also include a similar privacy policy as it describes how their content is distributed on the internet. Facebook’s privacy policy likely describes how your content may be seen on other facebook products and in facebook apps. These legal documents spell out how systems operate. You assume a similar risk with each site you operate on.
(data, ‘data’,
data, “data”) are all the same term. Let’s use better terms:Facebook is evil for a lot of reasons but their original sin was the 3rd party tracking which, thanks to their assets (images) being put everywhere because site owners wanted better SEO and engagement with facebook users, facebook could send a cookie with a random id that specifes some user as it travels from site to site and then link that random id with the facebook user when that user logs into facebook. This allowed facebook to track its users everywhere on the internet. However, this didn’t allow facebook to identify non-facebook users like it could with facebook users. All facebook would end up with when tracking non-facebook users is information about what a random user viewed on the web - this isn’t great (and can only be stopped if you just block facebook at the router or browser level) but at least that user stayed anonymous. The motivation for this tracking was to push more targeted advertisements to facebook users, where facebook actual stands to earn a profit. There isn’t a lot of profit in just identifying users online if those users stay anonymous… except of course of internet advertising (programmatic advertisements). This is why it’s also important to interact with sites which do not have programmatic advertisements - these are most advertisements now a days, especially if that ad feels targeted specifically to you based on a site you’ve been to. You want to worry about tracking, look into how the programmatic ad industry works - of which facebook is a part but most importantly doesn’t involve federation because that’s something totally separate and something which actually protects against tracking.
Think of federation as a site downloading an image and reserving it to you. Tracking happens in the serving of an asset (image, video, etc), so if you are getting that content from the site you trust won’t track you, then … you won’t be tracked. A nasty site that wants to track you cannot get your information via the fediverse, since the federated site simply copies and privately redistributes the copy to its users, leaving the nasty site only knowing that “this instance with thousands of users received our content” - not very useful for tracking, advertising or for ad revenue, doesn’t provide any data that would be valueable for data sellers either.
Please stop putting words in my mouth. I am capable of speaking on my own terms. Also, by your perspective, a server that receives and processes email from meta is part of meta’s ecosystem. That statement would be correct if you replace “meta” with “the internet”.
Also, why are we discussing this with Meta when there’s a log bigger threat out there (ABC/Google, search engines and scrapers)? And by “threat” I mean “how the web has always operated”. I feel like writing an application that showed users how easily they could be tracked on the fediverse even if that instance were not federated by any other servers.
thenexusofprivacy@lemmy.blahaj.zone 1 year ago
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.
OK, then, speak for yourself: do you see instances that federeate with Threads as being part of Meta’s ecosystem?
dipshit@lemmy.world 1 year ago
That depends on what you mean by “Meta’s ecosystem”. If we consider Meta’s ecosystem to contain only the entities which directly help Meta earn money in exchange for tracking data, then the answer is no, for reasons I have explained.
If you consider “Meta’s ecosystem” to be “ActivityPub federated instances which do not block ActivityPub data from going to Meta” then the answer is yes, but that’s an arbitrary definition. How does meta profit from this? By showing more and different memes to its existing userbase? You could argue that by giving meta more content, the engaged users on meta’s properties will be more engaged and more likely to see an ad served by meta’s property to the user, leading to higher time on site. It’s a weak argument if your concern is being tracked by meta, as ActivityPub doesn’t share tracking information between servers.
I personally define “Meta’s ecosystem” to be meta’s properties and I suppose by extension any site which helps meta do its tracking: any site which shows facebook buttons served directly from facebook, therefor allowing tracking in older browsers. I consider ActivityPub to be a protocol not that far off from RSS or even Email, although RSS is a better comparison as it also happens over HTTP[S]. I define it this way because of my work as a web developer who has also built tracking systems similar to how Facebook’s tracking works, though not as sinister (I used 1st party cookies and pixels, similar to Google Analytics, prior to GA being free years ago). I’ve also worked for some websites that relied on ad views, and learned how programmatic works (tl;dr: each ad you see is an action for your eyeballs based on the data collected by hundreds of other agencies you may not even know of). I’ve also worked for startups where a large part of generating a high valuation for the company involved simply having contact information of hundreds of users as well as some basic information about their preferences. A startup like that would then have data to sell to a broker for programmatic ads.
Ultimately, websites (and instances) require money to stay up. Money comes from volunteers, donations or ad revenue / subscriptions. Programmatic ads can be included inside any website or app, and most importantly, an instance owner could choose to provide tracking data to facebook and other data brokers just to show advertisements, all while choosing to defederate from Meta’s fediverse properties either knowingly or unknowingly. It’s kind of like adding high-security locks on your doors and then leaving your windows open. If the end goal is to provide an instance which respects privacy of its users, that instance needs to choose to show ethical advertising (not programmatic, databroker-based ads which require sending the user’s data with each ad visit). Federating or defederating from meta’s properties won’t send any data to meta’s properties that every instance owner doesn’t already get as a part of ActivityPub federation.
thenexusofprivacy@lemmy.blahaj.zone 1 year ago
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?