AT Protocolのドメイン、名付けてatprotocom!w、じゃあないんだよな

元々スクリプトも文章も脆弱性報告に使える程度には形になっていたのに、仕上げが面倒だからといって公開を先延ばしにしていたら一瞬で9ヶ月も経っていた……(?)

いや、そのハックも含めてMisskey側のGHSAで既に言及されているからやはり見所はないかも

スレッドを表示

原理としては単純な脆弱性なので具体的なPoC自体は大して重要でもないと思うけど、MisskeyのPoCはちょっとしたindirectionを要しているので、そこは見所といえるかも

スレッドを表示

tesaguri/activitypub-type-confusion-poc: Proof of Concept for the type confusion vulnerability of ActivityPub implementations
github.com/tesaguri/activitypu
というわけで、2024-02-17頃にMastodonやMisskeyなどで修正された脆弱性のPoCを今になってこっそりと公開するなどしていた

やべえ秘密鍵をpushしてしまった、もうおしまいだ……(いいえ)

複数の独立した(フォークを含まない)実装に影響するようなクラスの脆弱性でないならあまり私の関心分野ではないかも知れないけど(?)

スレッドを表示

面白い脆弱性だと良いな(すみません)

tesaguri 🦀🦝 さんがブースト

Hello everyone, the Sharkey project has been quiet due to our ongoing efforts to patch major security vulnerabilities in coordination with Firefish, Iceshrimp.js, and upstream Misskey. On Wednesday, November 20th, 2024, our efforts will be finalized with a security release for all affected projects. It is of upmost importance to update your instance(s) to the latest version if you utilize any of the aforementioned software once the patches are released.

s!/#!#!
(`/`の有無でリダイレクトの有無が変わるので、この文脈では重大な誤字)

スレッドを表示

Fedibirdで`misskey-hub.net/ns/#_misskey_quote`と書こうとするとフラグメント部分が消える現象があるのだよな。<example.com/#foo>のように単にフラグメントがあるだけのURLでは再現しないので、条件としてはリダイレクトがあるURLとかだろうか

というかJSONにHTMLを突っ込むのもだるいので、初めから全てXMLにしません?(Atom Activity Streams 1.0の再発明)(?)

スレッドを表示

こんな感じで……

```html
<a href="example.com/actors/1" rel="as:cc" type="application/activity+json">@alice@example.com</a>
<img property="as:tag" resource="example.com/emojis/1" typeof="joinmastodon.org/ns#Emoji" alt=":blobcat_foo:" />
<a href="example.com/notes/42" rel="misskey-hub.net/ns/" type="application/activity+json">RE: example.com/@Alice/42</a>
```

スレッドを表示

何かMisskeyで上手く表示できていないっぽいけど、まあそれはMisskeyが悪いということで(?)

Activity Streamsにおける`tag`の`name`をmicrosyntaxとして扱う慣習が非常にアドホックに思えてならない。こういうのはもっとまともなマークアップ言語に任せるべき仕事でしょ。例えばRDFaとか……(真顔)

スクリプトの内容をURLに突っ込み`eval(location.search)`することでベンチマーク上のスクリプトファイルのサイズを圧縮する技術(存在しない技術)

リポジトリの購読までは"small world fallbacks"で解決できても、例えばリプライの存在の通知といったレベルの"reach"ですらAT Protocolのアーキテクチャでは恐らくネットワーク全体の集約に依存せざるを得ないので、これもかなら極端な設計と言えるかも知れない。
<strong>個人的には</strong>フォロイーからの通知と知らない人間からの通知の扱いが異なるのはある種の思い切りとしてはありなのではと思うけど、まあ少なくとも一般的な考え方ではないよね。この辺りはSMTP的なモデルの方が素直ではある

つまり、Blueskyは分散的ではなくて、ATProto Browser(<atproto-browser.vercel.app/>)こそが分散的ということなのですよね(?)

スレッドを表示

というかそもそもリレーなんてものに関係なく未知URIを都度解決できたならば一般のWebが分散的であるのと同程度には分散的なアーキテクチャと呼べただろうに(この際1 googolplex歩譲って検閲の問題は考えないものとする)、実際はキャッシュの立場が強すぎるっぽいのが惜しいと思っている。
"big world with small world fallbacks"の"small world fallbacks"って結局何なんやねん。クライアントの手元で手作業でDIDを解決・検証してPDSを直接叩くこと?(?)

スレッドを表示

エアプなので文の区切りのたびに免罪符として「恐らく」を挿入している(?)

古いものを表示
Fedibird

様々な目的に使える、日本の汎用マストドンサーバーです。安定した利用環境と、多数の独自機能を提供しています。