ブラウザベースのファイル変換：仕組みとファイルがプライベートであり続ける理由

サーバーベースのコンバーターにファイルをアップロードすると、3 つのことが起こる。ファイルはネットワークを通じて、あなたが管理していない IP アドレスに移動する。そのサーバー上のプロセスがそれをデコードする。そして、サイトの保持ポリシーによって、ファイルは数分から永久にディスク上に留まる。

同じことをブラウザタブで行うと、ファイルはあなたのマシンの RAM から出ることはない。デコーダーはブラウザエンジンが強制する WebAssembly サンドボックス内で実行される。ネットワークが触れられることは決してない。

これはポリシーの違いではなく、アーキテクチャの違いだ。サーバーベースのコンバーターはファイルを削除すると約束できるが、ブラウザベースのものはファイルを受け取ることがないため、漏洩のしようがない。

アーキテクチャ

クライアントサイド変換を実現する 4 つのレイヤー：

レイヤー 1：ファイルアクセス

ファイルをブラウザタブにドロップすると、DragEvent または <input type="file"> が JavaScript に File オブジェクトを提供する。File はファイルの内容ではない。それは参照だ：名前、サイズ、MIME タイプ、そして必要に応じてディスクからメモリにバイトを読み取るメソッド（file.arrayBuffer()）である。

そのメソッドが呼ばれるまで、ゼロバイトが移動されている。ファイルはあなたのファイルシステム上にあるままだ。ブラウザのファイルピッカーは OS レベルのダイアログであり、Web ページはユーザーが明示的に選択した File オブジェクトのみを認識する。

レイヤー 2：フォーマット検出

あらゆるファイルの最初の数バイトは、そのフォーマットを確実に識別する。JPEG は FF D8 FF で始まる。PNG は 89 50 4E 47 で始まる。HEIC ファイルはオフセット 8 に heic または heif ブランドを持つ ftyp ボックスを含む。

ファイルのヘッダー（通常は最初の 32 バイト）を読み取るだけで、拡張子に関係なく実際のフォーマットを確認できる。このチェックは、どのデコーダーもピクセルデータに触れる前に実行される。ヘッダーが一致しなければ、ファイルは即座に拒否される。CPU の無駄も、デコード途中で混乱を招くエラーメッセージもない。

レイヤー 3：デコード

生のバイトはデコーダーを通じてピクセルになる。どのデコーダーを使うかはフォーマット次第だ：

JPEG、PNG、WebP、BMP：ブラウザにはこれらのネイティブデコーダーが搭載されている。createImageBitmap() は圧縮バイトをプラットフォームのコーデック（Windows では Windows Imaging Component、macOS では Core Graphics、Linux/ChromeOS では Skia）に渡し、生のピクセルデータを返す。この経路は高速で、OS が対応していればハードウェアアクセラレーションされ、追加コードは不要。
HEIC：Safari 以外のブラウザは HEIC のネイティブデコーダーを搭載していない。私たちのコンバーターは libheif（C ライブラリ）を WebAssembly にコンパイルして同梱している。.wasm バイナリ（圧縮時 ~1.2 MB）は一度だけダウンロードされ、キャッシュされる。WASM サンドボックス内で完全に HEIF/HEIC ファイルを生の RGB ピクセルにデコードする。
PDF：PDF.js（Mozilla の PDF レンダラー）が各ページを要求された解像度でキャンバスにレンダリングする。サーバーサイドレンダリングは不要。PDF がブラウザを離れることはない。

すべてのデコーダーはメモリから読み取り、メモリに書き込む。どのデコーダーもソケットを開かない。特に WASM サンドボックスはネットワークリクエストを行うことができない：ブラウザは WebAssembly モジュールにネットワーク API を公開しない。C コードが socket() を呼び出したとしても、サンドボックスがそれをトラップする。

レイヤー 4：エンコード

生のピクセルは <canvas> 要素の 2D コンテキストに入る。canvas.toBlob() または canvas.toDataURL() がブラウザの内蔵エンコーダーを呼び出し、JPG、PNG、または WebP を出力する。エンコーダーはプラットフォームネイティブのコードだ：あなたの OS がスクリーンショットを保存するのと同じコードパスである。

出力は Blob、つまりメモリ内のバイトバッファだ。それはダウンロードリンクに渡されるか、JavaScript で構築された ZIP アーカイブにパックされる。どの段階でも、バイトがネットワークソケットに触れることはない。

ブラウザが強制するもの

Web ページは、ブラウザがエンジンレベルで維持するサンドボックス内で実行される。これは紳士協定ではない。プロセス分離によって強制される：

レンダラープロセス：JavaScript エンジン、DOM、WASM ランタイムは、直接のファイルシステムやネットワークアクセスを持たないサンドボックス化されたプロセスで実行される。IPC を通じてブラウザプロセスと通信する。

サイト分離：モダンブラウザは各オリジンを独自のレンダラープロセスに配置する。file-convert-factory.org 上のあなたのファイルは、他のどのドメインで実行されている JavaScript からも見えない。

WASM サンドボックス：WebAssembly モジュールはフラットな線形メモリバッファのみを認識し、それ以外は何もない。ファイルシステム API も、fetch も（JavaScript から明示的にインポートされない限り）、DOM や他のブラウザ API へのアクセスもない。侵害された WASM モジュールができる最悪のことは、自身のメモリを破壊してタブをクラッシュさせることだ。

サーバーサイドコンバーターは、サーバーの OS 上で特権プロセスとして実行される。ディスクへの読み書き、ネットワーク接続の開始、子プロセスの生成が可能だ。セキュリティモデルはサーバー運営者の能力と意図に依存する。ブラウザサンドボックスはブラウザエンジンの正しさのみに依存し、ブラウザサンドボックスはソフトウェアで最も厳重に監査されているセキュリティ境界の 1 つだ。

サーバーベースのコンバーターが約束するもの（そして約束しないもの）

サーバーベースのコンバーターは本質的に悪意があるわけではない。多くは善意のチームによって運営されている。問題は構造にある：

アップロードステップはコピーである。あなたのファイルは今や 2 つの場所に存在する。1 つのコピーはあなたが管理し、もう 1 つは他の誰かが管理する。
削除は約束である。「24 時間後にファイルを削除します」というのは、ログ行、cron ジョブ、バックアップシステム、そしてサーバーにアクセスできるすべての従業員を信頼することを意味する。これらは外部から検証できない。
メタデータはファイルと共に移動する。写真の EXIF データ（GPS 座標、カメラのシリアル番号、タイムスタンプ）はファイルのバイトの一部だ。ファイルがアップロードされれば、メタデータもアップロードされる。EXIF プライバシーガイドでは、そこに何が含まれているか、そしてそれをどのように除去するかを正確に解説している。端的に言えば：このサイトのすべてのコンバーターは、ピクセルをデコードして再エンコードするため、画像データ以外のすべてを削除する。
HTTPS はパイプを保護するが、エンドポイントは保護しない。TLS はアップロード中の転送を暗号化する。ファイルが到着した後に何が起こるかについては何もしない。

ブラウザベースのコンバーターのプライバシー保証はより狭いが、より強力だ。それは「あなたのファイルがデバイスを離れない」と言う。なぜなら、そうするコードパスが存在しないからだ。これは検証可能である。ファイルを変換しながら DevTools のネットワークタブを開いてほしい。WASM バイナリが一度読み込まれた後、その後は何もないのがわかるだろう。ゼロバイトのアップロード。/api/convert へのリクエストなし。WebSocket トラフィックなし。変換は完全にレンダラープロセス内で行われる。