Home | Notifications | New Note | Local | Federated | Search | Logout
Note Detail
silverpill@silverpill@mitra.social (2026-05-24 04:52:17)
FEP-fe34 (Origin-based security model) update : https://codeberg.org/fediverse/fep/pulls/849
I tried to better explain the assumptions on which the model is based, and clarified how exactly origins should enforce boundaries between actors:
Servers MUST ensure that activities published by a client do not represent unauthorized actions. This includes activities embedded within other activities and objects.
Servers MUST NOT allow clients to publish activities where embedded objects are owned by another actor.
Lemmy API and Mastodon API implementers don't have to worry about this, but one needs to be very careful when accepting arbitrary payloads from clients, for example, when implementing ActivityPub C2S API or FEP-ae97 API. Unfortunately, these security issues are completely ignored by people who push for wide deployment of ActivityPub C2S API.
Another addition is the recommendation to not use partially embedded objects, because that might lead to cache poisoning:
Embedded non-anonymous objects SHOULD NOT be partial representations. A server that relies on embedding for authentication might save a partial representation of an object to the cache, replacing the full object.
(see this issue for details: https://codeberg.org/silverpill/feps/issues/21)
#fep_fe34 #activitypub
Reply
---Replies---
silverpill@silverpill@mitra.social (2026-05-24 04:56:26)
@phnt Following on one of our conversations, I now call out authorized fetch as ineffective when it is used on public objects:
Some servers require an HTTP signature in an attempt to limit access to public objects. In this scenario, the request is expected to be signed with a key that is owned by a server actor. However, this measure is ineffective and can easily be circumvented by changing the keyId parameter of a signature.
Evan Prodromou@evan@cosocial.ca (2026-05-24 05:03:52)
@silverpill
I don't think this makes sense: "Servers MUST NOT allow clients to publish activities where embedded objects are owned by another actor."
We've never had this requirement; it's not built into ActivityPub; it's not how federation work.
- Like
- Announce
- inReplyTo
- Follow
- Accept
- Reject
I think two way verification is a better mechanism than same-origin. So, check that the `object` of a `Create` has the same `attributedTo` as the `actor`.