@happyborg well, if we talk from a strictly technical point of view, I don’t see the issue there.
I mean, if an admin of an instance cares that their garden is completely insulated from risks of scraping/forwarding of their user content, then they already have the tools for it:
Encourage user who care about their privacy to make their profiles private / followers-only.
Disable /.well-known/webfinger.
Enable AUTHORIZED_FETCH on their instance configuration (Pleroma’s APIs are authenticated by default, but Mastodon requires that environment variable to be explicitly enabled).
Encourage other federated instances to also enable AUTHORIZED_FETCH.
If all these four conditions are met, I don’t see how Threads, or an instance federated with Threads and also with theirs, could be exploited to extract information about their users.
Meeting all four conditions means that:
The posts of a user aren’t publicly accessible, and they can’t even be crawled by a search engine nor by an under-the-radar bot instance. If some admins complain that my instance not defederating from Threads threatens the safety/privacy of their users, they should probably first make sure that their profiles are actually private and their content isn’t already indexed on a search engine. Because that’d be like asking me to close a small door on the back when they’ve actually let the flood gates open.
AUTHORIZED_FETCH closes the loophole on the “indirect content fetch” side. Consider this case: instance B is federated with both A and C, but A has adopted a strict “no-C” policy, while B has implemented a “wait-and-see” policy. If user Y on instance B boosts/quotes a post from user X on instance A, and both instance A and B have AUTHORIZED_FETCH enabled, then a request from C to download the post from B with the quote from A will have to go through an authorization phase from both A and B. If either fails, then the user on C will either see an empty post or nothing, depending on the implementation.
That’s what I mean when I say that, technologically speaking, we already have the tools to ensure that those who want their content to be shared with a controversial instance, but don’t want to lose the existing connections to other instances on that basis, can already do so without any side doing compromises.
If we want to talk about the ideological side, and whether we want to build a community with a single consistent position on certain issues, or a set of independent islands with different values that can still communicate talk to each other, regardless of who else they also like to talk to, then it’s another thing.
p.s. I think that AUTHORIZED_FETCH helps but it’s not the ideal implementation. For the chain to work, all the instances in a “federated chain of trust” need to enable it, or the risk of exposing unwanted content (especially upon repost/quotes) is non negligible. And the fact that it’s not even enabled by default on Mastodon (the software used by 73% of the servers here), and that many admins don’t even know about it, or didn’t enable it, means that my little Akkoma instance (with authorized fetch) federating with Threads is the least of the problems. IMHO either that option should be enabled by default (even if that means breaking back-compatibility with instances that run Mastodon < 3), or complemented by another feature that doesn’t require strong authentication (like chains of referrals).
Fabio Manganiello
happyborg
Evan Prodromou
All GNU social JP content and data are available under the