Today, we’re beginning to roll out new ZODL-operated wallet infrastructure that shields your IP address from being connected to your wallet requests.
We’ve partnered with Cloudflare and Fastly to integrate Oblivious HTTP (OHTTP), which routes wallet requests through independent relays. The relay sees your IP address but cannot read your encrypted wallet requests, while ZODL’s servers process those requests without seeing your originating IP address.
Beyond strengthening privacy, operating our own lightwallet servers will allow us to improve reliability, scale capacity, and build new features with greater independence.
The rollout is beginning with Zodl 3.20.0 on Android and iOS, with F-Droid and GitHub releases following later this week.
Obligatory this does not actually hide your IP address notice, even though you said it.
This is NOT an alternative to Tor. Using a Cloudflare OHTTP relay means trusting Cloudflare (which terminates TLS and can see your origin IP, even if not the request itself). So while ZODL cannot see who you are, Cloudflare absolutely can, and being under United States jurisdiction, is vulnerable to any Allied/G20 law enforcement requests to log requests from a specific ASN and location.
Simply put: the “anti-collusion” only works if all involved entities are invulnerable to at least 1 MLAT/subpoena, which is not the case here. ZODL is in Switzerland, Fastly and Cloudflare are in the United States.
If you want true privacy, use Tor, do NOT rely on this.
Thanks, that’s a fair point, and you’re right that OHTTP is not a replacement for Tor.
OHTTP splits what any single party can see: the relay sees your IP but not your requests, and our gateway sees the requests but never your IP. The guarantee holds as long as the relay and the gateway don’t collude, and, as you say, a legal order served on both could break that. We don’t claim otherwise.
What it changes is the default. Until now, a wallet talked directly to a lightwalletd server that saw both your IP and every request. With OHTTP, no single operator, including us, gets both by default, for every user, with no extra setup.
Tor is still fully supported in Zodl, and you can keep using it. You don’t have to choose between the two either: with Tor enabled, the OHTTP requests themselves go over Tor, so the relay only sees a Tor exit and never your IP. That’s the combination we recommend for anyone whose threat model includes legal pressure on infrastructure providers.
To limit what the relay can infer from traffic, sensitive responses (transactions, tree states, block ranges) are padded to fixed-size chunks, so their size doesn’t reveal what was fetched.
I absolutely do not dispute that. That is 100% correct. What I am concerned about is optics. The wording (“private wallet servers”) may lull users into a false sense of security, such that they may stop using Tor or Nym. That is when privacy breaks.
So keep it, just don’t overhype it, and ALWAYS, WITHOUT EXCEPTION, say that it is vastly less secure than Tor or Nym for protection against a state adversary.
Will 99% of the people who use Tor for this actually have a NSA nemesis? Heck no! But that’s not the point, the point is potential misrepresentation.
Understood, and agreed on the framing. Every design relies on non-collusion at some level, and Tor is no exception: a guard and an exit that collude can correlate traffic. What matters here is that no single edge sees both your IP and your request at the same time, and removing that by default for every user is the reason we run our own infrastructure. It’s a better default, not a substitute for Tor or Nym against a state adversary. Users who need that should keep Tor on, and Zodl fully supports it, including combined with OHTTP. We’ll keep that distinction clear in how we describe it. Thanks for the push.
That is quite pedantic/falsely equivalent here, because the difficulty is exponentially higher. The US government, who literally designed it, spend years getting all friendly nodes they had to line up to just one site, and even then was not able to get every node properly lined up. Here, Cloudflare and Fastly outright owns all relays as well as their network interfaces.
Thanks for writing this up. One technical question: do the Cloudflare and Fastly relays accept browser clients, i.e. answer CORS preflights for a web origin? We’re looking at OHTTP for a web app, where that’s the first thing that decides whether it works.
Good question. No: our relays don’t answer CORS preflights, so they can’t be called from a browser. They serve one path only: requests from the Zodl mobile apps, which they forward to our gateway and nowhere else.
For a web app you’d need a relay that serves your own origin with CORS, plus your own gateway. RFC 9458 (Oblivious HTTP) and RFC 9292 (Binary HTTP) are the place to start, and there are several public OHTTP implementations you can build on.
Thanks, that’s clear. One technical question: OHTTP is one request, one response, but light client sync leans on server-streaming calls like GetBlockRange. How does the Zodl app handle those over OHTTP: batched ranges as single requests, chunked responses, or do streams go over a different path?
Streams go through the same path, with chunked OHTTP (the IETF draft “Chunked Oblivious HTTP Messages”). A server-streaming call like GetBlockRange is one OHTTP request through the relay. The gateway opens the stream to lightwalletd and returns the response as a sequence of encrypted chunks as the blocks arrive, so the client starts processing before the range ends. The gRPC status and trailers come in the final chunk, and a truncated stream is detected as an error rather than taken as a complete one. Sensitive responses, block streams included, are padded to fixed-size chunks, so chunk sizes don’t reveal block contents.