The statements, and what their absence would actually mean.
Revision: Pre-Audit Candidate, 12 October 2026
Statement 1, dated 21 August 2026. Next statement due on or before 21 November 2026.
A canary is a set of things a service says while it is still able to say them, on the theory that being forbidden to repeat a statement is easier to survive than being forced to make a false one. It is a weak instrument, it is weaker than most sites imply, and the section on what its absence would and would not mean is the most important part of this page — more important than the statements themselves.
This is a draft, and we are not lawyers
Everything on this page was written by the people who build Haven, from the code, in the same register as the rest of this site. It is not legal advice and it has not been reviewed by a solicitor. Before this business relies on it — and before you do — it needs a lawyer's pass, and the clauses that need one most are marked where they appear. We would rather ship an honest draft that says so than a confident boilerplate that says nothing.
As at 21 August 2026
- Haven has not received a national security letter, a secret subpoena, or any other demand accompanied by a legal prohibition on disclosing that we received it.
- Haven has not been required to modify the client code served to any user, or to serve a different build to any user than to everybody else.
- Haven has not been required to add a key escrow, a decryption path, an additional recipient, or any other mechanism by which the operator could read content.
- Haven has not been required to hand over the database, in whole or in part, under a demand we are forbidden to describe.
- No employee, contractor or operator of Haven has been compelled by legal process to keep a demand secret from the rest of the team.
- Haven has not been the subject of a search, seizure or compelled access to its infrastructure.
Ordinary, disclosable legal process is a different matter and is not covered by this page. It is counted on the transparency report, whose figures are generated from a register rather than typed. The terms of service say what we comply with and, more usefully, exactly what compliance can produce — which for content is nothing, and for who talked to whom is everything.
Preservation orders
A court or other lawful authority can require us to stop destroying an account's messages. We have built the mechanism to do it, because a service that cannot comply with a lawful order is a service that gets taken apart rather than one that protects anybody. When a preservation order — a legal hold — is in force against an account, retention windows, disappearing messages, that account's own deletions and edits (the overwritten version is kept), the retirement of old conversation keys and the deletion of the account itself all stop destroying data, and it is kept instead until the order is lifted. Deleting a held account still removes the account; what the order covers outlives it.
What that order cannot do is make anything readable. No key is recorded when a hold is placed, and placing one runs no code that goes near a key. What is preserved is ciphertext we have never been able to open and wrapped keys we have never been able to unwrap. So we can be compelled to keep your messages and still cannot be compelled to produce what they say. Those are two different demands, and only the first one has an answer.
Two limits, stated rather than left to be discovered. A preservation order over an account necessarily preserves the other side of those conversations too, because half an exchange is not evidence of anything. And an order of this kind usually forbids telling the person it names — so neither this page nor a data export will tell you whether it is you. That is the boundary of what any statement here can honestly cover, and we would rather write it down than let it be inferred.
Cadence, signing, and how you would check it
Cadence
Every three months, on or before the same day of the month as the statement above. A statement is a new dated entry on this page, not an edit of the previous one: the history stays visible, because a canary whose old statements can be quietly rewritten is not a canary. If a statement is going to be late for an ordinary reason — illness, travel, a holiday — we will say so here in advance, and lateness with no such note beforehand is the signal, not the lateness itself.
Signing
Each statement is published as a plain-text file with a detached OpenPGP signature beside it, made by the person who operates the instance, under a key whose fingerprint is printed on this page and repeated in /.well-known/security.txt. Two publications of a fingerprint make substituting a key harder than substituting one page. The signature is what makes a statement something an operator has to personally produce, rather than a paragraph a server could go on serving by itself.
As this repository ships, none of that signing exists yet
There is no key, no fingerprint and no signature file, and there is no version of this page that could honestly print one: a signing key belongs to whoever operates a given instance, not to a source tree that anybody can clone. So what you are reading right now is an unsigned assertion on a web page, served by the same machine it makes claims about, which is worth very little. Anybody who can serve you a modified page can serve you a modified canary, and that is the same weakness as the first item on the security page.
Publishing the key and the first signed statement is what turns this from a paragraph into an instrument. Until an operator has done it, treat this page as a statement of intent, and treat any Haven deployment that presents an unsigned canary as though it were a signed one as having got the most important detail wrong.
What it would mean if this page stopped being updated
Most canaries stop here and let the reader assume. The assumption is usually far stronger than the evidence supports, in both directions.
What a missing statement would mean
Exactly one thing: that a statement due on this page did not appear. That is the whole of the signal. It is a reason to pause, to ask, to look at whether the operator has said anything anywhere else, and — if your situation is serious — to move what you are doing somewhere else while you find out. It is a prompt to act, and it is evidence of nothing in particular.
What it would not mean
It would not prove a warrant. A canary can go stale because somebody was ill, because a deployment failed, because the operator forgot, because a domain lapsed, or because the business quietly ended. The most likely explanation for a missing canary is almost always a boring one, and a reader who treats silence as confirmation will be wrong most of the time. It also cannot tell you which statement stopped being true, or when, or about whom.
And four things a canary cannot do at all, which apply to every canary anywhere
It has never been tested in court. The theory is that compelling somebody to make a false statement is harder than forbidding them to repeat a true one. It is a theory. No court in any jurisdiction has ruled that a canary works, and a jurisdiction that can compel silence may be able to compel a signature too — at which point the canary becomes an instrument for reassuring you while the thing it warns about is happening.
It cannot cover a targeted attack, which is the threat that matters here. The most dangerous demand against a service like this is not "hand over the database". It is "serve one modified JavaScript bundle to one account". A canary is quarterly and global; that attack is instantaneous and aimed at one person, who would see a perfectly current canary on a perfectly normal page while it happened.
It cannot help against the operator being the adversary. If the operator is the party you are worried about, an operator-authored, operator-signed, operator-hosted statement adds nothing. The whole instrument assumes the operator is on your side and constrained by somebody else.
It does not narrow the metadata. No statement on this page changes the fact that conversation membership is an indexed plaintext table and every message is stamped to the second. A canary that stays green forever leaves the first table in the threat model exactly as it is, and that table is where the real exposure is.
Which is the correct summary of this whole page: a canary is a small, cheap, unproven signal that is worth publishing and is not worth relying on. Use it as one input among several. If you need a guarantee rather than a signal, the honest answer is that this product does not have one, and neither does any other browser-delivered encrypted service.
Previous statements
None. Statement 1 above is the first, and every future statement will be added below it with its own date rather than replacing what is here. If you are reading this section and it is long past November 2026 with nothing added, that is the condition the section above is about.