Signalの電話番号なし登録、電話認証をゼロ知識証明に置き換え
Signalの電話番号なし登録は、長年にわたる必須の電話認証を経て、ユーザーからの長年の要望から実際に動作するAndroidコードへと移行した。最近のコミットでは、電話番号なしのアカウント作成、ログイン、決済処理、復旧、エンドツーエンドテストが追加されている。このコードではゼロ知識クレデンシャルも使われており、登録時に基となる購入記録を開示せず、認可を受けていることを証明できる。
この組み合わせは重要だ。電話番号を廃止すると、悪用を防ぐという難しい問題が生じる。電話番号が実在の本人性を保証したことはないが、使い捨てアカウントを作る人にとって、番号の取得は一定の障壁となる。Signalは、この不完全な障壁を有料クレデンシャルに置き換えつつ、支払いと作成されるアカウントを切り離す準備を進めているようだ。
これは単なるプライバシー設定ではない。Signalは2024年にユーザー名を導入したが、登録には依然として電話番号が必要だった。SimpleXのようなサービスは、識別子なしの通信を設計の中核に据えている。Signalは現在、主流の暗号化メッセンジャーが、購入を永続的な追跡手段にせずに電話番号を廃止できるかどうかを試している。
Signalの電話番号なし登録、Androidコードに登場
Signalは一般公開を発表していないが、Androidリポジトリには孤立した実験ではなく、連携した電話番号なし登録フローが示されている。
2026年9月2日、Signalの開発者は「電話番号なしアカウント」の登録機能を公開Androidリポジトリにコミットした。このコミットでは49ファイルが変更され、871行が追加、359行が削除された。対象は登録画面、アカウント状態、ネットワークリクエスト、復旧、テスト、ユーザー名作成にまたがる。
コード変更により、登録システムは電話番号を任意のものとして扱えるようになる。また、主端末に電話番号識別子（内部的にはPNIとして知られる）がないアカウントをアプリケーションが認識できるようにもなる。この区別は、最初の登録画面を超えた範囲に及ぶ。
Signalのアプリケーションは従来、主アカウントに国際電話番号表記であるE.164形式の電話番号があることを前提としていた。電話番号なし対応では、登録、復元、連絡先検索、アカウント状態が番号に依存するあらゆる箇所で、こうした前提を見直す必要がある。
同じ9月2日のコミット群では、電話番号なしアカウントに適用されない設定も非表示にしている。これには、電話番号の発見可能性に関する設定や、一部のPINリマインダーが含まれる。別の変更では、電話番号なし向けの特別な国コード設定と、既存の電話番号なしアカウントに対するログイン対応が追加された。
別のコミットでは、Signalのzkgroup暗号ライブラリから新しいクレデンシャルが導入された。このライブラリは、プライバシーを保護するクレデンシャルとグループ操作を支える。登録クライアントは、電話番号を提出せずにアカウントを作成する際、このようなクレデンシャルを提示できる。
Signalは9月9日、この作業に決済処理と電話番号なしアカウントに関する追加修正を加えた。追加内容は、バックアップのオンボーディング、アカウント復元、連絡先検索、マルチデバイス同期、登録ロックのエラーをカバーする。Signalはさらに、電話番号なしフローを対象とする619行の「登録テスト」も追加した。
この広がりは重要である。試作版であれば、新しい登録画面を表示する段階で終わるかもしれない。対してこれらのコミットは、IDシステムの変更がユーザーに届くのをしばしば妨げる、目立たない依存関係にも対処している。
リポジトリによれば、この機能は依然として内部ビルド内で制限されている。公開版Androidの利用者は、コードがマージされたことを即時提供と解釈すべきではない。Signalは、提供開始日、対応国の一覧、支払い方針、最終的なユーザー向けドキュメントを公表していない。
したがって、この証拠が支持する結論は限定的だ。Signalは、支払いとプライバシーの仕組みを含む電話番号なしアカウントを積極的に実装・テストしている。ただし、Signalの電話番号なし登録が一般機能になる時期は、まだ示されていない。
この区別は、既存ユーザーにとって特に重要である。公開されているコードは電話番号なしアカウントを作成・復元するものだが、すでに登録済みのユーザーがひも付けた番号を削除できるとは明確に約束していない。コミュニティの参加者が既存アカウントを解除できるか尋ねたところ、別の貢献者は、利用可能な変更からはその選択肢を確認できないと述べた。
そのため初期リリースでは、既存アカウントを移行せず、新しい電話番号なしアカウントだけをサポートする可能性がある。また、プラットフォーム、地域、テスト対象グループによって機能を制限する可能性もある。Signalが設計を公表するまで、これらの点は未確定のままだ。
Signalが電話認証に代わる仕組みを必要とする理由
電話番号をなくすことは、Signalが自動登録や使い捨てアカウントの悪用を抑えるために利用してきた、希少なリソースをなくすことでもある。
メッセージングシステムにおいて、電話番号はいくつもの役割を果たす。ユーザーが連絡先を見つける助けとなり、身近な復旧経路を提供し、人々がすでに理解しているアカウント識別子を作る。また、攻撃者が数百、数千件の登録を必要とする場合にはコストも生じる。
こうした利点があっても、電話番号が初めからプライベートあるいは安全であることにはならない。番号はしばしば、法的な身元、請求記録、雇用主、位置履歴と結び付く。再割り当て、契約解除、SIMスワップ攻撃によって失われることもある。
Signalは2024年にユーザー名と新しいプライバシー管理機能を導入し、対人関係での露出を減らした。公式の「ユーザー名設計」では、番号を共有せずに会話を始められる。正確なユーザー名が必要であり、Signalは検索可能な公開ディレクトリを提供していない。
しかし、ユーザー名が変えたのは登録ではなく、発見の仕組みだった。Signalの現行サポート文書には、サービスが既存の電話番号を利用すると依然として記載されている。通常のアカウント作成では、その番号でSMSメッセージまたは電話を受信しなければならない。
この隔たりは、プライバシーを重視するユーザーを長年にわたり悩ませてきた。ジャーナリストは、個人番号を公開せずにSignalのユーザー名を掲載したいかもしれない。主催者は、別の携帯回線を契約せずに独立したIDを必要とするかもしれない。タブレットの所有者は、利用可能な番号をまったく持っていない場合もある。
電話記録に雇用主、通信事業者、政府がアクセスできる人々にとっては、リスクがさらに大きい。エンドツーエンド暗号化は、通信中のメッセージ内容を保護する。しかし、電話番号を取得・維持する間に作られる外部記録をすべて消去するわけではない。
とはいえ、番号要件を単純に削除すれば、アカウント作成は安価で反復可能になる。スパマーはブロックされた後にユーザー名を次々と変えられる。詐欺事業者はアカウントの在庫を再構築でき、自動システムはメッセージリクエストやインフラを圧迫しかねない。
Signalはすでに、未承諾の送信者ができることを制限しているが、コンテンツの暗号化はサーバー側のモデレーションを制約する。このサービスは、非暗号化プラットフォームのように、すべての会話を調べて不正なテキストを分類することはできない。そのため、登録時の摩擦はより重要になる。
コミュニティの参加者は、別の移行上の問題も指摘した。ユーザーが1つの番号で登録し、すぐにその番号を切り離せるなら、1つの番号から多数の無料アカウントを作れてしまう。クールダウン期間はこの循環を遅らせるが、執拗な攻撃者は待機するか、活動を分散できる。
支払い要件は、別の希少なリソースを提供する。各登録者に、有効な電話番号ではなく有効な購入を求める。料金は、Signalが電話番号にひも付く身元を保持せずに、大量作成を抑止できる可能性がある。
このアプローチは、圧力をなくすのではなく移すものだ。決済システムには、独自の記録、地理的制約、利用上の障壁がある。対応する支払い方法を持たない人にとっては、電話番号なし登録のほうがSMS認証より利用しにくいかもしれない。
ストア運営者も、購入が行われたことを把握できる。Google Play、金融仲介業者、または別の決済プロバイダーは、その取引を既存アカウントと関連付ける可能性がある。中心となるプライバシー上の問いは、Signalが、最終的なメッセージングアカウントのどれが購入したかを知らずに、その購入を利用できるかどうかだ。
そこでゼロ知識クレデンシャルが設計に加わる。本来なら同時に明らかになる2つの事実、すなわち有効な購入が存在することと、この特定のSignalアカウントがそれを行ったことを、分離する狙いがある。
ゼロ知識クレデンシャルが決済との結び付きを断つ仕組み
提案されている仕組みでは、新しいアカウントと支払いを直接結び付ける再利用可能な記録を避けながら、Signalが利用資格を確認できる。
ゼロ知識証明では、ある主張の背後にある秘密を明かさずに、その主張が真であることを一方の当事者が示せる。ここで関連する主張は、ユーザーの氏名や金融上の身元ではない。登録者が認可済みのレシートクレデンシャルを保有していることである。
公開されているAndroidコードは、ランダム化されたレシートリクエストを作成し、それを決済関連の登録エンドポイント経由で送信する。購入が確認されると、クライアントはクレデンシャルレスポンスを受け取る。次にクライアントはそのレスポンスを検証し、アカウント登録用のクレデンシャル提示を構築する。
このプロセスでは、ブラインドクレデンシャルの概念が使われる。ブラインドクレデンシャルでは、発行者は隠された値を、その後に識別できる形で知ることなく認可できる。ユーザーは後に、その保有を証明しながら、発行と利用の間の関連付け可能性を抑えられる。
実用面では、Signalの決済サービスは購入トークンを検証し、暗号学的なレシートを発行できる。登録サービスは後にそのレシート提示を検証できる。適切に設計されたプロトコルなら、サーバーは提示を以前の発行記録と照合できない。
9月のコードでは、この分離が複数の別個のオブジェクトとして示されている。これには、レシートシリアル、リクエストコンテキスト、クレデンシャルレスポンス、クレデンシャル、クレデンシャル提示が含まれる。クライアントがリクエストコンテキストを作成する際に、ランダム性が導入される。
決済実装では、購入をサブスクリプションではなく再利用可能な商品カテゴリとしても扱っている。公開されている「決済フロー」では、同じ1回限りのアイテムを繰り返し購入できる。次の請求を始める前に、未消費の購入がないか確認する。
正常に利用された後、アプリは購入トークンを消費できる。これにより、同じトークンで繰り返し登録を認可させることを防ぎながら、ストアアイテムを再び購入可能にする。この詳細は、スパム対策の目的とクレデンシャル設計を結び付けている。
したがって、このシステムには同時に2つの保護が必要となる。クレデンシャルは登録者を守るために十分に関連付け不能であるべきであり、同時に利用規則は重複利用を防がなければならない。どちらか一方でも弱ければ、この機能は損なわれる。
決済と登録の記録が直接結合されるなら、電話番号なしの登録は通信識別子を金融識別子へ交換するだけになる。それは利便性をもたらすかもしれないが、この機能が示唆するプライバシー向上にはならない。
クレデンシャルをコピーまたはリプレイできるなら、攻撃者は一度購入するだけで多数のアカウントを作成できる。そうなれば、Signalは支払いを導入する動機となった悪用耐性を失う。コード内のレシートシリアル、検証手順、消費プロセスは、その結果を防ぐよう設計されているように見える。
Signalはすでに、関連する暗号技術を別の領域で活用している。プライベートグループシステムでは匿名認証情報を用い、通常の運用ではサーバーがグループメンバーシップを把握せずにグループ操作を実施できるようにしている。寄付バッジにもレシート認証情報が使われ、支払いとプロフィールバッジを切り分けている。
こうした実績は実装上の新規性を下げるが、展開リスクをなくすものではない。レビュー済みのプリミティブを再利用することは、新しいものを発明するより安全だ。それでも登録には、新たなエンドポイント、状態遷移、ストアへの依存関係、障害ケースが加わる。
公開されているソースコードだけでは、本番サーバーが何を保持しているかは証明できない。クライアント側の暗号技術は、有効なプロトコルが明らかにする情報を制約できる。研究者が主張全体を評価するには、最終的なサーバー実装、プロトコル仕様、保持ポリシー、デプロイ時の挙動がなお必要となる。
Signalによる過去の「private discovery」への取り組みは、同じ思想を示している。可能な限り、クライアントはサーバーに平文のソーシャルグラフを委ねるべきではない。電話番号不要の登録は、その原則をアカウント作成へと拡張するものだ。
この仕組みが保護するのは特定の関係性であり、あらゆる種類のメタデータではない。ストアは、誰かがSignal関連の商品を購入したことを依然として把握できる。通常のサービスアーキテクチャのもとで、Signalもネットワークリクエスト、タイミング、デバイス情報、その後のアカウント活動を観測できる。
したがって、ユーザーは「ゼロ知識」を正確に理解すべきだ。これは、定義されたプロトコル内で証明が何を秘匿するかを表す。すべての参加者が、あらゆる出来事について何も知り得ないという意味ではない。
高リスクのユーザーにとっては、とりわけタイミングが重要であり続ける。認証情報を購入し、数秒後に引き換えれば、別々のシステム間で相関付けが可能になるおそれがある。ネットワークの分離、バッチ処理、引き換えの遅延、その他の運用上の選択によって、この露出を減らせる可能性がある。
Signalは、最終的なワークフローにこうした対策を導入するかどうかを説明していない。また、サーバーがどの支払いメタデータを受け取り、保持するのかも明らかにしていない。こうした欠落は、暗号技術に付けられた安心感のあるラベル以上に重要だ。
電話番号不要の登録がSignalの競争上の位置付けを変える
Signalは、会話内で電話番号を隠す段階から、アカウント作成時に電話番号を不要にする段階へ進もうとしている。この領域では、プライバシー重視の競合各社がすでに差別化を図っている。
WhatsAppはメッセージ暗号化にSignal Protocolも利用しているが、アカウント登録は依然として電話番号を中心としている。Telegramも標準的な登録時には電話番号を使い、発見のためにユーザー名を提供している。こうした設計は容易な連絡先照合を維持する一方、電話番号ベースのIDがもたらすプライバシーコストを引き継ぐ。
Signalも歴史的には似た立場にあった。メッセージ暗号化は高く評価されてきたものの、批評家は必須の電話番号認証を基本的なIDの結び付きとして指摘できた。ユーザー名は連絡先間での露出を減らしたが、登録時のその結び付きをなくしたわけではない。
電話番号不要のSignal登録は、代替識別子を中心に設計されたサービスとの差を縮めることになる。たとえばSimpleXは、そのネットワークではユーザーにグローバル識別子を割り当てないとしている。連絡先は、共通の電話番号やユーザー名ではなく、招待リンクとペアごとのアドレスを通じてつながる。
Sessionは電話番号ではなくアカウント識別子を使い、メッセージルーティングを分散型ネットワーク全体に配分している。Matrixでは独立運営のサーバー上にアカウントを作成でき、通常は選択したホームサーバーに紐付くユーザー名を用いる。それぞれの方式は、発見、モデレーション、メタデータ、使いやすさにおいて異なるトレードオフを伴う。
Signalはこれらのシステムのアーキテクチャを採用するわけではない。厳格に管理されたクライアントとサーバーの関係を持つ、中央運営のサービスであり続ける。電話番号不要化の取り組みが変えるのは登録認証情報であって、連合型運用やインフラガバナンスへのアプローチではない。
この焦点は、Signalが掲げる優先事項に照らして理にかなっている。中央運営により、プロトコルの更新、不正利用対策の展開、クライアント挙動の調整が可能になる。一方で、暗号化によって利用可能なデータを最小化していても、信頼はSignalの実装とポリシーに集中する。
したがって、競争上の変化は「Signalが匿名化する」というほど広範ではない。電話番号不要のアカウントにも、ユーザー名、プロフィール名、デバイス、ネットワークアドレス、連絡先、行動パターンは存在し得る。プライバシーは、それらのシグナルがユーザーの現実世界のIDとどう結び付くかに左右される。
変わるのは、参加前に電話の接続先を提示するというデフォルト要件だ。これは重要である。電話番号はとりわけ永続性が高く、相互運用可能な識別子だからだ。メッセージング、銀行、広告、雇用、政府のシステムをまたいで使われる。
有料の認証情報は異なる性質を持つ。連絡先が使うアドレスになることなく、経済的な摩擦を課すことができる。暗号学的な分離が機能すれば、購入は登録を認可できる一方で、アカウントに結び付き続けない。
この設計は、使いやすさをめぐる競争も変える。Signalは、よりプライベートな参加経路を提供しながら、親しみやすいユーザー名と洗練された連絡先体験を維持できる。匿名識別子を中心に構築された競合サービスでは、ユーザーに招待リンク、サーバー選択、あるいは馴染みのない復旧モデルを理解するよう求めることが多い。
ただし、Signalのアプローチは、対応するストアや決済手段を利用できない人々を排除する可能性がある。プライバシーツールは、アプリストアが制限された地域を含め、制約のある環境にいるユーザーにも利用されることが多い。決済依存の選択肢には、1つのAndroid課金統合より広いアクセスが必要だ。
現在のコミットではGoogle Playの課金サポートが示されている一方、非Playビルドでは購入不可と報告される可能性がある。これは代替Androidストアや直接配布のアプリケーションパッケージを使うユーザーにとって、直ちに疑問を投げかける。Signalは最終的なクロスプラットフォーム計画を発表していない。
Appleのプラットフォームには独自の実装と審査が必要になる。現在のモバイルクライアントと同じ前提では、デスクトップ端末から主アカウントを作成できない。完全なローンチでは、どの端末と支払いの組み合わせで電話番号不要のIDを作成できるかを決めなければならない。
電話番号認証との比較は地域によっても異なる。SMS配信は一部の国で失敗し得る一方、プリペイド番号が利用しやすい地域もある。ストア課金はあるユーザーには便利でも、別のユーザーには不可能になり得る。
Signalは、電話番号不要の登録を、明確な制限を持つ選択肢として提示する必要がある。これを電話番号の普遍的な代替手段として扱えば、現行コードがサポートする範囲を過大に表現することになる。最も強い設計は、複数の登録経路を維持しつつ、それぞれのプライバシー特性を明確にするものかもしれない。
最も難しい問いは、証明が成功した後に始まる
ゼロ知識認証情報は1つの結び付きを断てるが、復旧、不正利用対策、支払いへのアクセス、メタデータが、システム全体が信頼に値するかを左右する。
最初の難所はアカウント復旧だ。電話番号は、SIMスワップのリスクを生む一方で、ユーザーがIDを取り戻すための外部チャネルを提供する。電話番号不要のアカウントは、秘密情報、端末、バックアップ、その他の認証情報に依存しなければならない。
Android向けの変更には、電話番号不要ログインのパスワードマネージャー対応と、調整されたバックアップ導入フローが含まれる。また、電話番号不要のアカウントでは一部のPIN動作も削除される。これらの詳細は、Signalが復旧用の情報により大きな責任を担わせると想定していることを示唆する。
この移行は、注意深いユーザーのセキュリティを向上させ得る。しかし、認証情報を紛失したり復旧用の秘密情報を保存しなかったりすれば、恒久的にアカウントを失う可能性もある。Signalは、端末が失われた後ではなく、登録前にその結果を説明しなければならない。
コードでは、バックアップと復旧のワークフロー全体で使われる高エントロピーの秘密情報であるアカウントエントロピープールに言及している。パスワードマネージャーは、人間の記憶よりもこうした情報を確実に保存できる。とはいえ、パスワードマネージャーを持たないユーザーには、安全で理解しやすい代替手段が必要となる。
第二の難所は不正利用だ。支払いが大量登録を抑制するのは、そのコストと引き換えルールが攻撃者に意味のある影響を及ぼす場合に限られる。不正業者は盗まれた決済手段、侵害されたストアアカウント、返金スキームを利用できる。
Signalはまた、禁止措置が新しい認証情報とどう関わるかを決めなければならない。ブロックされた行為者が直ちに別の登録を購入できるなら、このシステムは粘り強い不正行為を止めずに摩擦だけを生む。禁止措置を執行するためにSignalが過度の情報を結び付ければ、プライバシーの約束を弱めることになる。
この緊張関係は、暗号技術だけでは解決できない。ゼロ知識証明は、有効な購入が行われたことを示し、単純なリプレイを防止できる。しかし、Signalがどの不正利用シグナルを収集すべきか、サービスがどれほど積極的にそれらを相関付けるべきかは決められない。
決済の利用可能性が第三の懸念を生む。確認できるAndroidの実装は、実装済みの購入経路としてGoogle Playに依存している。コードコメントによれば、Play課金のない端末は利用不可状態を返す。これには、一部のプライバシー重視Android構成や配布チャネルが含まれる。
通信事業者への依存を減らすことを意図した機能が、結果としてアプリストア運営者への依存を高める可能性がある。Googleは最終的なSignalアカウントを知るとは限らないが、自社の顧客がSignalの登録アイテムを購入したことは把握できる。
この違いは重要だが、完全ではない。ユーザーの中には、Signalアカウントを電話番号から切り離すことを主に望む人もいる。Signalの利用を示すストアや金融上の記録を作ることも避けたい人もいる。
Signalは将来的に、代替の決済プロバイダーやバウチャーをサポートする可能性がある。また、ある人が別の人の登録を認可できる譲渡可能な認証情報を設計することもできる。現在のリポジトリはこれらの選択肢を確立していないため、期待ではなく可能性として扱うべきだ。
第四の懸念はメタデータだ。プライバシーを保護する認証情報は数学的にはリンク不可能であっても、運用上の出来事は依然として相関付けられ得る。発行時刻、引き換え時刻、ネットワークアドレス、デバイスフィンガープリント、エラーログは匿名性を狭める可能性がある。
Signalのクライアントはサーバーに開示するデータを減らすよう設計されているが、メタデータなしに動作するネットワークは存在しない。重要なのは完全な不可視性ではない。システムが必要なものだけを収集し、回避可能な結び付きを防ぐかどうかだ。
独立した評価には、プロトコルの説明と明確な脅威モデルが必要となる。Signalは、どの当事者が協力し得ると想定しているのかを特定すべきだ。そのリストには、ストア運営者、決済処理事業者、認証情報発行者、登録サービス、ネットワーク監視者が含まれる。
研究者はまた、1つの組織が複数の役割を管理しているかどうかを評価する必要がある。共同運用下でも、暗号学的分離には価値があり得る。その保証は、正しい構成、鍵管理、ログ記録の挙動、デプロイ境界に左右される。
コミュニティのスレッドはコードの存在を明らかにする助けとなったが、コミュニティの議論は公式の製品発表ではない。設計を確信を持って説明する参加者もいれば、リンク不可能性や決済プライバシーに疑問を呈する参加者もいる。その議論は有効な論点を示すが、決着をつけるものではない。
Androidリポジトリは、実装についてより強い証拠を提供している。それでも、これは開発中のソフトウェアを表すに過ぎない。機能フラグ、インターフェース、テスト、コメントはリリース前に変わり得る一方、サーバーの挙動はクライアントコードから導かれる前提と異なる可能性がある。
Signalは、相当規模のクライアント作業を検証可能な状態にしている点で評価されるべきだ。この可視性により、開発者はレシート認証情報、支払いの境界、電話番号不要アカウントの状態を特定できる。また、マーケティング文言が物語を定義する前に精査することも可能になる。
責任ある結論は条件付きだ。この仕組みは、一度限りの認可を強制しつつ、支払いとアカウントの直接的な結び付きを防ぐよう設計されているように見える。展開されたサービスがその目標を達成するかどうかは、まだ独立して検証されていない。
Signalが電話番号不要アカウントを開始する前に注目すべきこと
この取り組みが信頼できるプライバシー機能になるかどうかは、公開提供、文書化された脅威モデル、幅広い登録手段という3つの兆候で判断できる。
最初の兆候は、パブリックベータ版または安定版の公開だ。現在のAndroidコードでは、電話番号なしの登録は内部ビルドに限定されている。この制限がベータ版に移されれば、Signalが開発環境の外でもこのフローを利用可能だと判断していることを示す。
ベータ版では、実際のオンボーディング手順も明らかになる。支払いが必須か、ユーザー名の作成を省略できるか、どの復旧用情報を保存すべきかをユーザーが確認できる。ストアでの提供状況や国・地域ごとの制限も測定可能になる。
既存アカウントが電話番号を切り離せるかにも注目したい。新規アカウントへの対応だけでは将来のユーザーの登録問題は解決できるが、現在のSignal利用者は過去の電話番号識別子と結び付いたままだ。移行プロセスが用意されれば、この機能の影響は大幅に広がる。
Signalは、切り離しが何を意味するのか説明しなければならない。インターフェースから電話番号を消すことは、関連するすべてのサーバー記録を削除することと同義ではない。ユーザーには、アカウント状態の正確な定義と保持ポリシーが必要だ。
2つ目の兆候は、技術設計の公開である。有用な文書には、認証情報の発行、購入の引き換え、リプレイ防止、復旧、関連メタデータが記載されるべきだ。また、決済プロバイダーとSignalのサービスが何を観測できるのかも明示する必要がある。
正式なセキュリティレビューが実施されれば、この仕組みの信頼性は高まる。zkgroupライブラリはSignal内部ですでに使われているが、電話番号なしの登録は新たなプロトコル構成を生み出す。レビュー担当者は、数学的な仕組みだけでなく、その周辺のアプリケーションフローも検証すべきだ。
最も重要な問題は、リンク可能性である。Signalは、発行者が引き換え済みの認証情報を認識できるか、複数回の提示を相関付けられるか、どのようなタイミング情報が利用可能なまま残るかを定義すべきだ。広範な匿名性の主張よりも、明確な限界の説明の方が信頼できる。
3つ目の兆候は、プラットフォームと決済手段のカバー範囲だ。現在のAndroid実装ではGoogle Playの課金が使われているように見える。直接配布のAndroidビルド、iOSユーザー、あるいは対応していない地域に登録手段がなければ、このプライバシー機能はSignalの全利用者に提供できない。
代替的な認証情報は、その依存度を下げられる。ギフトコード、非営利団体による配布、プロバイダーに依存しない決済の仕組みは、対応ストアのアカウントを持たないユーザーを支援できるかもしれない。こうした経路でも、一度限りの引き換えと大量悪用への耐性を維持しなければならない。
開発者は、サーバーリポジトリやプロトコルライブラリにも注目すべきだ。新しいエンドポイント、認証情報の種類、文書は、どの保証が暗号学的に強制されているかを明らかにする可能性がある。クライアントのインターフェースだけでは、すべての保持に関する疑問には答えられない。
プライバシーに敏感な組織は、オンボーディング方針を変更する前に、こうした詳細を待つべきだ。ジャーナリスト、研究者、主催者、企業は、電話番号の露出低減と併せて、復旧およびアカウント喪失のリスクを理解する必要がある。
プライバシーツールを評価するナレッジワーカーは、こうした設計上の前提をpersonal knowledge baseに記録できる。Signalが文書を公開したり、展開方法を変更したりした際に、持続的な比較の基盤となる。
Signalの電話番号なし登録は、現実的な矛盾に取り組んでいる。このサービスはデータ収集を抑えた登録を望む一方で、使い捨てアカウントによって暗号化ネットワークが圧迫されるのを防がなければならない。有料かつリンク不可能な認証情報は首尾一貫した答えだが、それが機能するかどうかは実装の詳細によって決まる。
次の一手はSignalに委ねられている。機能を公開し、観測可能なメタデータを文書化し、暗号技術の用語で不確実性を隠すことなく復旧方法を説明すべきだ。その際、読者は実務的な問いを1つ投げかけるべきである。各当事者は、必要なことを証明しつつ、その人物へ恒久的にたどり着く経路を得ずに済むのか。
