tesaguri 🦀🦝 @tesaguri@fedibird.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I hereby attest that I (tesaguri) own this Fediverse account (<acct:tesaguri@fedibird.com>; <https://fedibird.com/@tesaguri>) and the OpenPGP key <openpgp4fpr:293ada14a1cb0b1c2313310110478e598b944aa2> by signing this message with the key and posting it from the account.

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

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

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

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

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

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

面白い脆弱性だと良いな（すみません）

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

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

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

こんな感じで……

```html
<a href="https://example.com/actors/1" rel="as:cc" type="application/activity+json">@alice@example.com</a>
<img property="as:tag" resource="https://example.com/emojis/1" typeof="http://joinmastodon.org/ns#Emoji" alt=":blobcat_foo:" />
<a href="https://example.com/notes/42" rel="https://misskey-hub.net/ns/" type="application/activity+json">RE: https://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（<https://atproto-browser.vercel.app/>）こそが分散的ということなのですよね（？）

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

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

リレーも建てる試みは一応存在しなかったっけ？　まあいずれにせよ恐らくサードパーティのリレーの存在の有無自体は大した問題ではなくて、というのも恐らくリレーを建てたところでAppViewがそれを見てくれなければ意味がないので