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---
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`.
Reply
---Replies---
silverpill@silverpill@mitra.social (2026-05-24 05:39:15)
@evan This is my mistake, thanks for pointing out. It should be changed to "...where embedded objects are owned by another local actor".
I think Create.object.attributedTo == Create.actor is a different thing, because it is related to authorization, whereas the requirement we're discussing here is related to authentication.
In general, yes, none of this was built into ActivityPub. But over the years implementers figured out authentication and authorization on their own, and now this is how federation works. People expect that same-origin embeddings can be cached as is, without re-fetching.
@general