While working on #Fedify, I noticed something about how #Misskey handles #ActivityPub object access.
-
Fedifyを開発していて気づいたことなんですが、MisskeyのActivityPubオブジェクトへのアクセス処理について少し疑問があります。リモートサーバーから、アクセス権限のあるアクターの有効なHTTP Signaturesを含むリクエストでフォロワー限定投稿やDMにアクセスしようとしても、Misskeyは内容を返さずに404を返すようです。どうやらMisskeyはHTTP Signaturesを検証せず、visibilityフィールド(publicとhome)だけを確認しているようです。
Mastodonの場合、authorized fetchを有効にすると、HTTP Signaturesを検証して、リクエストしているアクターに権限があれば内容を返します。MisskeyもMastodonのような仕組みを採用してくれたら、ActivityPubが意図しているアクセス制御のセマンティクスをより適切に尊重できるんじゃないかと思います。他の方も同じようなことに気づかれたことはありますか?それとも、Misskeyがこのような処理をしている特別な理由があるのでしょうか?
#Fedify #Misskey #ActivityPub #Mastodon #authorized_fetch #fedidev
-
For reference, Fedify makes implementing this kind of fine-grained access control quite straightforward—you can check the Fine-grained access control section in the documentation.
-
参考までに、Fedifyではこのようなきめ細かいアクセス制御を簡単に実装できます。ドキュメントの「Fine-grained access control」セクションをご覧ください。
-
Yeah and the replies collection isnt there on misskey either
-
undefined hongminhee@hollo.social shared this topic
-
@hongminhee woof. That's an important feature and a lot of the network fabric comes apart in that situation. If you can't refetch remote ActivityPub objects from their source, you have to keep them cached indefinitely. That gets very messy very quickly!
-
@hongminhee woof. That's an important feature and a lot of the network fabric comes apart in that situation. If you can't refetch remote ActivityPub objects from their source, you have to keep them cached indefinitely. That gets very messy very quickly!
@evan@cosocial.ca Yeah, indeed. It's also fragile for network errors.
-
@hongminhee woof. That's an important feature and a lot of the network fabric comes apart in that situation. If you can't refetch remote ActivityPub objects from their source, you have to keep them cached indefinitely. That gets very messy very quickly!
@evan@cosocial.ca to be fair, I think public objects are okay, it's just objects with limited visibility that are affected?
While I agree that they should be accessible when requested, perhaps the developers erred on the side of caution to guard against information leakage?
-
@julian It's not "information leakage" to return an ActivityPub object to an actor it was addressed to. That's just communications; it's the whole point of ActivityPub.
-
@julian It's not "information leakage" to return an ActivityPub object to an actor it was addressed to. That's just communications; it's the whole point of ActivityPub.
@evan@cosocial.ca not that, I meant, in the case of a logical error/bug that would accidentally return privileged activity data to someone who was not meant to see it. I'm just saying I could see the mental justification in saying "this is non-public data, I'd rather be safe and just not make it accessible on request, and only send the activity".
Not saying it's correct, just maybe providing an explanation.
-
@julian No, I get it. It's just a catastrophically bad engineering decision.