Fabio Manganiello<p>I’ve had some quite passionate (euphemism) discussions in the past couple of days with people who accused me of “throwing minorities under the bus” or “allowing Meta to scoop up everybody’s posts” just because I’ve temporarily decided not to defederate <a class="hashtag" href="https://manganiello.social/tag/threads" rel="nofollow noopener noreferrer" target="_blank">#Threads</a> from my personal Akkoma instance.</p><p>What’s interesting is that some of those accusations came from people who, in some cases, had their profiles fully public and searchable, on instances with webfinger enabled and without authenticated API constraints.</p><p>Their posts are already available on any search engine, searchable on Mastodon, their profiles can already be enumerated via API, and, even if their instance blocks another one, users on the blocked instance may still be able to see their content (especially if reshared/quoted) through unauthenticated API calls. But yeah, they think that the problem is with my tiny personal instance not defederating what they don’t like.</p><p>I’ve got the impression that there’s a lot of confusion on the <a class="hashtag" href="https://manganiello.social/tag/fediverse" rel="nofollow noopener noreferrer" target="_blank">#Fediverse</a> on how to customize the <a class="hashtag" href="https://manganiello.social/tag/visibility" rel="nofollow noopener noreferrer" target="_blank">#visibility</a> and <a class="hashtag" href="https://manganiello.social/tag/privacy" rel="nofollow noopener noreferrer" target="_blank">#privacy</a> of your content, and how to make sure that only those you wish will ever be able to see it.</p><p>In order to prevent pointless retaliatory blocks/defederations towards instances whose only fault is not to block what others want them to block, and in order to prevent the Fediverse from splintering into small islands along totally arbitrary fracture lines on the basis of unfounded beliefs about how it works, I’ve put together <a href="https://pics.manganiello.tech/texfx5.png" rel="nofollow noopener noreferrer" target="_blank">a sequence of steps</a> to check if your profile and your content are really private and sealed from unauthorized access (if that’s what you wish) - thanks to <span class="h-card"><a class="u-url mention" href="https://stroud.social/users/gruff" rel="nofollow noopener noreferrer" target="_blank">@<span>gruff</span></a></span> for the suggestion, and thanks to <span class="h-card"><a class="u-url mention" href="https://cosocial.ca/@evan" rel="nofollow noopener noreferrer" target="_blank">@<span>evan</span></a></span> for validating some of my assumptions.</p><p><span class="h-card"><a class="u-url mention" href="https://mastodon.social/@Gargron" rel="nofollow noopener noreferrer" target="_blank">@<span>Gargron</span></a></span> you’re welcome to validate my hypothesis about how <code>AUTHORIZED_FETCH</code> and <code>DISALLOW_UNAUTHENTICATED_API_ACCESS</code> work on Mastodon - I knew about <code>AUTHORIZED_FETCH</code> before, but I see that its functionality is now <a href="https://github.com/mastodon/mastodon/pull/19803" rel="nofollow noopener noreferrer" target="_blank">split on two environment variables</a>, and I’m not sure if both instance A and instance B need to have it enabled to prevent content leak towards blocked instances from reshares/quotes.</p><p>cc <span class="h-card"><a class="u-url mention" href="https://a.gup.pe/u/fediverse" rel="nofollow noopener noreferrer" target="_blank">@<span>fediverse</span></a></span> <span class="h-card"><a class="u-url mention" href="https://a.gup.pe/u/privacy" rel="nofollow noopener noreferrer" target="_blank">@<span>privacy</span></a></span></p>