ブラウザ暗号化の確かめ方:平文が端末を出ていないことを証明する

ページ上の「ローカル暗号化」「アップロードしない」は、それ自体では証明になりません。開発者ツールの Network を開き、この実験だけに存在するカナリア文字列で検索してください。リクエスト行、本文、分析送信に平文、パスフレーズ、ハッシュ記号の後ろの鍵が出てはいけません。AES-256-GCM は端末の Web Crypto で計算し終えてから、暗号文だけを出してよい。

標語は確かめられない。トラフィックは確かめられる

「オンライン暗号化」ページの安全性を、一文で判断する人は多いです。ローカル計算、ゼロアップロード、エンドツーエンド。こうした文はどのサイトにも置けます。ファイルをサーバーへ POST して代行暗号化するサイトにも置けます。証拠ではありません。

その場で見えるのは、このタブがどのリクエストを出したかです。開発者ツールの Network パネルは、メソッド、アドレス、クエリ、本文、一部のアクセス統計を並べます。いま選んだファイル名、パスフレーズ、自分だけが知る「カナリア」平文がそこに出たら、いわゆるローカル暗号化は成立していません。

逆に、Network に平文がないことは、今回の操作がそれらの欄を業務データとして出さなかった、という範囲に限ります。メモリに平文がないこと、拡張機能がクリップボードを読んでいないこと、次の更新でも同じ動きであることは証明できません。確かめる価値は、検証できない宣伝を、繰り返せる観察に落とすことにあります。

「ローカル」が指す計算の層

「ブラウザローカル」は「このドメインが安全そう」という意味ではありません。「暗号化と復号が、いま見ているこのタブで起きる」という意味です。AES-256-GCM の正しい経路は、たいてい Web Crypto API です。鍵導出、暗号化、認証タグはブラウザの暗号インターフェースで完了し、原文を遠隔 API に渡して代算しません。

ファイル暗号化の典型はこうです。ファイル選択で端末のファイルを選び、スクリプトがメモリ上のバイナリ塊として読み、塊ごとに暗号化し、ブラウザに暗号文をダウンロードさせます。下りてきた .lock.enc は結果ファイルであり、アップロードの受領証ではありません。単一ファイル上限が 5 GB と書いてあっても、それは端末のストリーム処理能力であり、サーバーが 5 GB の原文を受け取ったという意味ではありません。

「業務アップロード」と「ページ自身が出すリクエスト」も分けてください。開いてすぐ使えるツールサイトでも、スタイルとスクリプトは読み込み、本文を含まないアクセス統計を送ることがあります。それらの存在だけでは「ファイルがアップロードされた」とは言えません。ただし統計リクエストの query や body に、いま入力したパスフレーズや入力したパスワードが出たら、話は別です。

計算の境界を確かめられる文にした方が、形容詞より役立ちます。パスワード生成、パスワード強度チェック、UTM削除・マスキング、ファイルの暗号化と復号の平文と鍵は、初期状態ではブラウザを出ません。ワンタイムリンクは暗号文の出域だけを許し、復号鍵は URL の # フラグメントに置きます。MakePwd はこの境界でツールを実装し、すべて開いてすぐ使え、アカウントはありません。約束は約束のままです。次に Network で検査項目に落とします。

本物の鍵、身分証、未マスクの表で実験しないでください。捨てられる小さなファイルを用意し、パスフレーズは一度きりの長い文にしてください。確かめるのはトラフィックであり、プライバシーをもう一度晒すことではありません。

Network で繰り返せる検査をする

まず、本物の業務には出ない印を用意します。ファイル名は canary-local-2026.xlsx、パスフレーズはランダムな長い文、本文にはこの実験だけに存在する一文を書きます。カナリアの役割は検索です。Network のフィルタに貼り付け、当たれば失敗です。

開発者ツールを開き、Network に切り替え、Preserve log を入れ、XHR / Fetch で絞ります。「成功したリクエスト」だけを見ないでください。キャンセルや 4xx でも、すでに平文を載せていることがあります。

それから一連の操作を完走します。ファイルを選び、パスフレーズを入れ、暗号化または生成を押します。終わってもパネルは閉じず、次の三箇所を見てください。

  1. フィルタにカナリア文字列を貼り、赤いヒットがないかを先に見てください。当たったらそこで止め、そのリクエストを読みます。「ローカルっぽい」という感覚で先に進む必要はありません。
  2. ヒットがなければ、XHR / Fetch を一件ずつ開き、リクエスト行、クエリ、本文を照合します。静的リソース、フォント、スクリプトは無視して構いません。
  3. アクセス解析のパスは別に絞り、query と body を開きます。ページタイトルとパスは出てよい。いま入力したパスフレーズ、入力したパスワード、処理前の原文、ファイル内容は出てはいけません。

リクエスト行を見る

完全な URL の path と ? の後ろのクエリは、一字ずつ見る価値があります。id のような位置指定フィールドは出てよい。ファイル名、パスフレーズ、入力したパスワード、# の後ろの鍵は出てはいけません。アドレスバー全体とリクエスト行を比べてください。ハッシュ記号の後ろがリクエスト行に入っていたら、実装が fragment を query として扱ったか、スクリプトが読んでリクエストに書いたかのどちらかです。

リクエスト本文を見る

POST / PUT の payload が二箇所目です。ファイル暗号化が端末で完了すると言うなら、本文に元ファイルのバイナリもパスフレーズもあってはなりません。ワンタイムリンクには暗号文フィールドがあってよく、それは想定どおりの出域データです。ただし、いま入力した原文には見えないことを確認してください。パスワード強度チェックページが入力したパスワードを POST したら、目的が「漏洩照会」でも「強度計算」でも、すでに端末を出ています。

分析送信は別に見る

アクセス解析は見落としやすいです。主インターフェースがきれいで、送信だけが入力欄の全文を載せていたら、今回の操作は「平文がブラウザに残った」とは言えません。解析パスを絞るとき、「分析スクリプトは無害」と決めつけないでください。別種の出域リクエストであり、検査方法は業務インターフェースと同じです。

Preserve log を入れてください。暗号化のあとページ遷移や再読み込みがあると、未チェックだと平文を載せた最初のリクエストが消され、「パネルは空だ」という偽の結果になります。

クエスチョンは HTTP に入る。ハッシュは通常入らない

URL には、よく混同される二段があります。クエスチョンの後ろのクエリは HTTP リクエスト行に入り、サーバー、リバースプロキシ、アクセスログから見えます。ハッシュ記号の後ろのフラグメントは、初期状態ではブラウザが端末に残し、このページのスクリプトが読むためのもので、そのドキュメントリクエストには付きません。

そのため、一度きりの暗号文リンクが鍵を # に置くなら、受け手が s.html?id=...#鍵 を開いたとき、設計上サーバーが見るのは id だけで、鍵は見えません。追加の暗号プロトコルではなく、ブラウザの fragment の既定動作です。境界もあります。完全なアドレスをチケット、グループチャット、ハッシュを落とす遷移ページに貼ると、鍵は「HTTP に入らない」から「他人の画面とログに出る」へ移ります。

確かめ方も同じだけ具体的です。テスト用のワンタイムリンクを作り、作成リクエストの body が暗号文だけかを見ます。閲覧ページを開いたとき、ドキュメントリクエストと後続インターフェースの URL に id だけがあるかを見ます。アドレスバーの # の後ろは、これらのリクエストに出てはいけません。閲覧ページは受け手に公開で、ログインは不要です。

どこを見るか HTTP に入るか 合格の見方
ページの標語 関与しない 証拠にはしない。対照用だけ
リクエスト行 / query 入る カナリアなし、パスフレーズなし、fragment 鍵なし
POST body 入る 原文なし。ワンタイムリンクは暗号文のみ可
URL の # フラグメント 通常入らない アドレスバーにはあり、リクエスト行にはない
アクセス解析 実装次第 入力欄の原文なし

証明できること、できないこと

この検査が支えられる結論は狭いです。その範囲を書いた方が、無理に広げるより役立ちます。

支えられること:使っているこのブラウザ、この版、この操作では、平文、パスフレーズ、fragment 鍵は、観察できた HTTP 業務データや分析原文としてタブを出ていません。

支えられないこと:他のタブや拡張がクリップボードを読んでいない、ダウンロードフォルダが安全、相手が復号後にスクリーンショットしない、パスワード強度チェックがインターネット全体の漏洩庫を覆っている。検査が端末のエントロピーと公開の弱いパスワード上位リストだけなら、答えられるのは「よくある弱いパスワードに見えるか」であり、「ある漏洩に一度も出ていない」ではありません。インターネット全体の HIBP 照会ではありません。リストの範囲の書き方と、行数をその場で数える手順は、端末のよく使われるパスワードリストが証明できること、全件漏洩照会ではない理由にあります。

浸透テストだとも思わないでください。WebSocket も Service Worker キャッシュも見ておらず、難読化スクリプトも逆組み立てしていません。目標は同僚にこう説明できることです。Network を開き、カナリアで探し、リクエスト行と body はきれいだった。それは「公式がアップロードしないと言っている」を転送するより、工学の話に近いです。

同じ手順を、開いてすぐ使えるツールに当てる

計算の境界がはっきり書いたページで練習するなら、MakePwd のファイル暗号化から始めてください。開いてすぐ使え、登録は不要です。本物のプライバシーを含まない小さなファイルを選び、パスフレーズはカナリアにし、暗号化して .lock をダウンロードします。同時に Network を見てください。静的リソースと、あるならアクセス解析は見えてよく、元ファイルやパスフレーズが業務フィールドとして見えてはなりません。サイトの説明どおり、アルゴリズムは AES-256-GCM、Web Crypto で計算し、単一ファイルは 5 GB までです。

ワンタイムリンクは二番目の練習に向きます。害のないテスト文を作り、出域が暗号文であることを確認します。閲覧ページは受け手に公開で、リンクの形は s.html?id={id}#{key} です。パスワード強度チェックは「入力欄の内容が解析に入るか」の練習です。入力したパスワードは製品説明どおりアップロードせず、照合は端末のリストで行います。

これらの練習の目的は、あるサイトが「絶対安全」だと証明することではありません。同じ確認手順に慣れることです。ローカル暗号化を謳うどのページでも、手順は変わりません。カナリア、Preserve log、リクエスト行、本文、解析送信。

次に確かめるとき覚えておく三つのこと

第一に、トラフィックを見て、標語を見ない。第二に、暗号文の出域は受け入れてよく、鍵と原文は不可。第三に、ブラウザ、版、機能を変えたら、カナリア検索をもう一度行う。繰り返せる観察だけが、自分たちの安全説明に書く値打ちがあります。

「なぜ鍵をハッシュ記号の後ろに置けるのか」を続けて問うなら、URLのハッシュ記号の後ろに鍵を置ける理由と、その保護が効かなくなるときを読んでください。本稿は「平文がこのタブを出たか」を、その場で終えられる検査に落とすだけです。