#Fedify, an #ActivityPub server framework, has released version 0.7.0! Here are the key changes in this version:
• Access control for actors, collections, and more via authorized fetch (i.e., secure mode)
• Generalized object dispatcher
• Logging with #LogTape for easier debugging
Today I'm working on putting authorized fetch (aka secure mode) into #Fedify. The protocol implementation is complete, it's just a matter of polishing the API and docs. It appears that it will be finalized sometime tomorrow. Authorized fetch will be one of the major improvements in Fedify 0.7.0.
When an #ActivityPub server implements authorized fetch (aka secure mode), how does it associate the keyId in an HTTP request with the actual actor? I know major implementations (like Mastodon) use a fragment appended to the actor IRI as a keyId, but in theory a keyId could be any IRI that seems unrelated to the actor IRI, right? Should I maintain a table of actor–keyIds somewhere in the server?
Happy to report that Kolektiva has activated authorized fetch, which will help to protect our instance's posts from surveillance and "AI" ingestion by Meta. Thank you to @subMedia@admin@moderation for defending the zone!
We have recently been advocating the activation of a function which is present but usually off in Mastodon and other fedi services called Authorized Fetch. As we plead with the major development projects to take safety more seriously and make it a default, we have learned that Meta itself didn't think twice about it and has activated it in their own ActivityPub implementation against us.
We know this because of news that a fascist has devised a way to evade it and force federation with Threads. They promise to then turn their technique upon us and coerce unblockable federation with fascist and cryptospam instances: https://soapbox.pub/blog/threads-server-blocking/
While Authorized Fetch remains important to activate, it is clear that even it - which remember, provides better defense than that currently implemented on most of our home servers - is inadequate to the threats facing us as the Zuckerberg incursion progresses. If we're serious about protecting our communities and expressions from absorption into surveillance capitalism and the accelerating miseries of fascism, we need to talk about a stronger grade of defensive weaponry.
To this end, @are0h has fired a first volley: https://h-i.social/@are0h/111653850819592308 Every fedi community which serves as a refuge for those targeted and under siege should be thinking like this. True safety only awaits us in a transitive approach to defederation, and further on, in an intentional federation based on the allow-list.
I would love a list of servers who have activated authorized fetch, because ultimately not being associated with facebook, twitter etc is more important to me than making it easier for people with friends still using those services to see those posts. #AuthorizedFetch exists and if it means paying my instance every month to be part of something I can feel good about as opposed to feeling like I am complicit in the crimes commited by facebook and twitter, I would happily do that. #Fedipact#AskTheFediverse
Did you know that, if you or your Mastodon instance is blocking Meta, your posts and account can still be data-mined by them? That is, unless your instance has Authorized Fetch activated. More info here: https://kolektiva.social/@ophiocephalic/111602259275182233
With the Zuckerberg takeover impending, there's a lot of confusion circulating about the use of user-level and instance-level blocks, and how our online expressions can be secured against Meta. Everyone who objects to their accounts being mined by the Zuckerberg entity for data collection, AI ingestion, monetization, and possible ghost-profile building needs to understand this problem. Here's information to clarify.
Neither a user-level block, or an instance-level block, will protect our posts from Meta data-mining by default on a Mastodon instance. Posts won't be delivered directly, but can be ingested by other means; if, for example, users on Meta-federated instances boost them.
However, both user and instance blocks will totally prevent post delivery in all cases IF your host instance has enabled the functionality called Authorized Fetch.
By default, Authorized Fetch is off on Mastodon instances and most haven't turned it on. If this concern is important to you, you might want to respectfully reach out to your admins and let them know. Remember that they are working hard to provide and sustain online community at no charge. It's likely they won't be very familiar with it and will need time to look into it.
Go for example on @mosseri and click on the three dot button to see the "block domain threads.net" button.
At this time I don't consider necessary or even wanted to do a server wide block on ecoevo.social. More so that as a science server, some people here might want to interact with Threads in the future (if following a Masto account from Threads is ever implemented).
domanda nabba su activitypub perchè faccio prima a chiedere che provare a capirlo dai docs sparsi:
se io postassi un toot con privacy tale che determinato toot possa essere visto solo da @enverdemichelis , i server federati fetcherebbero lo stesso il toot per poi non mostrarlo o non possono proprio fetcharlo?
per capire se la fiducia si deve estendere a chiunque sia capace di sifonare tramite activitypub o solo i server delle persone con le quali avviene la conversazione privata (che sì ok appunto gli admin del server in cui sono io e il server in cui è un'altra persona possono sicuramente vederlo ma non è un problema)
@ex_06@enverdemichelis Cioè dici un toot "privato"? Quelli hanno un URL ma richiedono autenticazione, quindi le persone non citate non dovrebbero mai ricevere il contenuto nemmeno se scoprono l'URL. Le altre istanze federate invece non dovrebbero mai riceverne una copia dalla tua istanza, dato che non ne hanno bisogno. Per ridurre il numero di "copie non autorizzate" aiuta attivare #AuthorizedFetch. https://hub.sunny.garden/2023/06/28/what-does-authorized_fetch-actually-do/
Some more thoughts on the challenge of #Meta#Threads integrating ActivityPub support while living up to their normal obligations.
Enforcing actor and behavior-based content moderation will be hard.
All content moderation is either against the actor, behavior, or content (ABC model). With Federation, the metadata that big platforms use to tie accounts to a single actor or detect abusive behavior at scale aren't available (IPs, cookies, JS proof-of-life, TLS signatures, etc).