silverpill
Here's en example:
{ "type": "Create", "actor": "https://social.example/alice" "object": { "type": "Note", "attributedTo": "https://social.example/alice", "attachment": { "type": "Note", "attributedTo": "https://social.example/bob" } } }It contains an embedded Note that is attributed to another actor. There are many possible ways to embed an object, and malicious embedding could be difficult to detect for the origin server.
silverpill
@grishka I am developing a client application where this is a real concern.
But I agree that in general, originating servers are responsible for verification of client data. This part of FEP-fe34 will likely be revised in the future.
Gregory
@silverpill @julian @technical-discussion ideally you would traverse everything and replace anything you don't understand with "id" references.
But anyway, I feel like we're getting too carried away about a very niche aspect of the whole thing. Almost like on that SocialHub forum.
In my own AP extensions I always just act like C2S doesn't exist because I've never seen it used in practice, and it's wildly impractical to use anyway.
silverpill
@mariusor Yes, a forged note. I've come up with a more realistic example:
{ "type": "Create", "id": "https://social.example/activity/345", "actor": "https://social.example/alice" "object": { "type": "Note", "id": "https://social.example/note/123", "attributedTo": "https://social.example/alice", "content": "This is just a note, nothing to see here", "replies": { "type": "Collection", "id": "https://social.example/note/123/replies", "items": [{ "type": Note", "id": "https://social.example/note/987", "attributedTo": "https://social.example/bob", "inReplyTo": "https://social.example/note/123", "content": "Ha ha ha... Yes!" }] } } }If the originating server doesn't check the embedded replies collection, a recipient that processes replies and trusts same-origin embeddings unconditionally may end up trusting the forged note.
What we can do?
- Sender: find all embedded objects with local id and reject activity if they are not known.
- Recipient: trust embedded object only if the wrapping object has the same owner.
I think the second solution is much easier to implement. It reduces the utility of embedding in the use case described by @julian, but to be honest I doubt that embedding significantly reduces the number of required HTTP requests in that case.
marius
@silverpill do you mean that the "malicious" attachment is not a facsimile of an actual note produced by that actor, but a forgery?
In these cases, I'll agree with
@grishka that some validation based on the ID should be necessary.
For embedded object attachments on the other hand (like mastodon produces), probably the validation needs to check that attributedTo corresponds to the one of the parent object or missing.
Interesting corner case.
silverpill
@mariusor This is basically what my FEP currently recommends: you can trust embedded anonymous objects, fragments and object of Create. Everything else should be authenticated using a different method (e.g. fetched from origin).
marius
> - Recipient: trust embedded object only if the wrapping object has the same owner.
@silverpill no, dereference object and use that instead. The canonical version of an object is the one retrieved from the originating service.
Mastodon has popularised this behaviour where embedding collections (like your replies) is done by servers in the name of "optimizing" for request counts. But this introduces issues and personally I think it's a "code smell" for ActivityPub. Embedding should be restricted to anonymous objects. When an ID exists it should be used most of the time.
silverpill
@mariusor I changed the recommendation, I think an embedded object can be trusted if it has the same origin and same owner as its parent: https://codeberg.org/fediverse/fep/src/commit/69b7f77863844482be9d3b00abce7a93bdde9dff/fep/fe34/fep-fe34.md#embedding
Although I agree that in general embedded objects should be avoided, especially embedded collections.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.