リンクプレビューは、クリックする前にネットワークリクエストを発生させることがあります。ただし、誰がリクエストを送り、リンク先のサイトが何を見られるかは、メッセンジャーの設計によります。チャットに小さな画像があるだけで、送信者と受信者の両方の IP が漏れたとは判断できません。
エンドツーエンド暗号化は、会話の当事者間を流れるメッセージを保護します。ウェブサイトのタイトルや画像の取得は別の経路を通るため、個別に評価する必要があります。
プレビューを作る三つの異なる方法
| 方法 | リンク先のサイトに何が見えるか？ | 重要な問い |
|---|---|---|
| 端末が直接取得する | リクエスト元の接続の IP と、リクエストに付随する情報 | 入力時、送信時、受信時のいつリクエストが発生するか？ |
| 仲介サーバーやプロキシ経由で取得する | 通常はユーザーの直接の IP ではなく、仲介側の IP | 仲介側自身は何を見て、何を保存するか？ |
| 送信者がプレビューを作り、メッセージに入れて送る | カードの表示時、受信者はリンク先に接続しない場合がある | カード内の画像はローカルにあるか、それともウェブから再取得するか？ |
これらの方法は組み合わせることもできます。例えば Signal は、2019 年の技術解説でプレビューへのプロキシ利用を説明しています。この文書は設計の一例です。確認せずにすべてのバージョンやアプリへ一般化すべきではありません。Signal の現行ガイドは、プレビューの生成を無効にする機能と、送信前にカードを削除する方法を説明しています。
IP、リンクの識別子、本人の身元は同じではない
リンク先のサイトは、ネットワーク接続を確立する側の IP を見ます。それは端末、VPN、プロキシかもしれません。IP だけでは通常、個人名や正確な自宅住所はわかりませんが、リクエストの時刻や他のデータと組み合わせると、出来事を関連付けるために使われる可能性があります。
固有の識別子が付いたリンクも、その URL がリクエストされたことを示す場合があります。この観察だけでは、誰が読んだかは証明できません。リクエストは、プレビュー、セキュリティツール、送信者、受信者、あるいは転送されたリンクを受け取った人から生じたかもしれません。
また、IP アドレスは必ずしも HTTP 内のフィールドではなく、ネットワーク通信の一部です。User-Agent などのヘッダーの種類や値は、リクエストするソフトウェアによって異なります。
ページタイトルの取得と、ページ全体の実行は異なる
一部のプレビューは、HTML と画像だけを取得して処理します。それは必ずしも JavaScript の実行やブラウザーでのページ表示を意味しません。一方、プリロードやウェブ環境内でのページ表示は、異なる動作をする可能性があります。
そのため、「サイトにリクエストが送られるか？」と「ページのアクティブコンテンツが実行されるか？」を別々に尋ねてください。一方の答えから、もう一方の答えは決まりません。
機密性の高い会話のための実践的な設定
- プレビューカードが不要なら、アプリの自動生成設定を確認してください。生成後にカードを削除しても、すでに発生したリクエストは取り消せません。
- 見知らぬリンクや、ログイン、復旧、ファイル共有用の個別リンクは、機密データとして扱ってください。試すために公開 URL 解析サービスへ入力しないでください。
- 署名付きリンクのパラメーターを勝手に削除しないでください。アクセスや整合性を損なう可能性があります。可能なら、元の情報源から、そのページの公開された個人向けでない版を入手してください。
- プレビューの無効化を、すべてのネットワーク接続の防止と混同しないでください。リンクを開くこと、外部画像、その他の機能には、それぞれ独自の経路があります。
- 組織で評価する場合は、自分で管理する無害な URL とテスト端末を使い、いつリクエストが発生するかを確認してください。一つのバージョンの結果を、すべての端末に一般化しないでください。
Livara について何が言えるか？
Livara の脅威モデルは、非公開コンテンツの保護範囲と、端末やネットワークの限界を説明しています。この一般的な説明だけから、すべてのバージョンのすべてのプレビューが必ず直接取得される、あるいは必ずプロキシを通るとは結論できません。そのような主張には、機能の文書や、そのバージョンの調査が必要です。
リンクのプライバシーでは、プレビューカードの見た目より、リクエストの経路が重要です。
