Recent searches
Search options
Hot take: It is bad that #ActivityPub software implements #AUTHORIZED_FETCH, also known as secure mode, because, contrary to its name, it does not actually contribute to security and instead gives a false sense of security.
https://swicg.github.io/activitypub-http-signature/#authorized-fetch
所信發言: #ActivityPub 소프트웨어들이 #AUTHORIZED_FETCH, 이른바 시큐어 모드(secure mode)를 갖추는 것은 이름과 달리 정말로 시큐리티가 나아지게 하지 않으며, 오히려 安全하다는 錯覺(false sense of security)을 주기 때문에 나쁘다고 생각한다.
https://swicg.github.io/activitypub-http-signature/#authorized-fetch
그 證據로, AUTHORIZED_FETCH를 要求하는 #ActivityPub 오브젝트는 `fedify lookup -a` 커맨드로 아주 쉽게 照會할 수 있다.
As proof, #ActivityPub objects that require #AUTHORIZED_FETCH can be easily looked up with the `fedify lookup -a` command.
所信発言：ActivityPubのソフトウェアがAUTHORIZED_FETCH、通称セキュアモード（secure mode）を実装するのは、名前と違って実際にセキュリティに貢献しないし、むしろ安全だという錯覚（false sense of security）を与えるので悪いと思う。
https://swicg.github.io/activitypub-http-signature/#authorized-fetch
その証拠に、AUTHORIZED_FETCHを要求するActivityPubオブジェクトは単純に`fedify lookup -a`コマンドで簡単に照会する事が出来る。
@hongminhee 일단 이 기능 조차 없으면 followers only 같은 기능은 사실 의미가 없는 기능일 수도 있겠네요.
@galadbran 아무래도 좀 그렇죠.
서버메이드 깐프 @hongminhee
@galadbran 마스토돈은 보호된 리소스에 대해서 (비공개 Status) 항상 올바른 크레덴셜로 서명된 GET 요청을 필요로 하기 때문에 그 문제는 없습니다.
AUTHORIZED_FETCH 는 보호되지 않은 리소스에 대해서까지 서명 요구를 확장하는 스위치에요.
@hongminhee
@galadbran 구현 방식이 두 가지인데
보호된 리소스를 그냥 안 주거나 (Misskey)
보호된 리소스에 대해서 인증을 요구하거나 (Mastodon)
둘 중에 하나에요.
@hongminhee@fosstodon.org calling it secure mode is a misnomer, but that's a Mastodon issue isn't it?
@julian @hongminhee I think "secure mode" was a legacy name for it: https://github.com/mastodon/mastodon/commit/5bf67ca91350e40e6f329271d3ca2bdcba87ab64
And yes, authorized fetch being ridiculously easy to circumvent is a problem/limitation with it, but for now there isn't a better approach forwards (object signatures allow untrusted forwarding) — maybe ocaps can better secure activitypub, I'm not sure.
@julian @hongminhee on more closed off servers, I'd honestly expect them to be blocking those local tunnel type services with a wide domain block, also glitch and other "temporary" hosts for instances.
@thisismissem @julian @hongminhee my understanding is that it really only makes sense with a federation allowlist?
@untitaker @julian @hongminhee it makes federation with a denylist stronger too, but yeah, if your automatic federation policy is allow then you've fairly weak security in general.
(Many many fediverse projects default to allow as their federation policy)
@thisismissem @untitaker @julian @hongminhee I thought of it more as authentication, similar to how HTTP uses the Authorization header for authentication. The signature verifies the identity of the calling actor. Then it's up to the server to do authorization based on the actor. If the activity is publicly addressed (& the actor is not banned, etc.) return it. If activity is more arrowly addressed, check if the actor satisfies the address. If so return the activity, if not return an error.