We’ve been saying it for a while: Verifiable browser code is on the critical path for a redesigned version of SecureDrop, not to mention something that would benefit the wider browser security ecosystem. In our last post on this topic, we outlined the more-than-decade-old problem and its relevance to SecureDrop using several case studies, and we laid out the core requirements as we see them.
In this post, we introduce Web-based Code Assurance and Transparency, a project that supports verifiable in-browser code for single-page browser applications. Along with this post, we are publishing the WEBCAT project repository; follow-up posts will provide more detailed information.
Overview
WEBCAT is a multicomponent project; the easiest way to explain it is to start with the end-user experience. When a user visits a website that has enrolled in WEBCAT, before the site can load the content is checked against a signed manifest to ensure that it has not been tampered with (more on enrollment later). If everything checks out, the page loads normally. If, however, any content does not match what’s expected, the page load is aborted and a warning is displayed, protecting the user from potentially malicious content before it can execute.
Behind the scenes, a lot is going on to ensure that application developers can update their applications without requiring effort on the part of anyone hosting the web application. WEBCAT allows for a transparent, independently verifiable signing, verification, and update process, and ensures that the enrollment process itself can’t be abused. The project uses Sigstore, Sigsum, and The Update Framework, among other components; details are below.
So … does it work?
We deployed several popular self-hosted applications, including Element, Jitsi, Standard Notes, Bitwarden, CryptPad, and GlobaLeaks, as part of initial proof-of-concept testing. More details can be found in the project repository.
Proof-of-concept WEBCAT-enabled version of the Jitsi videoconferencing software, with the browser extension showing that all its components pass verification.
Before we dive in
There are a few more things to keep in mind: who our users are and what we’re trying to protect them from.
The users we’re trying to protect are engaged in an important, potentially high-stakes activity. Whether it’s using SecureDrop, GlobaLeaks, or another browser-based encryption tool, the user experience should minimize cognitive burden and provide safe defaults.
One use case that WEBCAT supports is that of site administrators self-hosting third-party applications — the backbone of the decentralized web. Self-hosted applications (like SecureDrop!) are often smaller, lower-traffic servers, where the resources and protections available to site administrators are limited compared to those of larger, centralized services.
In self-hosted deployments, a trusted application may be deployed on various hosts with different trust levels, and application developers and hosters are often distinct entities. An application developer should be able to ship signed updates without putting a maintenance burden on everyone self-hosting the application; similarly, an end user should be able to trust the application developer directly, rather than having to rely on assurances from an individual site owner or the server itself.
WEBCAT architecture
WEBCAT is a project that lets application developers or service providers create and update signed artifacts attesting to the code that they are shipping; site owners enroll their domains that run these applications; and end users automatically verify that the code they are served is authentic. Auditors may independently observe, reproduce, and evaluate the entire process.
The system is designed to fail closed for end users, meaning that a user doesn’t have to know or do anything to take advantage of the integrity mechanisms; they simply browse the web as they normally would.
When the WEBCAT browser extension fails to verify any part of a web application, it will not load any content or execute any scripts.
WEBCAT has four main components:
- A signing script that allows application developers to generate a signed manifest to verify the content they intend to serve to users
- An enrollment server to allow site owners to enroll their website
- An updater service that builds a list of trusted signers per domain
- A Firefox extension, to provide the end user an in-browser integrity checking mechanism, which blocks code that fails integrity checks for enrolled websites and warns the user.
WEBCAT does not depend on TLS, making it easy to integrate over other encrypted transport mechanisms, such as Tor Onion Services.
PLEASE NOTE: This is a developer preview; WEBCAT is not yet intended for production use.
Developer workflow
We are open source software maintainers ourselves, and we know how much work goes into application development. WEBCAT aims to provide a developer-friendly path to code integrity. Here is how the process works from a developer perspective.
First, developers ensure all their executable assets, such as JS, CSS, and their main HTML page, are static. They then sign an application manifest using Sigstore and one or more OIDC identities with the help of our signing script. The signed manifest contains: application metadata; a data structure that includes a cryptographic hash and the corresponding path for assets that will be loaded directly in the browser; and one or more Content Security Policies. Signing operations are transparently logged and published to Sigstore’s transparency log, Rekor.
WEBCAT tries not to restrict or downgrade the set of browser security features available to application developers, so it is compatible with configurations such as multiple CSPs for a given domain. It also aims to support modern web features and services (sandboxing iframes, workers, WebAssembly), while still failing closed and blocking untrusted content by default. A list of supported features can be found here; more detailed information can be found in the preliminary Developer Guide.
Enrolling in the preload list
WEBCAT uses a preload list of enrolled domains, instead of real-time fetching, to protect source privacy and avoid leaking timing or domain-specific query information. An updater service periodically builds a reproducible, independently verifiable preload list of enrolled domains and their authorized signers from the Sigsum transparency log; the updated preload list is fetched automatically by the end user’s browser. The extension can then locally verify that an application manifest has all the necessary valid signatures to be considered trusted for a domain.
A site owner hosting an instance of this application then enrolls their domain using the WEBCAT enrollment server. In contrast to other enrollment processes such as typical Certificate Authority enrollment, the WEBCAT enrollment model includes a "cooldown" period before changes are applied. This prevents rapid changes, requiring the site administrator to prove continued control over a domain to prevent a website from being enrolled or de-enrolled by an unauthorized actor. The end user’s browser then fetches an updated preload list, and benefits from code integrity protections when visiting enrolled domains.
Next Steps
In the true spirit of open source, our excitement at sharing this contribution is rivaled only by our excitement at updating one of our oldest open GitHub tickets. While we’ve emphasized the use case of smaller servers, self-hosted single-page applications, and Tor Onion Services, all of which describe the SecureDrop use case, we can see a variety of projects and platforms that could benefit from this type of privacy-first code integrity system.
We’re in early discussions with the Tor Project about delivering WEBCAT-like functionality through Tor Browser, and we’re grateful to the Tor team for its work on the project in an advisory capacity and providing crucial early feedback.
We’ll have more to say in the weeks and months to come. In the meantime, we welcome your feedback: you can write to us at <securedrop@freedom.press> (PGP-encrypted), or find us on GitHub.
FPF’s work on WEBCAT has been made possible by funding from the Filecoin Foundation for the Decentralized Web. We are deeply grateful to FFDW for their support.