ファイルがアップロードされていないことを確認する方法
どのサイトも「プライバシーは守られます」と書いてあるけど、実際どうやって確かめればいいの？
正しい前提から始める
宣伝ページに書かれたプライバシーの主張は証拠になりません。鍵のアイコンも、バッジも、プライバシーポリシーの一文も同じです。それらが表しているのは意図であり、知りたいのは実際の挙動です。幸い、挙動は観察できます。どのブラウザにも、ページが何を送信しているかをそのまま見せてくれるツールが備わっていますし、それを読むのに開発者である必要はありません。
このサイトでこれらの確認を試してください。以前使っていたサイトでも試してください。目的は別の主張を信じることではなく、主張を信じる必要そのものをなくすことです。
確認1：ネットワークパネルを見る
- 開発者ツールを開きます。多くのデスクトップブラウザではF12、Ctrl+Shift+I、またはCmd+Option+Iです。
- 「ネットワーク」タブを選び、記録が有効になっていることを確認します。
- ページを再読み込みし、一覧を消去して空のログから始めます。
- ファイルを選び、処理を実行します。
- サイズ順に並べ替えるか、Method列を見てPOSTとPUTのリクエストを探します。
探すのは、ペイロードがファイルのサイズと同じくらいの大きさになっているリクエストと、いま開いているサイト以外のホストへのリクエストです。ローカルで処理するツールなら、自分自身のコードを取得するリクエスト、つまりスクリプト、スタイルシート、WebAssemblyモジュール、場合によってはモデルファイルが並び、処理中は何も出てきません。アップロードするツールなら、ボタンを押した瞬間に数MBを運ぶリクエストが現れます。
確認2：ネットワークを切る
これが最も強力な確認方法で、専門知識はまったく要りません。ページを普通に読み込み、必要なエンジンがキャッシュされるようにツールを一度使ってから、通信を切ります。機内モードにする、Wi-Fiを切る、開発者ツールのオフライン切り替えを使う、どれでも構いません。その状態でファイルを処理してみてください。
完了したなら、処理はあなたのマシン以外のどこでも行われようがありません。議論の余地はありません。失敗したり止まったりしたなら、処理のどこかがサーバーを必要としていたということです。まだキャッシュされていなかったモデルファイルのように正当な理由の場合もありますが、少なくとも、どれが必要だったのかを尋ねるべきだと分かります。
確認3：コンテンツセキュリティポリシーを読む
コンテンツセキュリティポリシーは、サイトが送信しブラウザが強制するヘッダーです。そのconnect-srcディレクティブには、ページが接続を開いてよい宛先が列挙されています。connect-srcがそのサイト自身のオリジンに限定されていれば、ページのコードが何をしようとしても、他所へ何かを送ろうとする試みはブラウザ自身が遮断します。
読むには、「ネットワーク」タブを開き、ドキュメントのリクエスト、通常は一番上の行をクリックして、レスポンスヘッダーのContent-Security-Policyを見てください。外部ホストを含まないconnect-src 'self'が書かれたポリシーは、約束ではなく、ブラウザが強制する実質的な制約です。
それぞれの確認で証明できること
| 確認方法 | 証明できること | カバーできないこと |
|---|---|---|
| ネットワークパネル | そのセッション中にこのページが何を送信したか | 別のコード経路、後日のバージョンのサイト、見るのをやめたあとに送られたリクエスト |
| オフラインでの検証 | 処理そのものがローカルで動いていること | 何かが保留され、再接続後に送信されるかどうか |
| コンテンツセキュリティポリシー | そもそもブラウザが接続を許可する範囲 | そのサイト自身のオリジンを含め、ポリシーが許可している範囲の通信 |
| ソースコードを読む | 配信されているコードの中身 | 手間がかかること。またサイトが変わるたびにやり直しが必要 |
組み合わせれば強力です。個々には抜けがあり、たった1つの確認で決着すると言う人がいれば、それは単純化しすぎです。
ローカル処理ではないことを示すサイン
- 端末の性能と無関係な速さで進むプログレスバー。高速なノートPCでも古いスマートフォンでも、なめらかに同じ速さで進みます。
- 結果が、ブラウザがすでに保持しているファイルとしてではなく、先方のドメイン上のダウンロードURLへのリンクとして渡される。
- ファイルは数時間後にサーバーから削除されます、という案内。この一文は、ファイルがそこにあったという告白です。
- 順番待ちや利用回数の制限。自分のプロセッサに、他人と共有する順番待ちの列はありません。
- ネットワークを切った状態では、最初の小さなファイルだけ処理できて、その後は止まってしまう。
検証の限界
検証で分かるのは、検証した日に検証したバージョンのサイトについてだけです。サイトは明日には変わり得ます。だからこそ最も重要なのは構造的な確認です。制限の強いコンテンツセキュリティポリシーと、実際に成功するオフライン検証は、特定のリリースについての約束ではなく、そのアプリケーションがどう作られているかという性質だからです。
ここに挙げたどの確認でも届かないものが2つあります。ブラウザ拡張機能は、読み込んだファイルも含めてどのページの内容も読み取れますし、それをサイト側で防ぐ手段はありません。OSは、あなたが開くすべてのファイルを見られます。それが問題になるほど機微な文書なら、自分の管理下にあるマシンのオフラインソフトで処理してください。そして、このサイトも含めてウェブサイトはその用途には適さないと考えてください。
この作業に使えるツール
出典
- W3C — Content Security Policy Level 3
- MDN — Content-Security-Policy connect-src
- Chrome DevTools — inspect network activity
- MDN — Firefox Network Monitor