Key Persistence Lab Browser experiment
How it works
One iframe. Different websites.
A key can stay in your browser without being available everywhere. Follow it across two websites to see what your browser actually remembers.
Ready to try · No account, installation, or API keys
Try it in your browser
Stay in this browser and profile. Let each check finish, then choose Continue. Reload a page to test whether its key survives a refresh.
This is a real cross-origin iframe. Every stop embeds the exact same Site A.
The iframe is opening its browser storage and signing a fresh challenge.
Waiting for a verified resultThe next step becomes available after this check succeeds.
Your journey
| Stop | Compared with | Observed key |
|---|
Tour links carry public fingerprints for comparison. They never transfer private keys or share the iframe’s storage. Starting a new comparison keeps existing keys.
Fingerprints identify public keys. Signature bytes change and should not be used to identify a key.
Loading iframe…
Understand the result
Non-extractability controls exporting a key. Storage partitioning controls where that key can be found again.
The iframe creates a signing key and saves it in IndexedDB, the browser’s database. It can use the key to sign a message. This demo checks that trying to export the private key fails.
Your browser may keep one storage compartment for Site A inside B and another for Site A inside C. If C’s compartment has no key, the iframe creates a different one—even though its code and address are unchanged.
B and sub-B have different origins but belong to the same site. C belongs to another site. With site-partitioned storage, expect B = sub-B and C = sub-C, while B ≠ C.
Before & after
Nothing else needs to be configured. The pages and iframe are already hosted over HTTPS on Cloudflare.
Start on Site B. Wait for a verified result, then reload once: the fingerprint should stay the same. Continue through sub-B, C, sub-C, and back to B. The page compares fingerprints automatically. Download the results at the end.
That is an observation worth recording. Browser version, privacy settings, extensions, private browsing, and prior storage permissions can change behavior. A storage error means the test could not complete; it does not prove isolation. Repeat in another browser without changing settings midway.
Use a new browser profile, or clear this demo’s site data across all visited contexts. A new comparison only clears the tour’s references. It does not delete keys. Do not clear browser data during a journey.
This is a standalone Prove-branded browser experiment, not a Prove authentication flow. It uses no Prove SDK, phone number, account, or API credentials. Keys and signatures are created in your browser; this demo does not upload them to a backend. Cloudflare serves the files and receives ordinary page requests.
It measures whether an iframe can rediscover a saved key. It does not test blind tokens, hardware-backed keys, explicit CryptoKey transfer, or persistence after data is cleared. Non-extractable CryptoKeys can still be structured-cloned where the platform allows it; this demo never sends them to a parent page.
We do not request Storage Access API permissions. Those grants are a separate experiment and can change the storage available to an iframe.
Each Cloudflare Pages project is a separate site because pages.dev is on the Public Suffix List. The subdomain preview of each project is part of that project’s site. This gives us real HTTPS cross-site and same-site comparisons without custom domains.