エンドツーエンド暗号化

ウェブの大半は、すでにこれとは違う二つの方法で暗号化しています。通信中の暗号化（TLS、鍵のマーク）は、デバイスとサーバーの間のデータを守りますが、サーバーはそれを読みます。保存時の暗号化はディスクを守りますが、ディスクを持つ会社が鍵も持っているのが普通です。エンドツーエンド暗号化は、鍵を会社の手から外へ出します。サーバーへの侵入、運営者への裁判所の命令、興味本位でのぞく従業員があっても、得られるのは意味のないバイト列だけです。メッセージアプリがこの考え方をなじみ深いものにしました。メッセージは一台の電話で封をされ、別の電話で開かれるので、間を運ぶ会社でさえ、中身はわからず、何かが送られたことだけがわかります。Signal プロトコルのような公開された設計は、この方法が友人同士から大きなグループにまで拡張できることを示しています。

実際には、デバイスが鍵を作り、送る前に各項目を暗号化するのに使い、あなたが承認したデバイスにだけ鍵を渡します。難しいのは、標準的な暗号方式（AES-256-GCM が広く使われています）ではなく、鍵です。新しいデバイスがどう鍵を受け取るか、すべてを失ったときにどうなるかです。実際のエンドツーエンドの仕組みは、パスキー、リカバリーキー、すでに信頼されたデバイスで答え、トレードオフを受け入れます。他の誰もあなたのデータを開けないので、他の誰も救出できないのです。鍵のかかった箱に入れた手紙にたとえられます。配達員は道中ずっと箱を扱いますが、対応する鍵を持つ人だけが中身を読めます。

限界も知っておきましょう。データをサーバーから守りますが、侵害されたデバイス、ロックの解除された盗難スマートフォン、マルウェアからは守りません。そして、AI チャットは、モデルまで完全にエンドツーエンドにはできません。モデルは答えるためにあなたのテキストを読む必要があるからです。そのため、この言葉は、保存、同期、バックアップ、共有には当てはまりますが、モデルとのリアルタイムのやり取りには当てはまりません。見分ける簡単な方法は、誰が鍵を持っているかを確かめることです。答えが運営者なら、サービスは暗号化されていてもエンドツーエンドではなく、運営者が開示を強制されたり、侵入を受けたりする可能性があります。

初めて使うとき、ブラウザはエクスポート不可の AES-256-GCM の鍵を作ります。ページはそれで暗号化と復号ができますが、どのスクリプトもバイト列として読めません。当社のスクリプトでさえ読めません。会話、画像、キャラクター、記憶は、ブラウザのデータベースに書かれる前に、この鍵で暗号化されます。設定で同期をオンにすると、各項目は、当社のサーバーが決して持たないデータ鍵のもとで、ブラウザの中で暗号化され、その ID も中身を推測できない値に置き換えられます。その鍵はあなたのパスキーとリカバリーキーで暗号化して保護され、承認された各デバイス向けに封をされ、すべての同期リクエストは承認されたデバイスによる署名が必要です。パスキー、リカバリーキー、あるいは別の承認されたデバイスがなければ、当社の側のコピーは二度と開けません。

共有リンクとバックアップも暗号化されており、バックアップはあなたのパスフレーズで暗号化されます。エンドツーエンドではない部分は、回答そのものです。メッセージは当社のサーバーを通ってモデルへ行き、戻ってきますが、透明性のページは、それがデータベースにもログにも書かれないと述べています。当社が封をされた項目だけを保存する理由も、これで説明できます。データベースが漏れても、見えるのは意味のないバイト列と、切り上げられたサイズ、タイムスタンプだけで、あなたが書いた言葉は一つもありません。