Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)TP
Posts
32
Comments
154
Joined
2 yr. 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".

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

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

    Please stop putting words in my mouth.

    OK, then, speak for yourself: do you see instances that federeate with Threads as being part of Meta's ecosystem?

  • Yes, 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.

  • 𝕯𝖎𝖕𝖘𝖍𝖎𝖙: 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.

  • Today, I've gone to a lot of trouble to have fediverse accounts today, and accounts on other enviroments that aren't as toxic and hostile as Facebook ... I still have a Facebook account. It's necessary to keep in touch with some family members. It's valuable for activism -- meet people where they are. It's the best place to find out about music events. There are some friends and former colleagues that it's the best way to keep in touch with. etc etc I wish those things weren't the case, but they are. So I have an account but limit my engagement -- these days I rarely post except for activism, private messages, and occasionally resharing posts that people are trying to get the word out about. There's still a lot of value in keeping most of my activity off there.

    And I still have a Twitter account despite all its issues. A lot of reproductive justice and abolitionist organizers are still there. It's better than any other social network for getting first-hand views of Palestinians. A lot of Black Twitter is still there. There are some friends and former colleagues that it's the best way to keep in touch with. It's potentially still useful for activism purposes. etc etc. So I have an account but limit my engagement -- these days I rarely post except for retweeting, DMs, and stuff that I don't care if it's public. There's still a lot of value in keeping most of my activity off there.

    And some reproductive justice and abolitionist organizers have left Twitter and gone to Threads. Threads is likely to be useful for activism purposes. Over time there are likely to be friends and former colleagues that it's the best way to keep in touch with. I'm sure other etc etc's will evolve. So I have an account but limit my engagement. There's still a lot of value in keeping most of my activity off there.

    And Meta's fediverse is likely to be useful for activism, and there are likely to be people there that I don't have any way to keep in touch with. Also, it's a great audience for The Nexus Today. I already have accounts there so don't expect to give them up. So I have an account but limit my engagement.

    It's a classic double-bind. Being able to staying in an environment that some people find isn't safe enough to stay in is a form of privilege; but then again, feeling like I have to stay in an anti-LGBTQIA2S+ environment where I feel constrained as to what I can say publicly and my data's being exploited is a form of oppression -- and so is the expectation that I should have to give up on all these valuable things just because I want to spend most of my time in an pro-LGBTQIA2S+ enviroment. So, there aren't any perfect answers.

  • For new instances, the easiest thing is to start with the list of an instance that the kind of moderation you agree with. If I were starting up an instance in the Lemmy world, I might go with the current federation list of lemmy.blahaj.zone or beehaw.org (although others might make differnet choices), in the Mastodon world I might use awoo.space as a starting point.

    There's certainly a need for tools to make this more scalable. "Recommended lists" are a likely next step; there isn't much software support for this yet, but it's similar enough to blocklists that they're also fairly straightforward; it would be up to the new instance admin to decide how many to inspect or whether just to trust the list. And tools are also needed to address the challenge in the other direction: how do existing instances decide whether or not to accept the request? Instance catalogs like fediseer can help. Another possibility that I mention and link to in the article is "letters of introduction"; federations of instances (which I'll talk about in the next installment) are another.

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

  • Great point, I should be more explicit in the article. On Lemmy, it would look like a couple of things:

    • today, another instance's request to federate is accepted unless it's explicitly blocked. This means that bad actors can get away with stuff until they're discovered and blocked (although it makes it easier for good actors to federate). Consent-based federation turns that around: a request to federate isn't accepted unless it's approved. One way an instance admin could decide whether or not to approve a request is to look at FediSeer to see what other instances are saying about the requestor.
    • at the individual level, it would mean that people would start out by participating in local communities (and maybe even just seeing posts from their instance, not sure about that), and could then choose to have their posts federated out
  • This is great, thanks so much for taking the time to do it! I've been thinking of moving my Ghost blog/newsletter to Wordpress to take advantage of the fediverse integration, and one of the things that was holding me back is that I couldn't find a post like that that also includes the plugins and recommended settings.

    I'll be importing my content (there are various utilities to turn the Ghost JSON export into an importable XML file). Any idea of that imported content will federate, or will it just be treated like old blog posts and not federate?

  • How about this as a revised first sentence to clarify the focus is on an alternative (not the whole fediverse)?

    As I discuss in the first post in the series, the "free fediverses" are regions of the fediverse that reject Meta and surveillance capitalism, and these strategies position the free fediverses as an alternative to Threads and "Meta's fediverses".