It has been an eventful couple of months for WEBCAT. Since the alpha release, we've presented at Real World Crypto, been evaluated in an independent academic survey, continued shaping an emerging browser standards effort, and welcomed a new team member as we prepare for beta.

Real World Crypto 2026

At Real World Crypto in Taipei, we presented “Improving the Trustworthiness of JavaScript on the Web” on a panel with representatives from Mozilla, Cloudflare, and Meta. The talk covered the shared problem of establishing trust in browser-delivered web applications, and three approaches currently being worked on: WEBCAT, Meta's Code Verify, and the emerging WAICT effort.

An independent evaluation

At the ACM Web Conference 2026, Simon Schwarz of the Max Planck Institute, and Florian Bauckholt and Leon Trampert of the CISPA Helmholtz Center for Information Security published “Trust on Reload: Securing Browser-Based End-to-End Encryption.” The paper surveys five client-side code integrity tools: Meta's Code Verify, Accountable JS, Signed Pages, WAIT, and Giulio's WEBCAT original thesis and prototype. It evaluates whether each actually protects the security guarantees of E2EE in real web applications. Across the five tools, the authors identified nine common design and implementation pitfalls, and responsibly disclosed 18 security-relevant bugs.

Table from the paper “Trust on Reload: Securing Browser-Based End-to-End Encryption,” summarizing the achieved security properties of the various projects surveyed.

The authors conclude that WEBCAT provides the broadest security guarantees of any tool they surveyed, noting “The March 2025 WEBCAT preview provides strong integrity guarantees” and that "the developers have since fixed the issues raised in this work and made other major changes."

Specifically, the following pitfalls affected the original WEBCAT version:

• P3 – Missing Header Verification. It didn't verify the HTTP Location header, which, under redirect, preserves the URL fragment and can leak fragment-held secrets.
• P5 – Missing Resource Verification. It didn’t offer the option to verify non-active resources, such as fonts or images, which can be exploited for server-controlled UI-based attacks.

All implementation issues identified have since been fixed, and beyond those, we've also fully addressed the design-level limitations the paper identified. The findings from the paper, in addition to our internal work, led to the broader architectural changes we wrote about in “Towards auditable web application runtimes,” which we've since contributed to the WAICT effort (more below). We're grateful to the MPI/CISPA researchers for doing this work carefully and publicly, and for the responsible disclosure.

WAICT: A converging model

In parallel, a cross-vendor effort under the name WAICT — web application integrity, consistency, and transparency — is drafting a browser-native specification for the same problem, with participation from Mozilla and Cloudflare. WAICT describes how to enforce integrity over an entire web application using a manifest committed to a transparency log.

We've been part of the WAICT standardization effort from early on, and the WAICT integrity model is converging on a number of design choices we previously described: the split between active content and passive content, the logic that decides when to enforce integrity versus when a miss is acceptable, the call-level enforcement of Wasm, and the default-fallback page pattern for handling nonexistent paths and server errors, among others. We’ve furthermore pushed for extensibility support, decoupling the integrity from the transparency enforcement.

There are still some differences between the current WAICT draft and WEBCAT, reflecting the different design considerations between a focused open source application and a browser standard potentially shipped by multiple browser vendors. A few worth calling out: preventing dynamic code execution, more scrutiny on HTTP headers, and special attention to the CSP header.

Working through these tensions in the open is exactly what the standardization process is for, and we're glad that our sustained engagement is translating into stronger security guarantees and better compatibility for real-world deployments. A web-native standard shipped by multiple browsers beats any extension-based approach, and seeing the design converge on a model close to what we’ve deployed is an encouraging sign for the standard’s practical viability.

New on the team: Juho Forsén

We're glad to welcome Juho Forsén to the WEBCAT team. Juho brings a long career in security, including deep expertise in application security, browser behavior, and cryptography, and has already made substantial architectural improvements to the extension, and helped identify and fix security issues.

Heading toward beta

We're heading toward a beta release, and we'd like to hear from you, if:

• You maintain an open source web application and want to explore WEBCAT compatibility or deployment.
• Your organization is interested in running pieces of the decentralized enrollment infrastructure.
• You're a web developer, or security or browser expert, who wants to help review the WAICT draft specifications. Reading through it with a particular use case in mind, spotting limitations, and filing issues in the repository is one of the most useful things you can do at this stage.

You can reach us at webcat@freedom.press or file an issue on GitHub. The extension is available in Mozilla’s add-ons registry for anyone who wants to try the alpha. We’d like to thank everyone who's engaged with this work so far.