Hey guys, I’m looking at improving the handling of edits (Updates) in the Discourse ActivityPub plugin and I’m curious to see what the ActivityPub brains trust here thinks of the approach I’ve used across these related PRs. There’s further details in the description of the PRs which I won’t repeat here, but happy to explain further if need be.
Can anyone see any issues with this approach of allowing an Updates from an actor other than to whom the object is attributedTo?
How do you establish that the Update.actor is authorized to modify the Update.object?
Yeah, that’s probably the primary concern I have. As I think you’ve pointed out elsewhere, the ActivityPub spec provides
The receiving server MUST take care to be sure that the
Updateis authorized to modify itsobject. At minimum, this may be done by ensuring that theUpdateand itsobjectare of same origin.
As you probably know, mastodon does a form of the minimum requirement by checking that the activity actor and the object uri are of the same origin.
So you’re essentially trusting the publishing server to perform that authorisation (which Discourse does in fact do).
But if you have a better, more secure, idea, that is feasible to implement here, I’m all ears.
Yes, it’s an extension of the authorization scope. HTTP Signatures can be taken to mean that one is scoped to the permissions of the actor, who signed it. This actor has permission to modify the stuff it owns, e.g. where attributedTo is said actor. If one wants to do updates beyond that, one would need a server signing key, with more permissions.
The above has to be taken with a grain of salt. I do not think that the exact meaning of permission scope with HTTP signatures has been formalized. I think @macgirvin has been vocal about his criticism of ActivityPub about not addressing the issue of granting people greater permission scopes. The issue he likes is: You should be allowed to remove a comment from a post.
I recently put together a brief summary of ActivityPub authorization best practices and techniques implemented in the wild. A handful of community members have reviewed it and agreed so far. More feedback is welcome! SocialCG/ActivityPub/Authentication Authorization - W3C Wiki
A handful of FEPs are also relevant here:
attributedTo as an ACL. Their example has it as a Collection, but an inline array could maybe work too. (I know here you want to allow Updates by anyone, not just an specific group.)@snarfed @helge Thanks for your thoughts.
What, in your respective views, is the single most practical way of supporting the scenario where an actor performs an Update on an Object attributedTo another actor? I’m sure there are many possible approaches. What approach is at the top of your list (and why is at the top of your list)? Or do you think this scenario should not be supported by ActivityPub?
Do I take it that this is your preferred approach @helge?
Activities that create or modify an object - Create, Update, Delete, Undo, Move, etc - must be the same actor as the original object’s attributedTo or activity’s actor. This is generally called the “same origin policy.”
@snarfed Could you explain why you think there needs to be a strict 1:1 relationship between activity actor and object attributedTo? How would a “wiki” feature work with such a rule?
If I’m reading this right, neither of these approaches would support having an Update actor different from an object’s attributedTo, the first being about “changing metadata and remov[ing] malicious content” and the second being about “adding objects to collections”. Is that right?
Great questions!
My goal with that wiki page was just to try to understand what people are doing now, in the wild, and to distill those down to the minimum recommendations to satisfy obvious user expectations. I only really considered the traditional social networking use case - individual users posting their own stuff - and only a couple of the most basic expectations - users can only post as themselves, and they can’t edit or delete other users’ posts.
I don’t know offhand how AP should allow more sophisticated authz use cases. I like that you’re thinking about them! @eprodrom and I were discussing the same thing this morning; it scared us both to even consider designing more advanced authz when AP doesn’t even have the basics nailed down yet. But I guess the standard answer here is, write a FEP and see what people think!
No! My preferred approach is:
There are a lot of issues here: Like how to model moderators or allowing somebody to remove a comment. I would claim: It’s a mess and requires a lot of work
However, this does not mean that I recommend to anybody to take my preferred approach. The server signing key is a practical recommendation based on “the server, Discourse, has a much better permission system than the Fediverse, thus let’s use it”. I would call
User < Moderators < Server
the hierachical permission model.
HTTP Message Signatures (but not draft-cavage-http-signatures, unfortunately) seems to allow multiple signatures to be included (Section 4.3 of RFC 9421).
Will we be able to use this mechanism to represent authorization from both the original and new attributedTo actors?