While working on #Fedify, I noticed something about how #Misskey handles #ActivityPub object access.
Technical Discussion
11
Posts
4
Posters
2
Views
-
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
-
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.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@julian @reiver @fedicat @johannab
Yes, I've tried AI as a brainstorming assistant, and if you keep a keen eye on the conversation it works great. And there are many other good uses too.
But I feel that the net effect of AI on the fabric of our society will be quite negative, making regular people overly reliant on exploitative technology they do not own.
Huge AI bubble or not, it may be a passed station, and AI here to stay. Tech comes 1st, technology progress decoupled from human progress.
-
@liaizon@social.wake.st what do you define vibe coding as?
Vibe coding is prompting, followed by copy-paste, and then re-prompting with the error message, repeat.
In no step there is any critical thinking.
If you are inspecting the generated code, applying it judiciously, and asking questions back to further understand the decisions made, you are not vibe coding.
-
@julian I can say as someone who has learned quite a lot about a bunch of super technical topics from doing some exploration of vibe coding that I completely disagree with this sentiment. I think the companies and ways the AI industry is operating is horrid and abysmal but those two things shouldn't be conflated.
-
@uwehalfhand@norcal.social I feel we're conflating vibe coding with plain AI usage as an assistant.
There's absolutely no pedagogical value to vibe coding.
-
@reiver and, I would like to add, who they're politically supporting with that money
-
@reiver #LLM use is antithetical to the principles of freedom of Internet, so dear to the #fediverse
They're tools of control, by large corporations, which use their revenue and influence to erode democracy, concentrate wealth, take power away from people. Exactly the opposite of what fediverse stands for.
"Vibe coding" is an insult to any and everyone who dedicated effort, time to learn to code.
-
@reiver@mastodon.social
Overall, I'm anti-"vibe coding" because new coders don't always know enough to see the logical fallacies, security vulnerabilities, etc. It's not usually a big deal if you're just making a simple desktop app but it can have huge implications for software that is open to the internet, has an expectation of properly handling user data, and needs to compatibly interoperate with other servers. Also, the energy and theft problems inherent to all "AI" use.
But I think we should be pragmatic. "Vibe coding" not going anywhere, so doing what we can to help keep everyone as safe as we can while stopping poorly understood code from DDOSing across the fediverse is the more mature path.
That doesn't mean we shouldn't discourage "vibe code" or at least encourage gaining education and/or experience before relying on it, though.
