ハクソク

世界を動かす技術を、日本語で。

ブラウザはサンドボックスである

2026年1月26日原文(simonwillison.net)

概要

  • Paul Kinlan によるブラウザサンドボックスの研究
  • ブラウザが 安全なエージェント実行環境 として機能する可能性
  • Co-doデモ で実証された主要技術
  • ファイルシステム、ネットワーク、コード実行の3要素の解説
  • <input type="file" webkitdirectory> の新知見

ブラウザはサンドボックス

  • Paul Kinlan はGoogleのWeb Platform Developer Advocate
  • 近年は エージェントのコーディング に注目
  • ブラウザは 過去30年で最強のサンドボックス として進化
  • 世界中の 不特定多数のコード を即時実行可能な設計
  • Coworkのようなアプリを ブラウザで再現可能か の検証

Co-doデモの紹介

  • Co-do はCoworkのブラウザ版を目指すデモ
  • ユーザーが フォルダ選択、LLMプロバイダー設定、APIキー入力で利用開始
  • CSP承認API でプロバイダーと通信
  • ファイル操作用の チャットインターフェース を提供
  • ローカルコンテナ不要 で軽量な動作

サンドボックスの3要素とブラウザ技術

  • ファイルシステム: File System Access API（現時点ではChrome限定）

  • ネットワークアクセス: CSPヘッダーと<iframe sandbox>で制御

  • 安全なコード実行: Web Workers内のWebAssembly利用

    • <iframe sandbox> のドキュメント不足と互換性の課題
    • Paulの投稿で ダブルiframe技法 による詳細なネットワーク制御方法を解説

新しいファイルアクセス技術

  • <input type="file" webkitdirectory> タグの活用
    • Firefox、Safari、Chromeで動作確認済み
    • ブラウザから ディレクトリ単位で読み取り専用アクセス を実現
    • 今後のプロジェクトでの応用可能性

まとめ

  • ブラウザのサンドボックス機能 はエージェント実行環境として有望
  • Coworkのような複雑なアプリも ローカル環境不要で実現可能
  • 今後の Webアプリ開発 への多大な影響

Hackerたちの意見

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

└

これは、元のファイルを操作する必要がないエージェント的なフローでアプリを作る方法だと思ってる。要約したり、質問に答えたり、新しいドキュメントを生成したりする場合、ローカルまたは内部のLLMを使って、ツール呼び出しが制限されてるときに比較的安全に感じられるよ。

└

この枠組みで最も魅力的だと思うのは成熟度の議論だね。ブラウザのサンドボックスは、数十年にわたって怪しいリンクをクリックしてきた数十億のユーザーによってテストされてきたから[…] システムコールも、任意のバイナリも、直接のハードウェアアクセスもない。だから、NPMのプログラマーは、NodeJSの非標準（時々壊れる）APIに直接対抗するコマンドラインユーティリティを書くんじゃなくて、ブラウザのサンドボックスで動けるソースコードプロセッサ（や他のバッチ処理ツール）を書くべきだと思う。

それがないとは言わないよ。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にもね。

└

どれもひどいものだけど、Silverlightは良かったな、廃止されたのが残念。

└

余談だけど、Flashのスクリプト言語であるActionScriptは、後のJava、あ、ECMAScriptの世代デザインに直接関わってるし、TypeScriptにも影響を与えてるんだよね。俺だけがActionScript、特にAS3をめっちゃ好きだった気がする。昔、AS3を使って動画アグリゲーター（chime.tv[1]）を作ったんだけど、すごく楽しかったな。

└

JavaはActionScriptとは関係ないよ。LiveScriptはSun/Netscapeのビジネス契約のおかげでJavaScriptになったんだ。

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

└

これは、人々がDockerfileを書くこと以上のことを知っていると仮定しているけど、実際にはまだ珍しいよね。

└

だって、それは実際にUNIXのユーザー権限/グループで、何がうまくいくか、何がダメかの長い歴史があるからじゃない？

└

cgroupsは、dockerやpodmanを実装するために使われているものの一部だよ。

└

Unixの権限は、（マルチユーザー）システムがユーザーから自分を守るために書かれたものなんだ。すべてのプログラムはユーザーと同じ権限で動いてたから、プログラムがユーザーが思ってることをしないかもしれないっていうセキュリティの考慮はなかったんだよね。だから、クラシックなUnixツールのリストには、プログラムをサンドボックス化するようなものは何もなかった。そんなのは問題にならなかったから。だけど今は…それじゃ不十分なんだ。今日求められてるのは、ソフトウェア同士が互いに保護されて動くこと。しばらくの間、Unixの権限を使って（アプリごとに1ユーザー）やろうとしたけど、全然うまくいかなかった。ユーザー権限モデルじゃなくて、能力モデルが必要なんだ。まあ、このスレッドの他のところでもリンクしたけど、このコメントではこっちの方が合ってると思う。https://xkcd.com/1200/

Hacker Newsで議論の続きを見る