OpenAICloudflare2026/07/27 13:00

We’re open-sourcing our privacy proxy CLI

要点だけを先に読めるように短く再構成したセクションです。

元記事

Quick Digest

要約

要点だけを先に読めるように短く再構成したセクションです。

openaijamodel: gpt-5-mini-2025-08-07

プライバシープロキシCLI「pvcli」をオープンソース化

Key Points

  • pvcli を公開
  • OHTTP デバッグが簡単に
  • Apache-2.0 で公開

Summary

Cloudflareのプライバシーチームは、Oblivious HTTP(OHTTP)などのプライバシー保護プロトコルのデバッグを容易にするCLIツール「pvcli」をApache-2.0でオープンソース公開しました。pvcliはリレー、ゲートウェイ、オリジンを含むフルOHTTPフローを単一コマンドで実行でき、運用・開発・インシデント対応での再現と検証を高速化します。実装はRustで、外部からのコントリビュートを受け付けています。

pvcli --ohttp \
  --first-hop https://relay-cloudflare.ohttp.info \
  --proxy https://gateway.ohttp.info \
  -X POST \
  --header "content-type: application/json" \
  --data '{"test":1}' \
  https://target.ohttp.info/anything

Key Points

  • 目的: OHTTPなどのプライバシープロトコルのデバッグとエンドツーエンド検証を簡素化。
  • 機能: リレー→ゲートウェイ→オリジンを含むフルOHTTPリクエストの実行と再現。
  • ライセンス: Apache-2.0。コントリビューション歓迎。
  • 実装: Rust。大規模で実運用されるプロトコルの運用経験を反映。
  • 利用例: Apple Private Relay、Microsoft Edge Secure Network、Flo Healthなどのプライバシー製品での検証やトラブルシューティングに有効。
  • エンジニア向け実用ポイント: ローカルでの再現、CIでの回帰テスト、インシデント時の手順再現に使える。

Full Translation

翻訳

原文の流れを保ったまま読める翻訳セクションです。

openaijamodel: gpt-5-mini-2025-08-07

プライバシープロキシCLIをオープンソース化しました

プライバシープロキシCLIをオープンソース化しました

公開日: 2026-07-27 — Hannah Wang, Ben Yang, and Fisher Darling — 読了時間: 約8分

デバッグはプライバシー保護プロトコルにとって難しい作業です。Oblivious HTTP には四者にまたがるいくつものステップがあり、バイナリHTTPエンコーディングや多数の草案RFCに散在する細部もあります。我々は、Oblivious HTTP のようなプロトコルを1秒間に数百万リクエスト規模で運用して得た知見をまとめ、使いやすいCLIツールにしました。本日これをオープンソースとして公開します。

このツールを privacy-client、または pvcli と呼んでいます。ライセンスは Apache-2.0 License で公開しており、コントリビューションを歓迎します。

以下は、relay、gateway、origin を使った完全な Oblivious HTTP リクエストを一行で実行する例です。意味が分からなくても心配いりません — 以下で説明します。

pvcli --ohttp \
  --first-hop https://relay-cloudflare.ohttp.info \
  --proxy https://gateway.ohttp.info \
  -X POST \
  --header "content-type: application/json" \
  --data '{"test":1}' \
  https://target.ohttp.info/anything

このツールを作った理由と、その便利さを説明します。

なぜプライバシー・プロトコルのデバッグは難しいのか

まずは我々が pvcli を作った動機を詳しく見てみましょう。時間の経過とともに、Privacy チームの製品群と顧客基盤は成長しました。Privacy Proxy や Privacy Gateway のようなプロダクトを追加し、これらは Apple の Private Relay、Microsoft の Edge Secure Network VPN、Flo Health の Anonymous Mode などを支えています。これに伴い、顧客固有の要件やドメイン知識、全体の複雑さが増しました。

その結果、開発やインシデント対応での摩擦が増えました。実際の動作を把握するために、我々の製品の一つが Oblivious HTTP(OHTTP)をどのように実装しているかを見てみましょう。

OHTTP(簡単な説明)

OHTTP は利用者に対して次のようなプライバシー保証を提供します:誰がリクエストを行ったか(発信者)と、何をリクエストしているか(内容)の両方を1人の主体が同時に知ることができない、という保証です。これを実現するために、OHTTP はリレー(relay)とゲートウェイ(gateway)の2つのサーバーを要求し、これらは共謀しない2つの別個の当事者によって運用されます。

以下は、顧客が relay を所有し Cloudflare が gateway を所有している場合の OHTTP のシーケンス図(説明)です。

大まかに言うと、OHTTP は次のステップに分解できます:

  1. クライアントが gateway から公開鍵を取得する。
  2. クライアントがリクエストを暗号化し、relay に送信する。
  3. Relay が暗号化されたリクエストから「誰が送ったか」を切り離し、gateway に送る。
  4. Gateway がリクエストを復号し、ターゲットに送信する。
  5. ターゲットがリクエストを処理し、レスポンスを gateway に返す。
  6. Gateway がレスポンスを暗号化し、relay に送る。
  7. Relay が暗号化されたレスポンスをクライアントに返す。
  8. クライアントが復号して平文のレスポンスを得る。

ご覧のとおり、かなりやり取りが多く、各ステップはデバッグ時に考慮すべき潜在的な失敗点になります。

特に、OHTTP のデバッグ時には特定の種類の問題が発生することが多く見られました。お客様からは自身の側でライブシステムをテストする方法を求められることがあり、我々はしばしば