ナレッジベース
保存時の暗号化
メッセージのあらゆるフィールド(本文、件名、アドレス、添付ファイルの実体)を書き込む前に封をするため、データベースの複製はメールではなく暗号文になる。
未提供
現時点でこの方式で封をされているのは、利用者が預けた認証情報だけである。本文、件名、添付ファイルは届いたまま保存されており、これらを封じるためのエンベロープは実装済みだが、意図的にどこにも接続されていない。
詳細
- 未提供である。書き込み前に封をされているものは1つだけで、それ以外はない。Webhook の署名シークレットである。これは専用の導出鍵で封をされているため、あるテーブルから持ち出した暗号文を別のものとして開くことはできない。コードベースの中で何かが封をされているのはここだけである。本文、件名、連絡先、メモ、カレンダーの予定、添付ファイルのいずれもここを通らない。
- これは前後の2つの主張とは別のものであり、違いは鍵を誰が持つかにある。エンドツーエンド暗号化とは、鍵が利用者のものであり、メールはここでは読めないということである。保存時の暗号化とは、このサーバーが導出した鍵でメールがストレージへ入る途中に封をされるということであり、データベースのダンプ、流出したバックアップ、実行されるべきでなかったクエリはいずれも暗号文になる一方、サーバー自身はスレッド化、検索、要約のためにそれを開ける。前者は当社から利用者を守る。後者はそれ以外のすべてから守るものであり、他社で繰り返し起きているのはこちらである。
- 現時点で事実であることは、推測に委ねず率直に述べておく価値がある。メールはディスクを自ら暗号化するインフラ上に保存されているが、その上に当社独自の層はなく、鍵は当社が保持している。したがってサーバーは保存している内容を読むことができ、メールを検索・要約する機能はまさにそれを行っている。プライバシーのページは作成当初からこの表現でそう述べており、これが提供されるまでそう述べ続ける。
- 「あらゆるフィールド」とは本文だけを指すのではない。件名、送信者と宛先の一覧、一覧表示に描画される抜粋は、通常のインデックス付き列に置かれている。メッセージから生成した要約、スレッドに付けたメモ、連絡先の名前、カレンダーの件名と場所、すべてのファイルの名前と種類も同様である。件名が平文のままで「暗号化済み」と表示するカードは、この製品が他のどこでも描かないと決めている鍵アイコンそのものになってしまう。
- 未解決だったのはそのコストであり、検索に関してはいま、議論ではなく数値が出ている。現在の検索は、各スレッドの最新メッセージの先頭4,000文字をプレーンテキストとして保持し、それに対してクエリを実行するものである。封をすると、これは既に鍵を保持しているメールボックスストア内での復号と走査になり、1行ずつではなくまとまった塊で処理される。合成コーパスでは、5万件の会話に対しておよそ100〜400ミリ秒であり、20万件を超えるあたりからは結果を一度にではなく順次返す必要がある。これは実際のメールボックスではなく、開発機で生成したメールを対象に測定したものなので、コストの目安であって個々の環境についての約束ではない。したがって語の断片での一致は現在とまったく同じように機能し、後から持ち出される恐れのある単語ハッシュのインデックスをディスクに書く必要もない。要約機能、フィッシング判定の本文パス、AI 作成の判定、語に一致するルールは、いずれも同じテキストを読み、それぞれが同じ方法でそれを開く。これがこの主張の正直な姿である。データベースの複製に対しては封をされているが、サーバーに対して封をされているわけではない。
- 取り返しのつかないものに封をする前に、エンベロープは自身のバージョンと鍵 id を持っている必要がある。現在、導出鍵はすべて1つのシークレットにぶら下がっており、これをローテーションすると Webhook の署名シークレットが失われる。本文を同じ方法で封じた後にローテーションすれば、失われるのはメールである。この部分は実装済みだが、これで封をされたものはまだ何もない。ここで作られるエンベロープはすべて、自身のバージョンと、それを作った鍵の id を持ち、開こうとする前に読み取れる。さらに、自身が属する行そのものに結び付けられる。ある行から持ち出して別の行に入れた値は開かず、不正な鍵のときのような失敗ではなく、移動されたことが示される。まだ何もこれを呼び出しておらず、先に作っておくことにこそ意味がある。形式が約束であり、1フィールドずつ採用していく部分は後戻りできるままである。
- 何に封をするかは一文で決まる。まだ誰も考えていない列にも適用できるようにするためである。人が書いた、あるいは選んだものはすべて封をし、機械が選んだものはそのままにする。件名、本文、スレッドのメモ、連絡先の名前、カレンダーの件名、ファイル名、自分で入力したルールは、いずれも利用者に由来する。メッセージ id、キューの状態、再試行回数、行の id は、ここで生成されたものであり、封をしても得るものはなく、それらを読むすべてのクエリに負担をかけるだけである。この上に例外が2つある。すでに不可逆な値、たとえばハッシュやトークンのダイジェストは、さらに封をしても安全にはならない。意図的に公開されている値は読める状態のままにする。封をすれば、それが存在する唯一の目的である公開ができなくなるからである。
- この規則のもとで読める状態に留まるものが3つある。いずれも手を抜いた箇所ではなく、メールボックスの土台になっているものである。1つはタイムスタンプで、並べ替えのキーであり、ページ送りのカーソルでもある。日付で並べられないメールボックスはメールボックスではない。2つ目はドメインで、これを読むクエリこそ、受信メッセージが誰のものかを、まだ誰もサインインしておらず鍵も手元にない段階で突き止める手段である。3つ目は公開鍵で、送信者がそれを参照するからである。いずれもアカウントの外形について何かを示すが、どれもメールの中身ではない。
- サーバーが導出した鍵で封をすることが第一段階であり、いま作っているのはこれである。第二段階、すなわちメールの到着時に利用者の鍵で封をし、ここにあるどの鍵でも開けないようにすることは、より大きな変更であり、別の製品と言ってよい。本文は検索と AI 機能から恒久的に外れ、鍵の管理と復元フレーズが利用者と自分のメールとの間に入ることになる。これはスイッチを切り替えるようなものではなく、慎重に下すべき選択である。このカードは両者を曖昧にせず、どちらが提供されたのかを明示する。