Why We Built Popcorn: An Attestable Browser Cloud for Reclaim | Reclaim ProtocolWhy We Built Popcorn: An Attestable Browser Cloud for Reclaim<br>Abdul Rashid Reshamwala<br>Aug 5, 2026

engineeringpopcornTEE<br>Reclaim lets people prove facts about themselves from websites they already use. Popcorn is the attestable browser cloud we built to make those proofs easier to integrate. Users complete the flow in a live, mobile-native browser running inside a Trusted Execution Environment (TEE). Popcorn generates the proof, then destroys the session. You can try Popcorn or explore the code on GitHub.

In the latest 30-day window, Popcorn created 102,859 browser sessions and allocated ready browsers in 470 ms at p50 and 889 ms at p95 .

The story began with a WebView on the user's phone. That approach kept the work close to the user, but it asked every app integrating Reclaim to carry a surprising amount of infrastructure in its pocket: native cryptography, WebView orchestration, proof generation, and platform-specific glue. We rebuilt our proof-generation engine and cut proof time from roughly 40 seconds to 4–5 seconds, but the integration was still substantial. That migration is a story of its own.

The performance problem had improved. The integration problem had not.

We built both an App Clip and an Android Instant App to avoid a full SDK integration. They worked, but partners did not want verification to send users into a separate app experience. Google Play Instant was eventually discontinued. We needed an integration that stayed inside the product flow without putting the full browser and proof workload on the phone.

The product idea sounded almost suspiciously simple: open a browser remotely, stream its live view to the user, let them sign in and navigate, then generate the proof. Moving the work off the phone, however, also moves the hardest part of the trust model into our infrastructure.

The integration starter packSome assembly no longer required.

same proof · less inside the app<br>Before · ship the machinery<br>WebViewNative cryptoProof enginePlatform glue

With Popcorn · open the flowhttps://…/verifyOpen<br>One verification URL The browser and proof workload run remotely.<br>🍿

Starting with Kernel

We evaluated Browserbase and other hosted-browser platforms. Kernel worked best for our flows, especially because we needed headful browsers.

Users needed to operate a real, visible Chrome session. Some sites behave differently in headless mode, while some login flows block automation. Kernel gave us interactive Chrome sessions, a live view, and browser-control APIs we could build on.

Kernel got us to a working product quickly. Another important point was that its browser image was open source. We could inspect the image, make the changes our flows needed, and contribute useful fixes upstream, including parent-frame status events and a video-sync anti-echo fix.

Once the remote-browser experience worked, the harder question became where that browser could safely run.

Kernel did not have plans to support the hardware-backed security model we needed. That meant the browser had to run on infrastructure we controlled. We started building our own TEE-based deployment, using Kernel's open-source browser image as the base instead of rebuilding a headful Chromium container from scratch.

The browser still had to be trusted

Browser sessions handle credentials, cookies, and private account data. Encryption protects that data while it travels across the network and while it is stored, but not while the browser is actively using it. Inside an ordinary VM, the host can still access that memory.

A Trusted Execution Environment, or TEE, gave us the missing protection. It is designed to isolate the browser's memory from the rest of the host, including the surrounding cloud infrastructure.

A very short hardware heist attempt #404<br>Suspicious host process⌁steal(browser.memory)

TEE<br>BONK!<br>Protected memory<br>🍿

browser: unbothered<br>MEM?nope<br>Result: memory not found. Dignity also missing.It cannot directly inspect the TEE-protected browser memory.

A TEE does not hide the page from the browser; the browser still needs to render it and generate the proof. It protects that work from the surrounding host. In production, each browser runs on a Confidential GKE Node with a small attestor service beside it.

In simple terms, a verifier can check that the session ran on genuine confidential hardware and used approved code. It does not have to take our word that the server was configured correctly.

Here is how it works in production. The verifier sends the attestor a fresh nonce, or one-time random challenge. The attestor returns a response tied to that challenge, the cryptographic fingerprints of the browser and attestor images, and a Google Cloud hardware attestation.

A TEE still does not replace TLS, authentication, authorization, or code review; it narrows what must be trusted.

This was not a security feature we could bolt on after the...