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 #Threads from my personal Akkoma instance.
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.
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.
I’ve got the impression that there’s a lot of confusion on the #Fediverse on how to customize the #visibility and #privacy of your content, and how to make sure that only those you wish will ever be able to see it.
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 sequence of steps to check if your profile and your content are really private and sealed from unauthorized access (if that’s what you wish) - thanks to @gruff for the suggestion, and thanks to @evan for validating some of my assumptions.
@Gargron you’re welcome to validate my hypothesis about how AUTHORIZED_FETCH and DISALLOW_UNAUTHENTICATED_API_ACCESS work on Mastodon - I knew about AUTHORIZED_FETCH before, but I see that its functionality is now split on two environment variables, 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.
Change `AUTHORIZED_FETCH` to not block unauthenticated REST API access by Gargron · Pull Request #19803 · mastodon/mastodon
New environment variable DISALLOW_UNAUTHENTICATED_API_ACCESS Fix #19623GitHub
This website uses cookies to recognize revisiting and logged in users. You accept the usage of these cookies by continue browsing this website.
informapirata ⁂ :privacypride:
in reply to Fabio Manganiello • • •ma soprattutto, hanno capito questi ultras che, se la tua istanza monoutente federa o non federa qualcuno, a loro questo non cambia praticamente nulla?
@fediverse @privacy
Fabio Manganiello
in reply to informapirata ⁂ :privacypride: • • •@informapirata ho avuto diverse discussioni in passato con gente che ha portato tanti scenari improbabili a difesa delle proprie tesi - del tipo io boosto un post di tizio A sull’istanza X, e la mia istanza non blocca tizio C che mi segue dall’istanza Z, quindi tizio C vede il post di A sulla sua timeline.
Le argomentazioni pero’ in genere cadono quando:
- Gli spieghi come funziona il meccanismo di authenticated fetch, e gli spieghi che se loro o il loro admin non l’hanno implementato sulla loro istanza la colpa non e’ mia
- Gli spieghi come funzionano i meccanismi di block e defederation, che dovrebbero in particolare prevenire il problema del boost transitivo sulla timeline di un utente direttamente o indirettamente bloccato
- Gli spieghi che nella maggior parte dei casi i loro post sono su istanze che sono indicizzate pure dai motori di ricerca, quindi il problema dei miei boost sulla mia istanza monoutente e’
... show more@informapirata ho avuto diverse discussioni in passato con gente che ha portato tanti scenari improbabili a difesa delle proprie tesi - del tipo io boosto un post di tizio A sull’istanza X, e la mia istanza non blocca tizio C che mi segue dall’istanza Z, quindi tizio C vede il post di A sulla sua timeline.
Le argomentazioni pero’ in genere cadono quando:
@fediverse @privacy