Post · bonfire.cafe

Post

While working on #Fedify, I noticed something about how #Misskey handles #ActivityPub object access. When a remote server requests a followers-only post or DM with a valid HTTP Signatures (draft-cavage) from an authorized actor, Misskey still returns 404 instead of the content. It seems Misskey only checks the visibility field (public/home) without verifying the signature at all.

#Mastodon takes a different approach—when #authorized_fetch is enabled, it validates the HTTP Signatures and returns the content if the requesting actor has permission. I think it would be beneficial if Misskey could adopt a similar mechanism, since it would better respect the access control semantics that ActivityPub intends. Has anyone else run into this, or are there specific reasons Misskey handles it this way?

#fedidev

Evan Prodromou

@evan@cosocial.ca replied · 3 weeks ago

@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!

julian

@julian@activitypub.space replied · 3 weeks ago

Re: While working on #Fedify, I noticed something about how #Misskey handles #ActivityPub object access.

@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?

Evan Prodromou

@evan@cosocial.ca replied · 3 weeks ago

@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

@julian@activitypub.space replied · 3 weeks ago

Re: While working on #Fedify, I noticed something about how #Misskey handles #ActivityPub object access.

@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.

Evan Prodromou

@evan@cosocial.ca replied · 3 weeks ago

@julian No, I get it. It's just a catastrophically bad engineering decision.

洪民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social replied · 3 weeks ago

@evan Yeah, indeed. It's also fragile for network errors.

gabboman the wafrn dev [SINGLE INSTANCE EDITION]

@gabboman@gabboman.xyz replied · 3 weeks ago

@hongminhee@hollo.social

Yeah and the replies collection isnt there on misskey either

洪民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social replied · 3 weeks ago

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.

Access control | Fedify

Fedify provides a flexible access control system that allows you to control who can access your resources. This section explains how to use the access control system.

洪民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social replied · 3 weeks ago

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