To get feedback! I often send out drafts to newsletter subscribers and post them on Mastodon and in the [email protected] community … I got a lot of good feedback on this one which is incorporated in the revised version.

Thanks for the tipoff on having to turn off the VPN, it’s not at all intentional – and it’s not a good look for a site with privacy in its name! I’ll try to figure out what’s going on, it’s pretty vanilla Ghost / nginx hosted on a Digital Ocean droplet so not immediately obvious.

And yeah, it’ll be interesting to see how well the messaging you for approval works out in practice. As you could say it could look like phishing; and even if it’s fine when just one app is doing it, it’ll be annoying if there are hundreds. Also, there’s a Mastodon setting to silently ignore DMs (and I think other platforms have similar options as well). And for Bridgy Fed, it would be great to have a mechanism that works symmetrically between the fediverse and Bluesky … but Bluesky doesn’t have DMs. Tricky!

I should probably mention something about being a good ally in that section, that’s a good suggestion. That’s not the main message I’m trying to convey though, I really do mean it as a warning to cis guys to be careful. These firestorms are tiresome for everybody, ould we please just not? Also btw sometimes particularly unpleasant for whoever sets them off. But maybe there’s a better way to word it.

Thanks, glad you think they’re reasonable. I don’t see it as using ActivitiyPub implying consent; it’s more that ActivityPub doesn’t provide any mechanisms to enforce consent. So mechanisms like domain blocking, “authorized fetch”, and local-only posts are all built on top of ActivityPub. I agree that many people want something different than ActivityPub currently provides, it’ll be interesting to see how much the protocol evolves, how far people can go with the approach of building on top of the protocol, or whether there’s shift over time to a different protocol which has more to say about safety, security, privacy, and consent.

Thanks for the feedback – and thanks for reading them despite the bristling. I couldn’t come up with a better way to put them … I know they’ll cause some people to tune out, but oh well, what can you do.

I don’t think these solutions are inherently unscalable, it’s more that there hasn’t ever been a lot of effort put into figuring out how to make things scalable so we don’t have any great suggestions yet. I wrote about this some in The free fediverses should focus on consent (including consent-based federation), privacy, and safety (the article is focused on instances that don’t federate with Threads, but much of it including this section is true more generally):

There aren’t yet a lot of good tools to make consent-based federation convenient scalable, but that’s starting to change. Instance catalogs like The Bad Space and Fediseer, and emerging projects like the FIRES recommendation system. FSEP’s design for an"approve followers" tool, could also easily be adapted for approving federation requests. ActivityPub spec co-author Erin Shepherd’s suggestion of “letters of introduction”, or something along the lines of the IndieWeb Vouch protocol, could also work well at the federation level. Db0’s Can we improve the Fediverse Allow-List Model? and the the “fedifams” and caracoles I discuss in The free fediverses should support concentric federations of instances could help with scalability and making it easier for new instances to plug into a consent-based network.

(The post itself has links for most of these.)

Preemption is bonkers from a privacy perspective, and also flies in the face of the basic principle that the states are “the laboratories of democracy.” But from a corporate perspective preemption is wonderful … it keeps pesky pro-privacy states like California and Washington from ever raising the bar above whatever can get through Congress! So historically privacy advocates and organizations have always opposed preemptive federal legislation. But that wall cracked in 2022, where EPIC Privacy joined pro-industry privacy orgs like Future of Privacy Forum to support a preemptive bill (although EFF and ACLU continued to oppose the preemptive aspects).

The argument for supporting a preemptive bill (not that I agree with it, I’m just relaying it) is that the federal bill is stronger than state privacy bills (California unsurprisingly disagreed), and many states won’t pass any privacy bill. Industry hates preemption, industry hates the idea of a private right of action where people can sue companies, most Republicans and corporate Democrats will do what industry wants, so the only way to pass a bill is to include at most one of those. So the only way to get that level of privacy protection for everybody is for people in California, Maine, Illinois, etc, to give up some of their existing protection, and for people in Washington etc to give up the chance of passing stronger consumer privacy laws in the future. California of course didn’t like that (neither did other states but California has a lot of votes in Congress), and Cantwell’s staffers also told us in Washington that she was opposed to any preemptive bill, so things deadlocked in 2022.

With this bill, I’m not sure why Cantwell’s position has changed – we’re trying to set up a meeting with her, if we find out I’ll let you know. I’m also not sure whether the changes in this bill are enough to get California on board. So, we shall see.

Thanks! Here’s how it looks:

Great example of how there isn’t any one right answer here, it’s different for different instances. Can I quote this in the “What will instances do? Opinions differ!” section of https://privacy.thenexus.today/should-the-fediverse-welcome-surveillance-capitalism ?

Agreed that there isn’t one particular model that’s right or wrong for everybody, and that a split is likely – a region like today’s fedi and that welcomes Threads, and a more safety-focused region (with more blocking, a more consent-based federation).

And, it gives cops another excuse to overpolice Black and brown neighborhoods.

There have been other waves, it’s just that once they get shut down everybody loses interest and moves on. The PR for the one of the changes Mastodon just made was implemented in May 2023 after the Doge spam wave. And here’s a June 2019 post talking about exactly the same kind of attack: “The problem we are experiencing is the spammer signing up on random open instances and sending spam remotely.”

A very good idea! https://startrek.website/ took this approach, it’d be intersting to check in with them to see what they learned.

I had shared the draft version here a few weeks ago, and this incorporates some of the feedback – including “This goes against everything the Fediverse stands for” 😎

It’s true, but the time pressure is likely to be used to try to get a weak “compromise” bill through.

Yep. But, even though I didn’t suggest it, I didn’t explicitly say that it didn’t mean global blocklists. So I clarified it, and added a footnote with more detial.

As Instance-level federation decisions reflect norms, policies, interpretations, and (sometimes) strategy discusses, opinions differ on the definition of “bad actor.” So the best approach is probably going to present the admin of a new instance with a range of recommendations to choose between based on their preference. Software platforms should provide an initial vetted list (along with enough information for a new admin to do something sensible), and hosting companies and third-party recommenders should also be able provide alternatives.

Yes, at least on Lemmy. It’s the icon with two boxes.

Nonsense. Instance blocklists are used across the fediverse today. They’re certainly not a perfect solution but they have the advantage of actually existing. See Blocklists in the fediverse for a lot more discussion.

Indeed, the entire point is that instances should decide for themselves – I say it multiple times in the article and I say it in the excerpt. If they think that you federating with Meta puts them at risk, then they should defederate. And yes, it says more about the instances making the decisions than it does about Meta – Meta’s hosting hate groups and white supremacists whether or not people defederate or transitively defederate.

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!

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