Firefoxはもっと使われるべきだね。 まったく同意だよ。どのサイトで買い物するかを、Firefoxで動くかどうかで選ぶこともあるし、サポートに「対応してない」とか「機能がうまく動いてない」ってたまに連絡することもある。たぶん何も変わらないけど、ブラウザを少しでも意識してもらうためにできることだと思ってる。

Firefoxはもっと使われるべきだね。 問題の一部は、バグ修正をやめると、Mr. Robotみたいなことを始めることだよね… ただのウェブブラウザが欲しいのに。ポケットやAIなんて誰も求めてないよ。もしAIを使ってバグを全部直すなら、彼らは他に何をするの？ 様々な言語との構文互換性を維持することだけ？ またブラウザをゴミに戻すだけだよ。

Chromeは99%以上のユースケースで意味のある点で良くないよ。俺は開発者だけど、過去10年くらいFFをuBlock Originだけで使ってる。妻も同じで、俺がいろいろ説明したら、インターネット体験がどれだけ違うか理解してくれたから、彼女もそれがメインブラウザになった。だから、「ここにクソみたいなアンダードッグがあるけど、独占は悪いから使って」みたいな議論はやめてほしい。俺が試した中では、全てにおいて一流の体験なんだ。モバイルではそれが3倍になるし、最高のモバイル体験だよ。

君の定義にはちょっと混乱したけど、Mozillaが271の、えっと、ものをこう分けたんだ： > 追加のコンテキストとして、バグの緊急度を示すために、セキュリティの重大度評価をクリティカルからローまで適用しているよ： > * sec-criticalとsec-highは、通常のユーザーの行動で引き起こされる脆弱性に割り当てられる。ウェブページをブラウジングするような行動だね。技術的には違いはないけど、sec-criticalバグは公開されているか、実際に悪用されていることが知られている問題に予約されている。 > * sec-moderateは、通常はsec-highと評価されるはずの脆弱性に割り当てられるけど、被害者からの異常で複雑な手順を必要とするもの。 > * sec-lowは、煩わしいけどユーザーに害を及ぼすことはないバグに割り当てられる（例えば、安全なクラッシュ）。 > Firefoxのために発表した271のバグのうち、150はsec-high、80はsec-moderate、11はsec-lowだった。Mozillaはsec-highでも「脆弱性」という用語を使っているけど、その下で実際の悪用とは同じ意味ではないと言っている。定義のページでは、sec-lowも「脆弱性」として分類されている [2]。言葉は道具で、集合的な意味からその有用性を得るものだ。君がどこでその意味論を得たのか、Mozillaと一致するのか、違うのか興味があるな。

Mythosは、メモリ安全でない動作を示す全てのバグに対してPoCを書いたんだ（例えば、use-after-freeやバッファオーバーランなど）。私たちにとっては、これがセキュリティ脆弱性と見なすのに十分な証拠なんだ、他に示されない限りはね。これは常にそうだったし（ファジングバグにも）。

Mythosは脆弱性のために271のPoCを書かなかったけど、君が言いたいのは「エクスプロイト」ってことかな？

これは、優先順位を決める必要がある場所ではどこでも真実じゃないよ。

Claudeは、もし自分がそのコードを持っていると思えば、見つけた脆弱性に対してPoC（Proof of Concept）エクスプロイトを生成することができるし、実際にそうするだろうってことは覚えておいてもいいかも。これについての唯一の情報源は自分の経験だけで、証拠は共有できないけどね。

このアプローチの一般的な限界は、バリデーターの質に依存するってことだね。テストケースを使って、例えばAddressSanitizerのuse-after-freeを作るのは簡単だから。もっと微妙な問題に対しては、より具体的なバリデーターが必要になるのかな？それともLLMが他の危険な条件を見つけるのが上手くなるのかな？様子を見てみよう。

MythosはC++コードの脆弱性を見つけるのが他の言語よりもずっと得意かもしれないね。結局、これらのモデルは既存のセキュリティ分析に基づいてるから。俺が見る限り、これらのバグはほとんどC++特有のものではなくて、単にC++コードで発生しただけなんだ。最も安全なRustでも、TOCTOUの問題のようなものを魔法のようにキャッチすることはできないよ。

コードはオープンだよ。もしそれが証明できたら、リアルなニュースになるね…

一方で、AISLEのような他の会社は、古いモデルを使って自社のハーネスでMythosに匹敵する脆弱性を出してるよね。 https://aisle.com/blog/aisle-matches-anthropic-mythos-on-fre... だから、Mythosが本物なのは確かだけど、Deepseek proやGPT 5.5などでも同じことができると思うよ。

リンクされたハックスブログ https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...

これについて考えてたんだけど、静的解析ツールはかなり速いし、ほとんどが完全に決定論的だから、CIに組み込むことでバグや潜在的なバグを早めにキャッチできるんだよね。俺はFirefoxのCIで使う静的解析ツールを維持してるんだけど、誤検出は修正するか、問題じゃないって注釈をつけないと、パッチをツリーに入れられないんだ。つまり、誤検出も真の検出もゼロにする必要があるってこと。これは意識的なトレードオフで、解析を弱めて誤検出（見逃したバグ）を出す必要があるんだ。そうしないと、シグナル対ノイズ比が高すぎて、みんなが無視したり、注釈をつけたり、実行をやめたりするからね。ほとんどの静的解析ツールはこういうバランスを取らなきゃいけない。AIは一般的にもっと自由度があるけど、誤検出を許すのが基本的なところなんだ。これがその力の源になってるから、上に検証とバリデーションの層を重ねる必要がある。遅くなるし、「この特定の形式のエラーを100%キャッチする」なんて言えないけど、たくさんの問題を見つけてくれる。データポイントとして、俺の解析は、真の検出（実際のバグ）が出る可能性が低いと思ってたケースをカバーしてなくて、実装するのが面倒だと思ってたんだ。OpusかMythos、どっちかがそのケースからの脆弱性を報告し始めたから、急いで分析を拡張してそのギャップをカバーした。実装に時間がかかって、ソースツリーのフルスキャンを終えた頃には、Claudeが報告した重要な問題を全部見つけてた。静的解析は他にもいくつか見つけたけど、正直言って、それらが実際にトリガーされるかどうかはまだわからない。静的解析には価値があると思ってる。問題のあるパターンのいくつかは、AIが構築できないようなトリッキーなパスを通って到達できるかもしれないし、他のコードが変更されると本当の問題になるかもしれない。今のところ、両方の可能性に対して修正を用意しておく価値があると思うし、AIに無駄な時間を使わせたくないっていう小さな理由もある。一方で、明らかにコスト/ベネフィットのバランスは変わってきてる。チームを組むこともできるね。もし俺が基準を緩めて、分析が疑わしい問題の追加警告レポートを書くことを許可すれば、誤報の可能性があることを明確に期待して、AIにそのリストを渡して検証させることができる。要するに、スロップをスロップマシンに流し込んで、粗い中からダイヤモンドをフィルタリングさせるって感じ。考える材料だね…

LLMはツールを置き換えるよりも、ツールを使うのがずっと得意だよ。ツールは一般的に、LLMで同じ結果を得るよりもずっと速い。LLMのコーディングツールを使って静的解析ツールの出力を管理するのはすごく効果的だし、問題がないことを強制するガードレールを追加するのはいいアイデアだと思う。すべてがクリーンであることを確認するためにCIチェックを追加するのと同じだね。誤検出については、ツールによるかな。俺はノイズを大量に生成するツールは避ける傾向がある。ほとんどのツールは、ノイズが多い場合はルールを無効にすることを許可してるし、LLMにすべての問題を修正するように指示することもできる。ルールと議論するよりも修正する方が安いなら、修正しちゃった方がいい。手動でやらなきゃいけなかった頃は本当に高くついたけど、今はそうじゃない。最近、数年触ってなかったAnsibleのコードベースをリフレッシュするためにこれをやったんだ。何百ものansible-lintの問題があって、ほとんどが非致命的な警告や廃止警告だった。10分後にはゼロになったよ。たぶんそれほど深刻なものではなかったけど、技術的負債の一形態だね。何百もの警告を手動で修正しなきゃいけないなら、たぶんやらないだろうけど、魔法の杖を振って全部解決できるなら、やらない手はないよね。ガードレールを調整して、今は常にansible-lintを実行して問題を修正するようにしたよ。追加で数秒しかかからないし。

面白い可能性として話題に上がっているのは、静的解析ツールを強化して、LLM（大規模言語モデル）が最初に発見するバグの形を見つけることだね。静的解析ツールは速くて安価だから、大規模なコードベースに対してスケールしやすいし、LLMの手法を一般化することもできるかもしれない。

両方とも正しいけど、どのモデルを使うか、誰がそのバグを提出するかによるね。先進的なモデルの能力は、数ヶ月で99%のノイズから99%の有効なバグに変わった。あるプロジェクトは前者に溢れていて、メンテナに対する本質的なDoS攻撃を避けるための対策が必要なんだ。