DocsDigest
Back to listLanguage: JA
OpenAICloudflareJul 27, 2026, 1:00 PM

We’re open-sourcing our privacy proxy CLI

A condensed section focused on the key takeaways first.

Original Post
OpenAIClaude

Quick Digest

Summary

A condensed section focused on the key takeaways first.

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

We’re open-sourcing our privacy proxy CLI

privacyohttpclirusthttp3apache-2.0debugging

Key Points

  • pvcli CLI open-sourced
  • Runs full Oblivious HTTP flows end-to-end
  • Apache-2.0 license; contributions welcome

Summary

Cloudflare has open-sourced pvcli (privacy-client), a command-line tool that executes full Oblivious HTTP (OHTTP) flows end-to-end (client → relay → gateway → origin). pvcli is released under the Apache-2.0 license and is intended to make debugging, testing, and incident response for privacy-preserving protocols much easier for engineers working with relays, gateways, and origins.

Key Points

  • Purpose: reproduce and debug multi-party OHTTP flows locally or against live relays/gateways to reduce development and incident-response friction.
  • Usage: a single command executes a complete OHTTP request, e.g. 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.
  • Benefits: simplifies troubleshooting of each OHTTP step (key fetch, client encryption, relay stripping, gateway decryption, origin request, and response encryption) so you can isolate failures quickly.
  • Engineering workflow: useful for integration tests, CI debugging, reproducing customer issues, and validating relay/gateway configuration changes.
  • Implementation and compatibility: built with Cloudflare’s production experience in mind (mentions of Rust, QUIC/HTTP3 in project context); intended to work with existing OHTTP relays and gateways.
  • License and contributions: released under Apache-2.0 and open for contributions from the community.

If you operate or integrate with OHTTP-based privacy services (e.g., privacy proxies, gateways, or client integrations), pvcli lets you run and inspect full request/response flows without assembling custom tooling.

Full Translation

Translations

A translation section that keeps the flow of the original article.

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