Returning objects in a collection vs. IDs
Technical Discussion
27
Posts
6
Posters
124
Views
-
@trwnh @silverpill @julian @technical-discussion but even if, the actor object is still the ultimate source of truth as it's the one which contains the key ID
@grishka @silverpill @julian @technical-discussion true but we are talking about mistakes. like taking the origin of the keyId on the http sig instead of following the link to the owner/controller. such assumptions might be true for monoliths, but not everything is a monolith
-
Web Annotations has a neat solution here which is prefers representation, which allows the requestor to ask for minimal or full representation (i.e., just the IDs or the full representations)
You'd still likely want to gate that on authorization
-
@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.
@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. -
@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.
> and it's wildly impractical to use anyway.
@grishka shush, you! 🤫
-
@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.@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 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.
@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
repliescollection, a recipient that processesrepliesand trusts same-origin embeddings unconditionally may end up trusting the forged note.What we can do?
- Sender: find all embedded objects with local
idand 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.
-
@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
repliescollection, a recipient that processesrepliesand trusts same-origin embeddings unconditionally may end up trusting the forged note.What we can do?
- Sender: find all embedded objects with local
idand 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.
> - 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.
-
> - 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.
mariusor@metalhead.club silverpill@mitra.social C2S brings with it a whole other rat's nest of security concerns.
In an S2S context same origin content ought to be trusted as having been verified. I'd argue a server blindly reflecting received AP content is a vulnerability.
-
@julian I'm not sure what "blindly reflecting" means, but it's at most as vulnerable as using iframes and way less than trusting CDN scripts.
The way GoActivityPub uses C2S is through clients that validate and sanitize content that they serve back to users, or store in a persistence layer.
Personally I don't understand why it would make it different than S2S?
Are you thinking about C2S from a JavaScript client perspective only?
-
> - 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.
@mariusor This is basically what my FEP currently recommends: you can trust embedded anonymous objects, fragments and
objectofCreate. Everything else should be authenticated using a different method (e.g. fetched from origin). -
@silverpill oh, I see. I must have missed the context for the discussion, sorry. :)
@technical-discussion @julian @grishka
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@caohuak Thank you!
-
@silverpill I created an issue.
https://activitypub.software/TransFem-org/Sharkey/-/issues/1212
-
The minutes from this month's ForumWG minutes were just posted.
Ironically, I need to make a separate post to reference it in this group, because we have not invented federated cross-posting yet.
But soon!
-
Hi Nutomic, thanks for joining the forum.
While I have you, I wanted to ask you about the removal of audience from Lemmy. I believe the rationale for it was that it was not used outside of Lemmy, but both Piefed (rimu@piefed.social) and NodeBB use it.
I still think the explicit use of the audience property is more helpful than not.
I discovered another use case for it, although it is a bit of an edge case. Last night a user from lemmy.ca posted to activitypub@community.nodebb.org. Here, there are no followers to that group actor, so it did not federate here. However, one of the relays this site subscribes to did Announce the topic, and when it arrived here, NodeBB could not accurately determine whether the topic/post _actually belonged to activitypub@community.nodebb.org.
Specifically, it is because sometimes users (on Mastodon or other sites) mention group actors but don't intend for the post to be made there. It is not a strong enough signal.
But audience being explicitly set does provide that strong signal. I've updated NodeBB's code to trust the group actor if located in audience.
-
@carloshr as always, my best ideas are the ones that seem so obvious to me that i figure someone else surely has already had them
-
@jonny what a great idea! 🤯
-
what if a torrent contains self-authenticating signed activitypub objects???? what if we could jump back and forth between federation and p2p?
-
@jonny oh shi
