Privacy protocols tend to hide the exact thing engineers reach for during an outage: the straight line between a caller and a request. That is the bargain. If a system is supposed to stop one operator from seeing both who made a request and what the request contained, then debugging cannot depend on one convenient wire trace that explains the whole story.

That is why Cloudflare's July 27 release of pvcli is more interesting than a new command-line tool normally sounds. The company is open-sourcing a curl-like client for privacy-preserving HTTP work, with first-class support for Oblivious HTTP, HTTP/2 and HTTP/3 requests, relay and gateway testing, CONNECT proxying, and the rough edges that show up when a protocol leaves the whiteboard.

The project lives at cloudflareresearch/pvcli under the Apache-2.0 license. Its README also carries the right warning label: the software is experimental, unaudited, and should be treated as a tool for testing and implementation work rather than a magic privacy appliance.

OHTTP test path

client intent
  - method
  - headers
  - body
  - target URL

pvcli
  - fetch key config
  - encrypt request
  - send outer request
  - trace relay/gateway behavior

relay -> gateway -> origin
The useful abstraction is not hiding the protocol. It is making each privacy boundary testable without hand-built scripts.

Privacy Needs Boring Tools

Oblivious HTTP, standardized in RFC 9458, splits knowledge across a relay and a gateway. The relay sees the client but not the target content. The gateway can recover the request but should not learn the original client identity. Cryptography, transport, and operational separation are all part of the model.

That is a clean privacy story. It is also a debugging tax. A normal HTTP client can show a request and response in one place. An OHTTP implementation has to care about key configuration, encapsulation, binary HTTP encoding, HPKE choices, proxy transport, gateway behavior, origin behavior, and whether each actor in the chain is failing in a way that looks like someone else's problem.

Cloudflare says pvcli grew out of that operational friction. The company has been running protocols such as OHTTP at large scale, and the blog post frames pvcli as a way to turn incident response and implementation testing into repeatable commands instead of specialized tribal procedure.

The point of a privacy-preserving protocol tool is not to make the privacy vanish during debugging. It is to give engineers enough handles to test the pieces without collapsing the boundary the protocol was built to protect.

The Curl Shape Matters

The reason curl became infrastructure is not that HTTP is simple. It is that curl gives engineers a small, scriptable instrument they can trust when a browser, SDK, proxy, or service framework adds too much behavior. The same pattern matters here. Privacy-preserving protocols will not spread through production systems if every validation step requires a notebook full of bespoke invocations.

pvcli's README describes a practical scope: plain HTTP/2 and HTTP/3 GET and POST requests over TLS, OHTTP requests through a relay and gateway, proxy headers for CONNECT flows, local mock gateway testing, and an HTTP/3 proxy transport option. The dependency list points at real protocol plumbing, including HPKE, TLS 1.3, and QUIC-related Rust components.

That combination is narrow in the right way. It does not try to become a browser. It gives protocol engineers a repeatable path for asking, "does this request work through the privacy layer, and where does it break?"

The Roadmap Is A Signal

Cloudflare is also clear that pvcli is not meant to stop at today's OHTTP use case. The post names CONNECT proxying, MASQUE, and Privacy Pass as the broader neighborhood. The repository's to-do list includes TCP proxying over HTTP/3, UDP and IP proxying over HTTP/2 and HTTP/3, Chunked OHTTP, timing and latency information, better logging, and post-quantum cryptography support for OHTTP.

That roadmap matters because privacy infrastructure is becoming less like a single feature and more like a family of transports. OHTTP, HPKE, HTTP/3, and proxying protocols all sit close to the path where browsers, apps, relays, CDNs, and application backends meet. The tooling has to follow that path, not just the spec text.

What To Watch

  • Operational clarity: if pvcli becomes the shared repro command for OHTTP issues, it can reduce the distance between protocol authors, platform teams, and product engineers.
  • Protocol coverage: MASQUE and Privacy Pass support would move the tool from OHTTP helper toward a broader privacy transport workbench.
  • Security maturity: the unaudited warning is important. A debugging client can become critical infrastructure once teams put it in CI, incident runbooks, and conformance tests.
  • Implementation diversity: an Apache-2.0 tool from a large operator gives other implementers a concrete target to compare against, which is how protocol ecosystems get less mysterious.

The small lesson is that Cloudflare released another open-source CLI. The larger one is that privacy-preserving infrastructure needs the same boring developer ergonomics as the rest of the Internet. If engineers cannot reproduce, inspect, and automate a privacy path, the protocol stays impressive but fragile. pvcli is a step toward making that path ordinary enough to operate.