I'm trying to get my head round HTTP Signatures as they're used extensively in the Fediverse.
Conceptually, they're relatively straightforward.
You send me a normal HTTP request. For example, you want to POST something to https://example.com/data
You send me these headers:
POST /dataHost: example.comDate: Sat, 24 Feb 2024 14:43:48 GMTAccept-Encoding: gzipDigest: SHA-256=aaC57TDzM0Wq+50We2TkCsdMDvdqON92edg7KI+Hk8M=Content-Type: application/activity+jsonSignature: keyId="https://your_website.biz/publicKey",algorithm="rsa-sha256",headers="(request-target) host date digest content-type",signature="JGQ53kEoIiMWRp9By9jajVGCOCu4n7XBeiA1uY5xLcnAxL2Y1GIgU/...=="Connection: Keep-AliveContent-Length: 751
In order to verify the contents of the message, I need to do three things:
Check the SHA-256 hash of the message matches the content of the "Digest" header.
Check the timestamp is somewhat fresh.
Check the signature matches.
The first is simple: base64_encode( hash( "sha256", $request_body, true ) ).
The second is a matter of opinion. I might be happy to receive messages from the distant past or far in the future. For the sake of a little clock drift, let's allow 60 seconds either way.
The third gets complicated.
First, I need to get the public key published at keyId="https://your_website.biz/publicKey".
Next, I need to know which algorithm is being used to sign the headers: algorithm="rsa-sha256"
Then, I need to know which headers - and in what order - are being signed: headers="(request-target) host date digest content-type"
So I create a string using the received details which matches those headers in that specific order:
(request-target) POST /dataHost: example.comDate: Sat, 24 Feb 2024 14:43:48 GMTDigest: SHA-256=aaC57TDzM0Wq+50We2TkCsdMDvdqON92edg7KI+Hk8M=Content-Type: application/activity+json
I can verify if the signature - signature="JGQ53kEoIiMWRp9By9jajVGCOCu4n7XBeiA1uY5xLcnAxL2Y1GIgU/...==" matches by:
Which means your server will need to validate my signature by obtaining my public key. Which it will get by signing a request and sending it to me. Which, before I return my public key, I will need to validate your signature by obtaining your public key. Which I will get by signing a request... and so on.
This deadlock loop is documented. The usual way around it is either for the sending server to use an instance-specific signature which can be retrieved by an unsigned request, or to allow any unsigned request to access a user's public key.
I get why things happen this way - I just wish it were easier to implement!
Je rappelle aux admins des instances inscrites sur le relais que :
Mastodon : AUTHORIZED_FETCH doit être false pour que l'instance puisse envoyer les posts au relais ; ou via l'interface web : "administration" > "paramètres du serveur" > "découverte" > "exiger une authentification de la part des serveurs fédérés" doit être décoché (falseest la valeur par défaut, aucune intervention n'est requise si vous n'avez pas touché à ce paramètre), cf. la doc de Mastodon
Firefish/Iceshrimp/etc : dans les paramètres d'administration, sous "security" > "server security" > "secure mode (authorized fetch)" doit être décoché (option activée par défaut, donc une intervention est requise)
Actuellement à ma connaissance, il n'est pas possible de faire tourner un relais compatible avec Authorized Fetch (par définition)
Si Authorized Fetch est activé :
l'inscription initiale au relais est impossible
si l'option est réactivée après inscription au relais, celui-ci ne peut pas recevoir de posts de votre instance, mais il peut lui en transmettre : cela ne fonctionne que dans un sens
Alex Gleason, the former Truth Social developer behind Soapbox and Rebased, has come up with a sneaky workaround to how Authorized Fetch functions: if your domain is blocked for a fetch, just sign it with a different domain name instead.
Mastodon has been providing a half-measure to its users for years. Now it’s the time to make things right: going into 2024, I think it’s going to absolutely be a requirement to develop more robust forms of privacy options and access controls to empower users.
que derrota ver colar o discurso de usar a Meta como razão pra defender que as instâncias abram mão de liberdades do conhecimento que elas têm hoje (restringir o acesso à API hoje liberado)
Please note, this post will be a living document that will be updated over time as new information becomes available.
Over the past several weeks, IFTAS has fielded an increasing number of inquiries about the implications of Threads – the microblogging platform from Instagram, a Meta platform – enabling ActivityPub and testing their connectivity with the Fediverse.
Server admins and moderator teams are grappling with the decision and trying to understand the impact of allowing their service to interact with Threads, and thereby with Meta’s network and data infrastructure.
IFTAS has solicited a list of questions from the community which has been sent to the Threads team. If we get replies, we will post them here. We will continue to collect your questions for the foreseeable future.
IFTAS will remain steadfast in its mission to support the moderators of federated social media services. If a large number of threads.net accounts opt in to federating their content, this would increase both the source of content that may break your terms of service leading to an increase in local reports, as well as the number of accounts able to view your member’s content, leading to an increase in remote reports if your member’s content is deemed objectionable.
Before federating with Threads, you may want to review the Instagram Community Guidelines (Threads is an Instagram product) to review your member content’s applicability. Federating with Threads may expose you to compliance issues you have not previously been concerned with, as Threads is a US corporation with strict compliance requirements regarding subject matter commonly found on the Fediverse, including intellectual property concerns, sexually explicit content, and sex work. Threads users can report any content they find that meets their definition of spam, nudity or sexual activity, hate speech or symbols, violence or dangerous organizations, bullying or harassment, selling illegal or regulated goods, intellectual property violations, suicide or self-injury, eating disorders, scams or fraud, and false information.
According to the GLAAD Social Media Safety Index, Instagram, Thread’s parent, has a 63% SMSI score for safety. While Instagram scores the highest of all the rated platforms, you should note that Instagram will allow accounts on their service that many would choose to block. We are unaware of any shared lists of such accounts on Threads, but if we become aware of such a list we may link to it here. Online hate leads to offline violence which leads to yet more online hate, and all hate and harassment should be reported to the relevant platform, no matter the source.
If you wish to completely shield your members from interacting with Threads, be aware that defederating threads.net stops content coming in, but not necessarily going out. Followers of your members may boost or repost content to their followers, which in turn may be threads.net accounts. Mastodon offers an Authorized Fetch option – Configuring your environment – Mastodon documentation – which will completely remove the ability for Threads to gather content from your service. Other platforms may have similar options, and you should pose this question to the relevant developer team.
You should also be aware of the Threads Supplemental Privacy Policy. This document describes the data Instagram will collect from your users if they interact with Threads, and the intent to service privacy requests, notably:
What information do we collect?
[…]
Information From Third Party Services and Users: We collect information about the Third Party Services and Third Party Users who interact with Threads. If you interact with Threads through a Third Party Service (such as by following Threads users, interacting with Threads content, or by allowing Threads users to follow you or interact with your content), we collect information about your third-party account and profile (such as your username, profile picture, and the name and IP address of the Third Party Service on which you are registered), your content (such as when you allow Threads users to follow, like, reshare, or have mentions in your posts), and your interactions (such as when you follow, like, reshare, or have mentions in Threads posts).
(IFTAS note, this is the same information most ActivityPub servers will collect if a user interacts)
and:
How can you manage or delete your information and exercise your rights?
[…]
If you are a Third Party User, our ability to verify your request may be limited and we may be unable to process your request. Please note, however, that the interoperable protocol allows Third Party Services to automatically send Threads requests for deletion of individual posts when those posts are deleted on the Third Party Service. We make reasonable efforts to honor such requests when we receive them. Contact your Third Party Service to learn more.
Below are the initial set of questions submitted to the Threads team, as we learn more, we will update this page.
Questions
If a Fediverse user reports content from threads.net to their service provider and chooses to notify the source server, how does Threads receive it? Can Threads receive it?
If a Threads user reports content from a third party to Threads Trust and Safety, is that report forwarded to the third party moderation workflow?
How will Threads observe and effect user-to-user blocks that involve a third party?
If a third party service publicly defederates Threads in a fashion Threads can discern, will Threads reflect that defederation and not ingest posts or profiles from that service?
Will Threads take an “allowlist” approach, only federating with approved instances; or a “denylist” approach, federating with all instances by default unless they are explicitly blocked? Will any such lists – if they exist – be public?
How will Threads safeguard against federating with known bad actors in the existing ActivityPub space, thereby exposing Threads users to accounts and servers that are widely defederated by the community at large?
Will Threads require instances that federate with it to adhere to Threads-defined moderation standards? If yes, will Threads publish these standards?
As you may be aware, Facebook is starting to make noises about connecting to the fediverse. There's a lot of people who are looking at how they used to be part of the open web by providing RSS feeds for every user, but now only let you see their users by using their frontend, which is designed to maximize their profit at the expense of all other concerns, and saying that they do not want to let Facebook join the party.
I am one of these people, and I have taken steps to ensure this by turning on "authorized fetch". Now that this is on, any site asking for our posts via the ActivityPub protocol will be asked who they are, and if they are a blocked site, they will be told to fuck off. Facebook's Threads is one of these sites.
This may break compatibility with anyone following you on really old Mastodon servers (<3.0) or on other ActivityPub servers. But it will certainly break any attempts by Facebook to use our posts as something to keep people amused between ads.
(There are arguments to be had for not blocking Threads; however one of the rules of this server has always been that "corporations are likely to get blocked" and this is exactly the kind of corporation I was thinking about when I set down those rules back in 2017. Six years later, here we are.)
Is there a website that keeps track what instances are protecting their users from #Threads and which doesn't? Not everyone joined #FediPact, yet many still blocked them. It would be nice to know how much of the Fediverse is save from Meta.
This shouldn’t come as a huge surprise. Meta is moving forward with their plans for Theads and the Fediverse, and their adjusted terms reflect a new impending reality for Fediverse users.
Defederating actually does stop Meta from accessing data (at least through ActivityPub) if you enable AUTHORIZED_FETCH / similar. That setting requires remote instances to authenticate themselves, which prevents blocked instances from querying anything. IIRC, Lemmy either already supports or plans to support that same feature.
Meta could, of course, just use web scraping, but that can be prevented with DISALLOW_UNAUTHENTICATED_API_ACCESS. Although admittedly, I don’t think Lemmy has this feature yet.
@pfefferle could you clarify how does the AP plugin for WordPress handle (soft) bounces? When does it stop trying, how can it be reset etc? We're seeing some instances of federation stopping (unable even to fetch post manually) and would like to understand how this happens and hopefully avoid it happening in the future.
cc @gubi
I learned today that google indexes Mastodon posts (at least they do for the server im on)
I hate that, anything I can do about it..?
Willing to learn how to setup my own instance if it means my posts aren't indexed by fucking google #mastodon
Seems like you didn't really understand my point. Meta is very averse to, for example, any NSFW content, or using words that aren't G-rated to talk about other people. I do not think there will be a slow creep of Meta federating with server by server, because I do not think 99% of servers are willing to abide by those restrictions. If you want me to make up numbers, I think Meta will federate with 10 servers, at most, and that's it.
The other part of the equation, from what I understand, is authorized fetch. If servers implement that, that prevents Threads from accessing their content from a middle-man server if defederated.
So no, I don't want to federate with them. But I also think that writing off kbin because Ernest hasn't already defederated is a premature, knee-jerk reaction.
Many people are asking me, "How will #ActivityPub ultimately be #Meta's own undoing?"
Meta's current business model is not built for an open protocol like ActivityPub. It's very much dependent on them owning and controlling the network effect of services like Facebook and Instagram.
Not only does Meta want to collect all your personal data -- they want to control it too. They enforce this control through proprietary APIs. In this sense, they're not different from Twitter and Reddit.
The point of ActivityPub is that services, such as #Mastodon, #Kbin, and #Calckey, can depend on an open protocol instead of a proprietary API.
What if I, the admin of calckey.social, don't like what a dev is doing? Well, too bad. The protocol is open. I might be able to twiddle with my own server, but I can't do jack with anyone else's.
And what if I'm a greedy asshole who wants to monetize the user data on my server? Too bad for me, everyone on my server can migrate elsewhere.
This is not how Meta does business. In almost all ways, ActivityPub is counter to their business. Yet, here they are -- wanting to join the Fediverse.
The tech industry is awash in stories of big corporations that own proprietary tech that become undone by open standards.
Remember IBM's dominance of PCs? It was undone by the EISA standard.
Remember Novell's dominance of networking? It was undone by the bundling of TCP/IP in operating systems.
Remember AOL's dominance of online services? It was undone by the World Wide Web.
ActivityPub is yet another standard that pierces the opaque walled gardens that largely depend on proprietary technology owned by one company. And Meta happens to be one company that owns an opaque walled garden.
If history is to be repeated -- and usually it's worth learning from history -- then Meta opening the door to ActivityPub is company suicide. It's the first domino to fall before everything else in their catalogue of walled gardens also falls. Contrary to popular opinion, creating an ActivityPub enabled social network does not "kill" ActivityPub -- it validates it.
As it happens, I've known quite a few people who work at Meta. I have a little insight into what they're thinking.
Most folks at Meta know very well that Facebook will eventually die. But not just Facebook, Instagram too. Social networks, by their nature, are generational and transient. They have a shelf life.
Meta very much wants to build the app that kills Facebook and Instagram.
They have to build it because they can't acquire competition. That will raise the ire of regulators.
Likewise, Meta have already tried to leverage their own proprietary APIs to build compelling platforms. We've already seen this with the likes of Portal and Oculus.
What's apparent is that, even for a Big Social company like Meta, it is extremely hard to build a network effect from scratch. Sure, billions of people use Facebook and Instagram, but it was a whole lot of work for Meta to do that themselves.
And what was the end result of building Facebook and Instagram's network effect? More regulation by governments.
Thus, ActivityPub gives Meta two things it craves: the ability to piggyback on the network effect of an open protocol, and the ability to head off regulators by saying, "Hey, we don't own this protocol -- we're no different from Mastodon and Calckey."
Again, open protocols usually mean the demise of big corporations who leverage success through proprietary APIs. And ActivityPub will be no different.
Meta joining the Fediverse means that Automattic was right to build ActivityPub plugin for WordPress. It also means competitors, such as Apple and Microsoft, should probably start investing in ActivityPub.
What else does it mean? That small developers should start building apps that appeal to people who use Meta services. They should build these apps based on garden-variety ActivityPub -- because Meta can't own or control ActivityPub.
@atomicpoet@avividtale This is an interesting / frustrating (sometimes) feature of GoToSocial that I discovered was enabled by default: authorized fetch.
That is, an HTTP GET is a 403 unless the request is signed with the key of an actor and that actor is allowed to see the resource.
That basically breaks RSS feeds in general if enabled for those, since no reader supports it so far. But it's interesting for outbox and actor resources.
The reason I’m asking: I’m trying to follow some bird.makeup accounts from a Calckey instance. I can view their profiles just fine (the instance is not blocked) but trying to follow an account results in a “pending” state forever.
Here’s my best guess for what I think I need to do:
Add API endpoints to streetpass.social that returns profile photo, display name & handle for a given federated profile URL (or null if the link isn’t a federated profile)
Threads' federation is already using a deny list. And Authorised Fetch.
Soapbox lead developer, Alex Gleason discovered, that at least 5 Fediverse instances are blocked by Threads. These are:...
Threads' New Terms and Conditions Affects the Fediverse (wedistribute.org)
This shouldn’t come as a huge surprise. Meta is moving forward with their plans for Theads and the Fediverse, and their adjusted terms reflect a new impending reality for Fediverse users.
Is there any kbin instance that is seriously considering defederating Meta/Threads?
I've checked the fedipact signatories, but they all seem to be lemmy instances.