September 5, 2026
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. HTTPS confirms that the browser has reached a server authorized for a domain, but from that point the server defines the page. It can inject a JavaScript backdoor or replace the page entirely tomorrow while keeping the same URL and certificate. Alice’s pages and Bob’s pages may share a domain, yet the browser has no way to distinguish their authority; it simply trusts whatever the server sends. Whoever controls the server—a hosting provider, CDN, cloud account, or an attacker who has compromised it—therefore controls everything it serves.
Existing mechanisms do not address this problem. Certificate pinning can confirm that the browser is still talking to an expected server, while Subresource Integrity can verify an embedded resource, but neither establishes the integrity of the page itself. Immutable storage, such as WORM and Legal Hold, has a similar limitation: if DNS is compromised, the browser can be directed to an impostor that answers the same URL with different content.
The missing layer is integrity at the URL path itself, allowing Alice and Bob to be verified separately even when their content lives on the same domain.
The website publishes an integrity.log, similar to robots.txt. This is an append-only history of signing keys, URL path assignments, and integrity requirements. It contains only public keys. A key inherits whatever rights an earlier valid key signed over to it, and retains those rights until its TTL expires. The first applicable record wins.
The browser always has the public key from the TLS certificate available as a starting point. When a signature cannot be verified through a chain already established in the log, it tries that key. A newly issued certificate, however, cannot override a path that has already been assigned to another key. Once a URL has an I line, the server also cannot simply remove its integrity protection and serve the URL unsigned. The log establishes the requirement; the page itself carries only the current checksum.
<timestamp>
<timestamp> A <TTL> <alice-key-1> <sig by cert-1> /alice/
<timestamp> I <TTL> <alice-key-1> <sig by alice-key-1> /alice/article.html
<timestamp> K <TTL> <alice-key-2> <sig by alice-key-1>
<timestamp> I <TTL> <alice-key-2> <sig by alice-key-2> /alice/app.js
<timestamp> K <TTL> <cert-2> <sig by cert-1>
<timestamp> A <TTL> <bob-key-1> <sig by cert-2> /bob/
<timestamp> I <TTL> <bob-key-1> <sig by bob-key-1> /bob/index.html
Every <timestamp> is Unix epoch UTC. The first line is the time the log was created and nothing else; it is part of the hashed content. The columns following it, preceding the variable-length path, are fixed width, allowing them to be stripped off when necessary. The TTL appears immediately after the line type so that a future version of the format can omit it. A signature may identify the key that produced it; otherwise, the browser tries every key authorized for the relevant path.
K— a valid key endorses a successor, which inherits its rights until the TTL expires.A— assigns a signing key to a URL prefix, where the assignment remains valid until the TTL expires.I— declares that a specific URL requires integrity. The checksum itself is not stored in the log.{}— a checkpoint block. The same timestamp marks both ends.
For HTML, the current integrity assertion is placed as the last line of the document. It contains a checksum of everything preceding it, including otherwise invisible bytes such as newlines.
<!DOCTYPE html>
<html>
<body>...</body>
</html>
<!INTEGRITY <sha256-...> <TTL> <sig by alice-key-1>>
The integrity line is not included in the hash. When a current I entry exists for a URL, this line is mandatory. If it is missing, stale, invalid, or does not match the document, the browser rejects the page. Without an I entry, the URL remains ordinary web content and no integrity assertion is required.
Non-HTML files can use an X-Integrity header covering the entire file. This represents the same bytes that would be hashed for an HTML document without its integrity line. How the server stores these values is an implementation detail: for example, a sidecar file such as <filename>.jpg.sidecar could be read by the web server and used to generate the header. When Alice changes a file, she generates a new checksum and signature; the I line in integrity.log remains unchanged.
Public keys and signatures are 32 bytes long. Encoded in Base64, they have this kind of shape:
7IbpFh91gyaBQxTiKRojcIlfO7fQBIdeBcrAv/5TET0=
Alice chooses the TTL herself: a day, nine months, or whatever period suits her use case. She does not need to rewrite the I line on a schedule. Before a key expires, she can add a K record authorizing a successor. If she loses her key, the affected files remain frozen until the TTL expires. Once it does, the URL becomes ordinary again. Lapsed records are dropped when the log is condensed at a checkpoint.
The visitor still types the same URL, for example:
https://example.com/alice/article.html
Behind the scenes, the browser finds an A entry covering /alice/, an I entry for the requested URL, and requires a current integrity assertion signed by a key in Alice’s chain. If the assertion is missing, stale, invalid, or does not match the content, the browser shows an error similar to a certificate error.
Recovery and Replay Attacks
To prevent replay attacks while allowing legitimate recovery, the system relies on third-party witnesses: the certificate authority named in the TLS certificate the server is already serving, and the domain’s registrar, found through the same lookup used for WHOIS. The browser does not ask the server where to look. A witness keeps the opening timestamp and cryptographic hashes of recently observed versions for a limited time or number of versions, then prunes older history. If it has no history for a domain, the browser’s first request starts one. If every witness has already dropped that history, the site is treated as new. That is either a genuine new site, or a replay that waited until no witness still remembered the old log—long enough that an active site could hardly afford the outage.
The browser compares the received opening timestamp and log hash against that history. With the same opening timestamp, an earlier witnessed version is a replay and is rejected. With the same opening timestamp, a version that extends a witnessed one—or that is a witnessed checkpoint—is normal continuity. A later opening timestamp is a reset. The opening timestamp must not be later than the time at which a witness first observes the log, subject to reasonable clock tolerance.
If the server still has a valid key chain, it continues the same log. A reset is an emergency measure, used when the log or the keys needed to continue it have been lost. The server then starts a new integrity.log whose opening timestamp is later than that of the previous log.
A new log may be published immediately, but during a recovery period of at least N = 1 day, or longer if the browser chooses, it cannot revoke or weaken integrity commitments from the previous witnessed log. Earlier A and I entries remain in force while their TTLs are valid, while new commitments in the reset log do not become effective until the recovery period ends. This prevents a compromised server from repeatedly resetting the log to escape Alice’s protection. Alice and Bob can also monitor integrity.log with watchdog software to verify that a new log preserves their keys and authorizations.
Truncating the Log
The log is append-only in history, but need not grow forever. A checkpoint restates all unexpired A, I, and K records, including certificate keys. Records retain their original timestamps and signatures; the block itself is unsigned. A witness hashes the entire block and records that hash.
...
<timestamp> {
<timestamp> K <TTL> <cert-2> <signature>
<timestamp> A <TTL> <alice-key-1> <signature> /alice/
...
<timestamp> A <TTL> <bob-key-1> <signature> /bob/
<timestamp> }
The opening and closing timestamps are identical. A checkpoint does not renew TTLs or signatures; it only restates records that remain valid.
A checkpoint may be witnessed immediately, but cannot become a cut point until it has coexisted with the history it replaces for at least N days—thirty days is a reasonable default. During that period, browsers can verify that every active record has been preserved, expired records alone have been omitted, and nothing has been added or altered.
After the waiting period, everything preceding a witnessed checkpoint may be removed. The witness need retain only the checkpoint hash.
A previously listed key may later be written as a prefix that identifies it uniquely up to the line where it is mentioned. The log is compressed, so column-alignment spaces add little to its size.
Keep reading
-
Hiding Text in a Numeric ID
September 2, 2026
When designing IDs that a person may need to read, copy, type, or pass to someone else, usability matters as much as uniqueness. A lookup ID may have to be dictated over the phone, …