VPNディレクトリが背後のノードを保証できない理由
掲載項目は接続と、それを公開したディレクトリを記述している。収集と保持は運営者に属し、その運営者は別の当事者でありうる。
次のものを一覧に載せるディレクトリ項目は、ホスト名、国、プロトコルの組み合わせ 接続可能性についての証拠であり、反対側のマシンが何を記録するかについての証拠ではない。ここで重要な判断は、一覧を一般に信頼すべきかどうかではない。本当に問うている質問に答えられる立場にあるのはどの当事者か、という点である。
一件の項目の背後にある四つの当事者
どんな約束を読む前にも、役割を切り分けよう。ディレクトリは項目を公開し、ソフトウェアのプロジェクトはプロトコルの実装を提供し、ホスティング事業者はマシンとネットワークを提供し、ノードの運営者はサービスを設定する。四者はそれぞれ別の組織でありうるし、どれも自分の部分についてしか語れない。
この分離は、ある記述が正しくありながら役に立たないことがある理由を説明する。プロトコルが内容を記録しないと文書化する開発者は、リレーで詳細な接続ログを有効にした運営者について何も語っていない。両方の記述は矛盾なく併存しうる。だからこそ、質問は名指しされた当事者に向けなければならない。
自前の端点を運営するサービスもあり、その場合は項目と方針が同じ当事者から出てくる。それはより強い立場だが、ページの形式から推測するのではなく、確認する必要がある。声明を求め、それが項目の指すサービスを名指ししているか確かめよう。
主張に対応する記録を求めよう
収集についての主張には、システム、データの種類、期間を名指しした文書が必要だ。保持についての主張には、数値と範囲が必要だ。独立性についての主張には、誰が何を所有するかの説明が必要で、形容詞では足りない。
| Field in a listing | What it evidences | What it cannot evidence |
|---|---|---|
| Hostname or address | A reachable endpoint existed when the entry was published | Who runs it, or what it stores |
| Protocols offered | Which client configurations should interoperate | Whether logging was disabled on that deployment |
| Country | Where the endpoint claims to be located | Which legal process could reach the operator |
| Availability score | How often the entry answered a probe | Anything about data handling |
ボランティアのプロジェクトはしばしば最も明快な例だ。受け入れるノードに明示的な記録要件を公開しているものもある。その文書はプロジェクトの規則についての一次証拠であり、それを無視した個々の運営者についての証拠にはならない。
監査も同じ論理を別の規模でたどる。特定の配備を特定の期間に調べた報告書は、その範囲の内側では有用だ。同じソフトウェアのあらゆる独立した導入に引き伸ばせば、誰も発行していない保証になってしまう。結論を読む前に範囲の段落を読もう。
事業者のプライバシー声明が自社サービスを対象にしているときは、その事業者が自社システムについて述べた声明として読むべきだ。それを第三者の中継サーバーの説明に流用するのは分類の誤りであり、プロトコルが同一であっても変わらない。
各選択肢で何を買うのかを決めよう
公開ノードは説明責任を代償に、到達性と多様性を買う。あなたに何の義務も負わない運営者は、消えたり、設定を変えたり、通知なしに記録を保持したりでき、あなたの取り得る手段は次に限られる。端点を切り替えること その取引は、ある種の作業には受け入れられるが、そうでない作業もある。
有料サービスは、公開された方針と失うものを持つ相手を買う。技術的な保証を買うわけでも、方針を読む必要がなくなるわけでもないが、保持に関する声明を持つ名の通った組織は、匿名の中継サーバーより評価しやすい。
どちらの場合にも耐える判断の原則は、証拠をリスクに合わせることだ。作業が変動する端点を許容するなら、ディレクトリは効率的な道具である。特定のデータ取り扱いの約束に依存するなら、その約束をできる当事者だけが意味を持ち、ディレクトリは経路の便利さであって保証ではない。
curl -s --interface tun0 https://example.net/ -o /dev/null -w '%{remote_ip}
'上のコマンドは実行する価値がある。二つの問いをきれいに分けるからだ。通信が実際に使ったアドレスを示すが、それは接続の事実であり、そのアドレスの運営者が接続のメタデータで何をしたかについては何も語らない。
クライアント側の問いは切り離しておこう
運営者の方針は一つの層であり、トンネルの中で何をするかの安全性は別の層だ。宛先でのHTTPS、ブラウザでのセッション処理、ログインしたアカウントの強さはあなたの管理下に残り、寛容な中継サーバーがそれを弱めることも、優れたものが強めることもない。
この分離は二つのよくある誤りを防ぐ。厳格な運営者方針をHTTPSを省く理由とすること、そして機能するHTTPS接続を中継サーバーの運営者が誰かを無視する理由とすることだ。どちらの誤りも二つの層を一つに溶かし、そのうえで間違った層について論じている。
短い文書の評価で両方を扱える。それぞれの約束をする当事者を名指しし、それを支える文書を添え、日付を記す。そのうえで、作業に強い主張が必要なのか、動く経路だけで足りるのかを決めよう。
掲載項目は、どこに接続できるかを伝えた時点で役目を果たしている。問いの残りはその端点を運営する者に属し、正直な答えは多くの場合、知りようがないので、それに応じて選ぶべきだということになる。