Part 3 of Strategies for the free fediverses

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

  • 𝕯𝖎𝖕𝖘𝖍𝖎𝖙English
    2•6 months ago

    I’d like to understand your definition of tracking, in that case. What is your biggest concern regarding tracking when federating? Am I correct in assuming that you also don’t want to be tracked by other data brokers? I have these conversations because I want to try to steer these conversations in a productive direction. I don’t need to convince you, but it would be interesting to understand the tracking concerns people have with federating. I’m also entertaining the idea of creating a website which shows people what data they share on the fediverse so they can understand where the real risks are (e.g., we probably should reject instances which choosed to use targeted advertising, as it sends data not only to facebook but to data brokers, etc…)

    There are good reasons for defederating from instances, such as harassment, hate, lax moderation policies, etc, as you mentioned. I’ve discussed that topic a lot too in other posts, mostly boiling down to “yeah it’s going to be really hard to say ‘yes’/‘no’ to what amounts to being one instance with millions of users”. Personally, I like the decentrialized nature of the internet, the fediverse and the freedom with which that brings. I don’t really have any interest in being on an instance which federates with meta properties, but I also don’t really take a strong stance for or against it. I personally see more conversation about defederating from threads and less concern with a route that some instance owners may be forced to head in: targeted advertising. After all, the tactics meta uses are the same tactics any web developer can use.

    The only positive I’ll say about federating with Threads is that some people have a lot of friends who are stick in facebook, and this would be a way for people to stay connected. I think that’s probably why they’re moving towards that direction, especially if they are seeing those users migrate away to ActivityPub. But someone else will need to make that empassioned argument - and I’m sure there’ll be a non-zero number of instances who choose to federate, and users will decide which ones they want to engage with at what time in their life. Choice!

    I’m certainly not going to make the argument that people should federate with any instance. You don’t like the instance, you server the connection. That ability was built in for a reason and should remain.

    • The Nexus of PrivacyOPEnglish
      2•6 months ago

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