In an effort to make the web safer, Entelecheia is sharing this proposed architecture with browser developers, standards organizations, and others working on the future of the web. It addresses a fundamental weakness in the face of JavaScript backdoors: browsers verify content per domain, but not per URL.

The web is already secure, but only up to a server. When you open a web page, your browser verifies the server that delivered it. A URL tells the browser where to go, and HTTPS confirms that it has reached a server authorized to operate that domain. After that, the server defines what the page is. It can inject a JavaScript backdoor into the application, or replace the page tomorrow, while keeping the same URL and certificate. Alice’s pages and Bob’s pages may live under the same domain, but the server is oblivious to Alice and Bob. The browser simply trusts whatever the server sends. Whoever controls the server—a hosting provider, CDN, cloud account, or an attacker who has compromised it—effectively controls everything it serves.

HTTPS does not solve this problem because it answers a different question: whether you reached the right server. Certificate pinning can confirm that the server is still the expected one, and Subresource Integrity can verify an embedded script, but neither establishes the integrity of the page itself or detects a backdoor already placed inside it. Immutable storage, like WORM and Legal Hold, has a DNS vulnerability: if DNS is compromised, the browser follows it to an impostor that answers the same URL with a different page.

The fix is to establish integrity at the level of the URL path, so Alice’s pages and Bob’s pages can be verified separately even when they share the same domain. A page Alice did not sign is refused.

To make this work, the website publishes integrity.txt, similar to robots.txt. It is an append-only history of integrity commitments. Suppose /alice/ is assigned to Alice. The server adds a signed entry assigning that path to Alice’s public key for a limited period:

<cert-1>
<cert-2>
<alice-key-1>        expires 2026-05-22T00:00:00Z      signed by cert-2       /alice/
<alice-key-2>        expires 2026-05-22T00:00:00Z      signed by cert-2       /alice/
sha256-...                                             signed by alice-key-2  /alice/article.html
sha256-...                                             signed by alice-key-1  /alice/app.js
<bob-key-1>          expires 2026-05-22T00:00:00Z      signed by cert-2       /bob/
sha256-...                                             signed by bob-key-1    /bob/article.html

Alice holds /alice/, and Bob holds /bob/. Each assignment covers that prefix and everything below it unless a more specific path says otherwise. The log preserves these decisions: new lines are added, while old ones are not rewritten. The browser already trusts the server’s certificate, and the public signing key for the domain comes from that certificate. Every key in the log has a label—certificate keys, Alice’s, Bob’s—so a signature can name one when several exist on the same prefix. A certificate key signs the assignment of /alice/ to one of Alice’s keys; that key signs an integrity commitment, e.g. a checksum, for a page under her path.

Alice sets the expiration herself: a day if she can automate renewal, nine months or whatever if she cannot. She appends a fresh signature before the assignment expires. If she loses the key, she cannot change those files until the term ends and /alice/ falls back to the domain. Lapsed lines can be trimmed so the file remains small without dropping anything still valid, for example through a Merkle-tree checkpoint.

The visitor still types the same URL, e.g. https://example.com/alice/article.html, and the browser does the checks behind the scenes. An error is shown only when integrity does not match, similar to how browsers currently show a certificate error.