標語は確かめられない。トラフィックは確かめられる
「オンライン暗号化」ページの安全性を、一文で判断する人は多いです。ローカル計算、ゼロアップロード、エンドツーエンド。こうした文はどのサイトにも置けます。ファイルをサーバーへ 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 でも、すでに平文を載せていることがあります。
それから一連の操作を完走します。ファイルを選び、パスフレーズを入れ、暗号化または生成を押します。終わってもパネルは閉じず、次の三箇所を見てください。
- フィルタにカナリア文字列を貼り、赤いヒットがないかを先に見てください。当たったらそこで止め、そのリクエストを読みます。「ローカルっぽい」という感覚で先に進む必要はありません。
- ヒットがなければ、XHR / Fetch を一件ずつ開き、リクエスト行、クエリ、本文を照合します。静的リソース、フォント、スクリプトは無視して構いません。
- アクセス解析のパスは別に絞り、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のハッシュ記号の後ろに鍵を置ける理由と、その保護が効かなくなるときを読んでください。本稿は「平文がこのタブを出たか」を、その場で終えられる検査に落とすだけです。