https://github.com/mastodon/mastodon/blob/2cab1c7b09f64cae8128fa33645137fe55daf075/app/lib/link_details_extractor.rb#L198-L200
https://github.com/mastodon/mastodon/blob/ff08d99d4dceebd720e16e4a40118cbd6941b0ca/app/services/fetch_link_card_service.rb#L154
Mastodonによる`fediverse:creator`の値の解釈が`ResolveAccountService`に丸投げで、いかにも実装詳細ダダ漏れという感じだ（先頭に`@`を付けても付けなくても良い。ただし`acct:` URIは受け付けない）
`fediverse:creator`は帰属の主張の真正性の担保周りでsecurity considerationsがそれなりに繊細そうな機能なのに明文化された仕様がないのも危なっかしく感じるな。このあやふやな状態のまま他実装が追従したらどこかしらでなりすましの脆弱性が成立しそう。実装間のセキュリティモデルの食い違いが深刻な結果に繋がりかねない性質の機能だし
セキュリティモデルの食い違いと関連した話として、Webページからアクターへの`fediverse:creator`によるリンクの検証の手段としてアクターからページへの`PropertyValue`によるリンクを使うという提案（<https://github.com/mastodon/mastodon/pull/30398#issuecomment-2183993789>）があるけど、仮にページからアカウントへのリンクで`rel="author"`を使うとするとなりすましに繋がるケースがありそう。
というのも、アクター`alice.example/`が`example.com/~Alice`にリンクしていたとして、`example.com`としては`example.com/~Mallory`が`alice.example/`へ`rel="author"`リンクを張ることを妨げる理由がないので。
これを解決するには少なくともアクターからページへのリンクかその逆のいずれかは（それこそ`fediverse:creator`のような）新規の仕組みにするしかなさそう。新規の仕組みなら仕様として例えば`rel="me"`の検証なしでの使用を禁じたり出来ると考えられるので
類似の事例として`as:attributedTo`があって、これも概念的にはオブジェクトがアクターへの帰属を一方的に主張しているだけなわけだけど、こちらは同一ドメイン内での帰属の主張を信用するという慣習的なセキュリティモデルによって運用が成立しているわけですね（なおtype confusion（？））
（現状の`as:attributedTo`の運用もこれはこれで例えば別々のドメインに属する複数のアクターによる共著を表現したいときなどに困るだろうけど、そういった場合はObject Integrity Proofなどの別の手段で検証する運用になるだろうか）
このアカウントは、notestockで公開設定になっていません。
