Verifiable Web Code — Why It's So Exciting

Browsers are beginning to be able to guarantee that the code running on a page is actually the code its developers published — no silent tampering, no trusting the server.

We think the payoff is huge:

It beats "install our binary." Nothing to install — just open a URL. It runs inside the browser sandbox instead of giving apps full disk access, and automatic integrity checks make it both more convenient and safer than the downloaded-app-hash alternative.
Open source becomes a lot more attractive. Published frontend code today only tells you what a project could ship — not what's actually running in your browser right now. Fixing this makes open-source web apps dramatically more credible.
It could be as significant an upgrade as HTTPS. HTTPS secures the connection between your browser and the server. This makes the application layer trustworthy too — letting web apps build real end-to-end channels between users (or users with themselves, eg secure file storage), not just connecting to a server that can still betray them.

Here's the problem it solves, and where it stands today.

The vulnerability

Web apps aiming for "zero trust" have long had a big hole in that promise. No matter how sturdy the architecture is, every time a page is loaded, the server hands the browser fresh code — and in practice there's no convenient way to check it's the code you think it is. It's theoretically possible to inspect the network tab or diff a source by hand, but effectively no-one does. A compromised server or rogue insider can silently swap in malicious Javascript, then swap it back before anyone notices.

This isn't a new observation. Thomas Ptacek wrote back in 2011 "Javascript Cryptography Considered Harmful": you can't do meaningful crypto in the browser if the server delivering the crypto code can't be trusted. In 2020, Artemis Lena spelled out how targeted the attack can get, with "Do not use webapps in zero-trust designs" — a service could push malicious code for even one specific user, grab what it needs, then quietly revert. A later audit would find nothing.

The fix

A project called WEBCAT from The Freedom of the Press Foundation (built for SecureDrop, to protect whistleblowers) changes this: it enables your browser to automatically check opted-in sites' code against a signed, public manifest before running it. If there's a mismatch, the page refuses to load. No silent tampering or relying on someone noticing later.

You're still trusting something, but it shrinks from every single page load down to the single, auditable publication step. Out in the open, where anyone can check.

It builds on earlier efforts like Meta's Code Verify for WhatsApp.com, and is now converging with browser vendors through a new working group: WAICT ("Web Application Integrity, Consistency, & Transparency").

Firefox already has an early native prototype, Cloudflare has helped author the transparency spec, and the other major browser vendors are engaged. That's part of what makes this especially exciting: it's on track to eventually become a browser default.

Why it matters to us

We've always built SIV without assuming this problem would get solved — we couldn't wait on a "someday" fix. Instead, SIV lets voters run the code themselves, easily air-gap their vote against spying client software, and verify after the fact that their vote wasn't tampered with.

But these require manual steps. Verified web code would automatically get everyone that same protection, at vastly larger scale.

Current status, & how you can help

WEBCAT is live & in production: github.com/freedomofpress/webcat

Applications can already enroll today, with consumer support for Firefox & Tor Browser.

Browser vendors are active in the new WAICT working group to nail down an exact standard, working through edge cases & implementation details, to bring this to everyone.

We've shared some feedback of our own — ideas for making the implementation even easier to adopt, including an intermediate architecture built on browsers' existing extension APIs, a sort of polyfill people could start using much sooner.

If you have an app that can benefit, you're encouraged to do the same: try out the enrollment process, and give feedback.

Bright future

We hope to see the full standard ship as soon as possible, and just become how browsers work by default — as ubiquitous and invisible as HTTPS.

This development can seriously raise the baseline safety level for everyone.

Not just for high-stakes tools like SecureDrop, even an ordinary password login screen — every bank, email, and social account on the web — could finally adopt, and prove, designs where your raw password never leaves your device. Today there's little reason to bother, since users can't verify the code anyway. Verified web code changes that math.