arcanicanis on Nostr: What is the recommended mitigation here, is it as simple as a domain match check? For ...
What is the recommended mitigation here, is it as simple as a domain match check?
For flexibility, I think a fair option would be to just try checking if the object really exists at the differing domain (at the alleged object ID), and if so, just use the content of that newly resolved object, as long as things match up (domain of object ID matches up to domain of actor and/or attributedTo).
I’m sure there’s some edge-cases yet that I could be overlooking, but I assume that’s a fair start.
Nonetheless, in the opposite extreme, what I also don’t want to happen is: for the protocol design to be overly locked down that it screws up the minimalistic “IndieWeb” aspirations of the protocol, or restrict the the flexibility of it, or to be prevented from splitting up roles to different subdomains. e.g. where I could have public ActivityPub content be on one subdomain, on a server that’s essentially a static website of HTML and ActivityPub content, and then have the inbox/outbox be on a beefier server on a different subdomain; therefore: even if the server running active code for handling federation traffic goes down, the public content is still online and accessible, versus all of it collapsing down together.
Published at
2024-02-15 20:35:21Event JSON
{
"id": "cd3281bde79e50398fd298fd0702c8e2838461e6ac08f97e255487e4397a25c1",
"pubkey": "0ed7afc8b04a4ef5d52c14fd46c65e452d62ca50a47d6cf5287ed2825a6d26f7",
"created_at": 1708029321,
"kind": 1,
"tags": [
[
"p",
"9491f9228ab18b128c8e08800821e3d958d25b1df637db4221ddd34a1f41d04f",
"wss://relay.mostr.pub"
],
[
"e",
"55d1a33fa7efb1eceb70abed2a1c32f541af94f2184f4e022852f3647c8f9282",
"wss://relay.mostr.pub",
"reply"
],
[
"proxy",
"https://were.social/objects/9dd90e14-5823-4813-99f5-9dacf1c467a9",
"activitypub"
]
],
"content": "\n\nWhat is the recommended mitigation here, is it as simple as a domain match check?\n\nFor flexibility, I think a fair option would be to just try checking if the object really exists at the differing domain (at the alleged object ID), and if so, just use the content of that newly resolved object, as long as things match up (domain of object ID matches up to domain of actor and/or attributedTo).\n\nI’m sure there’s some edge-cases yet that I could be overlooking, but I assume that’s a fair start.\n\nNonetheless, in the opposite extreme, what I also don’t want to happen is: for the protocol design to be overly locked down that it screws up the minimalistic “IndieWeb” aspirations of the protocol, or restrict the the flexibility of it, or to be prevented from splitting up roles to different subdomains. e.g. where I could have public ActivityPub content be on one subdomain, on a server that’s essentially a static website of HTML and ActivityPub content, and then have the inbox/outbox be on a beefier server on a different subdomain; therefore: even if the server running active code for handling federation traffic goes down, the public content is still online and accessible, versus all of it collapsing down together.",
"sig": "950f3f7c490fdda242ef83db62e92282e1ce9c4b1e855f471b8ec2446719f1b4b2929d105924ea184501b25e4c66e6e9453cacc400e4a7d005b7c1a2996eb5bf"
}
