Returning objects in a collection vs. IDs
Technical Discussion
27
Posts
6
Posters
202
Views
-
@silverpill @julian @technical-discussion
> The server hosting the malicious actor can't realistically verify every embedded objectHow so? It's a responsibility of that server to authenticate its actors, and restrict them from impersonating other actors on the same server, C2S or not. I don't quite understand the threat model here. In mine, clients are always assumed malicious.
grishka@mastodon.social silverpill@mitra.social yes I had the same question.. I assumed this would only occur in a C2S context but even then the server is an intermediary and can verify.
-
grishka@mastodon.social silverpill@mitra.social yes I had the same question.. I assumed this would only occur in a C2S context but even then the server is an intermediary and can verify.
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
Notethat 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. -
> messy... mixing types
if mixing types is a concern you can serve ids in object form: {"id": "foo"}
-
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
Notethat 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 @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.
-
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
Notethat 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 @julian @technical-discussion @grishka this wouldn't be "malicious", it would be "unverified". anyone can say anything about anything. it'd be like if i said herman melville wrote moby dick, and you didn't trust me until you verified with herman melville himself that he wrote moby dick. it's just a statement that you can either accept or reject. maybe you don't trust alice to make claims about bob, or maybe you trust social.example to make claims on social.example
-
@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 @silverpill @julian @technical-discussion what does exist is publishing an AS2 resource on a web server, which you can do with any "api" you want -- ftp, rsync, ssh, anything that can get a file in a folder served by nginx with the appropriate headers. "c2s" is literally just an endpoint that you can POST some json to and it will publish that json and POST it to others. you can replace it with curl.
-
@grishka @silverpill @julian @technical-discussion what does exist is publishing an AS2 resource on a web server, which you can do with any "api" you want -- ftp, rsync, ssh, anything that can get a file in a folder served by nginx with the appropriate headers. "c2s" is literally just an endpoint that you can POST some json to and it will publish that json and POST it to others. you can replace it with curl.
@trwnh @silverpill @julian @technical-discussion if I remember the spec correctly, that endpoint does have to do at least *some* interpretation of the json — for example, the spec explicitly says that Block activities that come into the inbox "MUST NOT" be exposed in the client's view of the inbox, but instead interpreted and acted upon by the server itself
-
@trwnh @silverpill @julian @technical-discussion if I remember the spec correctly, that endpoint does have to do at least *some* interpretation of the json — for example, the spec explicitly says that Block activities that come into the inbox "MUST NOT" be exposed in the client's view of the inbox, but instead interpreted and acted upon by the server itself
@grishka @silverpill @julian @technical-discussion i think you're referring to how Block should not be sent to an inbox if posted to an outbox? but this is just a rule for outboxes. the user/agent can manually send whatever notifications they want. the user/agent can also follow those rules and just store the relevant json on any properly configured web server.
-
@grishka @silverpill @julian @technical-discussion i think you're referring to how Block should not be sent to an inbox if posted to an outbox? but this is just a rule for outboxes. the user/agent can manually send whatever notifications they want. the user/agent can also follow those rules and just store the relevant json on any properly configured web server.
@grishka @silverpill @julian @technical-discussion point being, you can completely upend a lot of fedi applications' security models with just nginx and curl and subdirectories.
-
@grishka @silverpill @julian @technical-discussion point being, you can completely upend a lot of fedi applications' security models with just nginx and curl and subdirectories.
@trwnh @silverpill @julian @technical-discussion I still wouldn't call that "upending". The actor objects — that reside on that server — contain public keys, which the entire security model of the entire fediverse relies on. So it follows, then, that since a server can serve any arbitrary public key for any of its actors, and the rest of the fediverse will unquestionably trust it, it can also be trusted with any other objects on the same domain.
-
@trwnh @silverpill @julian @technical-discussion I still wouldn't call that "upending". The actor objects — that reside on that server — contain public keys, which the entire security model of the entire fediverse relies on. So it follows, then, that since a server can serve any arbitrary public key for any of its actors, and the rest of the fediverse will unquestionably trust it, it can also be trusted with any other objects on the same domain.
@grishka @silverpill @julian @technical-discussion the key can be on a different keyserver
-
@grishka @silverpill @julian @technical-discussion the key can be on a different keyserver
@trwnh @silverpill @julian @technical-discussion it can in theory but no software currently in existence supports that
-
@trwnh @silverpill @julian @technical-discussion it can in theory but no software currently in existence supports that
@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
-
@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.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@bjb so a smaller and smaller audience as the conversation goes on? Eventually too small to keep the conversation up?
-
Intersection of Alice and Bob's followers.
-
@pauamma so, the audience for replies gets smaller and smaller as the conversation grows?
-
-
@evan @maj
So the third item should be "Anyone who are following both Alice and Bob" to be clear. Current form of the item (candidate) can be read "Anyone following whichever Alice or Bob, but not both" as I've confused.
-
@evan You asked "should", not "does", so my answer is "only people who follow *both* Alice and Bob", that is, the intersection of both sets of followers. (Your 3rd option, to me, reads like "people who follow *either*", that is, the union.)
Whether Alice-only follower Carol (resp. Bob-only follower Dave) should gain access to Bob's reply by following Bob (resp. Alice) after Bob's reply is unclear to me.
-
Huh?
I'm sorry I encroached on your poll without your invitation. I saw it, it looked interesting, so I submitted my vote and explained my "other" as requested.
If you didn't want to hear people's thoughts, don't ask for them.
