大丈夫そうだった
https://mstdn.mizunashi.work/@mizunashi_mana/110446949994753945
@noellabo なるほど、WebFinger の JSON の方には verified_at は含まれてないんですね。ローカルはローカルで verified_at 持ってるんですね、なるほど
ならば、リモートの方を見ないようにすれば確かに安全そうですね。ありがとうございます！
@noellabo https://github.com/mastodon/mastodon/blob/55785b160320783392ffe3f24c5ca48e6ee7a5f2/app/services/activitypub/process_account_service.rb#L60
ちゃんとローカル側でも verify link 走らせてるんですね。リモートサーバまで見に行かないでローカルサーバで Verified がついてるかを確認するようにすれば安全そうですね
@noellabo verified_at じゃなくて field entity でした
https://docs.joinmastodon.org/entities/Account/#Field
@noellabo ちょっと気になるので今調べてるんですが、Account の verified_at がリモート側の言い分を信じてたら、ユーザにはその URL の持ち主が verified したアカウントのように見えてしまうので、信ぴょう性が上がると思ったという感じです
つまり、https://ruby-ill.social にインスタンス立ててそこに verified_at: https://github.com/ruby を送ってくるアカウントを作ってリレーとかにばら撒くと、Ruby 公式垢に見えてしまったりしないかなと
Mastodon、実は結構詐称に弱いのか？UI が幾つかリモートに行く前提だから、リモート側の Web UI 工夫するだけでいくらでもフィッシングできそうだな
Mastodon fork して、なんでもかんでもリンクに verified つけるようにすれば、本人詐称できることに気づいた。ちゃんとリンク先から見れるようにするのがいいのか (さっきのは普通に公式垢っぽい)
それ使えば Rust の allocation の邪魔しないで malloc 独自実装できる？
virtual address space reserve の方法よく分からんので後で Go の malloc ちゃんと読むか
最終的には下位3bit Pointer Tagging ぐらいしたいよな
Rust よく分からずに使って低レイヤいじるのめちゃくちゃ無謀感があって良い（？）
とりあえずこういうの書き始めた
https://github.com/mizunashi-mana/mini-stk-lang-with-ms-gc
