フォルダ入力のやつ、最初に見たときはびっくりしたよ。何年もウェブアプリを作ってきたのに、webkitdirectory属性を見逃してた。これを考えると、成熟度の議論が一番興味深いね。ブラウザのサンドボックスは、何十年も怪しいリンクをクリックしてきた数十億人のユーザーによってテストされてきたからね。それに比べて、信頼できないコードを実行するたびに新しいコンテナを立ち上げるのは大変だよね。もちろん、トレードオフは明らかで、ブラウザができることに制限される。システムコールもできないし、任意のバイナリも使えないし、ハードウェアに直接アクセスすることもできない。多くのAIコーディングタスクにはそれで問題ないけど、他のタスクには致命的な欠点になることもある。実際のセキュリティの面積をベンチマークしてる人が見てみたいな。「ブラウザは安全」ってのは実際には正しいけど、最小限のコンテナと比べると攻撃面は膨大だよ。

それがないとは言わないよ。GoogleがNaClを開発した理由があって、それがWebAssemblyを究極のサンドボックス標準にするインスピレーションになったんだ。しかも、DOM、JS、CSSもレンダリング標準のサンドボックスとして機能してるし、能力ベースのデザインは多くのブラウザで見られるよ、Netscape Navigatorから始まってね。機能を制限して統一された体験を提供するのがブラウザの役割だから、パフォーマンスに関係なくね。もちろん、プラットフォーム特有のものを導入してこれを壊そうとしたベンダーもいるけど、それがIEや後のEdge（非Chrome）がひどい目に遭った理由でもあるよ。ただ、Adobe FlashやActiveX、Java Applet、Silverlightのような外部サンドボックスの脱出もあるけど、これらはどれもひどいものだけど、別のサンドボックスでもあるんだよね…でも、asm.jsや後のWebAssemblyの安定化によって、そういうのはすっかり消えちゃった。余談だけど、Flashのスクリプト言語であるActionScriptも、後のJava、あ、ECMAScriptの世代デザインに直接関係してるし、TypeScriptにもね。

systemdやLinuxのユーザー権限/グループがサンドボックスの議論に出てこないのが面白いと思った。どちらもかなり堅牢で、カスタマイズの幅も広いし、性質上、コストも低いんだよね。

エージェントが動作するための堅牢なサンドボックスについて、単純にエージェント用に別のコンピュータを用意することを提案したい。なんでこんなに複雑にする必要があるのか分からない。ナノEC2インスタンスは月5ドルくらいだし、今の私たちの多くは仮想化に頼らずにオンプレミスでこれを実現できると思う。

信じられないな。特定のユースケースにはすごく役立つかもしれないけど、デスクトップオートメーションの流行や「料理のためのClaude」みたいなものが続く中で、ライブビジネスアプリケーションのコンピューティングモデルは、メンテナンス性、監査性、セキュリティ、データアクセスなどの観点から、クラウド中心になってしまってる。だから、ほとんどの「本物」のアプリにとってローカルで動かすのは…ちょっと無意味になってる。個人の生産性の可能性にはワクワクしてるけど、これが解決策だとは思わない。もしそうなら、AppleScriptやCOM、DDE（覚えてる？）を使って、主流のデスクトップOSでちゃんとしたデスクトップオートメーションができなくなってないはずだ。

これは私のリンクブログのエントリーなんだけど、リンク先の記事を読んで全体の文脈を理解してほしい。私のコメントだけじゃ意味がわからないかもしれないから。https://aifoc.us/the-browser-is-the-sandbox/

Simonや他の人にブラウザでできる2つのことを指摘したい。1) webcontainerを使えば、Node.jsのフロントエンドとバックエンドアプリをブラウザで動かせる。これは（今は残念ながらメンテされていない）bolt.diyプロジェクトで簡単にデモされてる。2) jslinuxやx86 Linuxの例を使えば、WASMで完全なLinux環境を動かせて、双方向通信もできる。薄い拡張がLinuxにネットワーキングサポートを追加するから、技術的にはURLを訪れるだけでかなりフル機能のエージェントシステムを動かすことが理論的には可能なんだ。

これはFile System Access APIがどれだけ便利かの素晴らしい例だね。http://co-do.xyz/ では、ディレクトリを選択してAIにその中で作業させることができるから、副作用を心配する必要がないんだ。File System Access APIは、ここ数年でウェブに起きた最高のことだよ。ウェブアプリが一流の生産性アプリケーションになるんだから。

AIがツールコールで長時間セッションを行えるようになってから、AIごとに1つのVMを使うサービスがかなり儲かるようになった。でも、実際にはブラウザ内で動かせるものがたくさんあると思う。特に、コードをライブアップデートしたり、マウントされたファイルシステムの上でシェルを実行したりするだけのものはね。ユーザーのブラウザ内でこれを効率的に実行できるんだ。ただし、失うものが2つある：コラボレーション（できるけど、中央サーバーがないと分散問題になる）とバックグラウンドでの作業（ユーザーのタブがサスペンドまたは閉じられると、すべての作業を一時停止する必要がある）。だから、制約の中で作業できれば、プラットフォームとしてたくさんの利点があるよ：レイテンシがかなり下がるし、パフォーマンスはユーザーのハードウェアによって上がるかもしれない（通常はこのために使うVMよりも強力だし）、正しく設計すれば帯域幅も大幅に減らせるし、同時に何千ものVMを動かす必要がなければ、プラットフォームの稼働時間やコストも改善されるよ（それをやってくれるプラットフォームにプレミアムを払う必要もないし）。とはいえ、ユーザーのブラウザにOS全体やWebContainersみたいなものを入れるのが正しい方法かはわからない。少しカスタムなランタイムを構築する必要があると思う。このタイプのローカルなエージェント環境にはね。でも、スムーズなユーザー体験とプラットフォームの成長を得るためにはこれがベストだと確信してる。Framerでは、ウェブサイトの任意の部分を60fps以上でReactコードに再コンパイルできるようにしたから、プラットフォームをサクサクに感じさせて、すぐに公開できるようにするためのトリックが少なくて済んだんだ。[1] OpenAIやAnthropicのような大規模モデルプロバイダーには、GPU負荷が非常に多く、これに利用できるCPUもたくさんあるという興味深いアドバンテージがあるよ。

これ、ファイルシステムをサンドボックス化してるんだ。それは一つの問題のクラスに過ぎない。人々はこれを自分の受信トレイやカレンダー、チャット、ソースコード、財務などに接続したいと思うだろう。ファイルシステムはセキュア？それはいいけど、他はどうなの？あまり良くないね。とはいえ、良いスタートだよ。