If you have found a security problem, here is how to tell us.
This page is the policy referenced by security.txt. It says where to send a report, what happens after you do, what we will and will not do in response, and what is out of scope. It is deliberately short, because a policy nobody finishes reading is a policy that does not work.
How to report
Email the address in security.txt. Include enough for us to reproduce the problem — a description, the steps, and what you saw. If you have a proof of concept, send it; if sending it would require us to attack somebody else's account, describe it instead.
Please do not test against other people's accounts or data. Register your own, or ask us and we will make you one. Everything in this product is end-to-end encrypted, which means a test against a stranger's conversation is not a test — it is the thing the product exists to prevent.
What happens next
We aim to acknowledge a report within two working days and to tell you what we think of it within ten. Those are targets, not a contract: this is a small team without a night shift, and saying otherwise would be a promise we could not keep at three in the morning. If a report is serious we will say so quickly and keep you updated while we fix it.
We work to a 90-day coordinated disclosure window: publish after 90 days, or earlier once a fix has shipped, whichever comes first. If a fix needs longer we will say why and agree a date with you rather than letting the clock run out quietly. We will credit you by whatever name you choose, and will not name you if you would rather we did not.
Where a problem affected people's data, what we tell our customers is governed by the data processing addendum, not by this page.
Safe harbour
If you make a good-faith effort to follow this policy, we will treat your research as authorised, will not pursue or support legal action against you for it, and will say so if anybody else asks us. Good faith means: you stay inside the scope below, you do not access or modify data that is not yours, you do not degrade the service for other people, and you give us a reasonable chance to fix the problem before you publish.
This assurance is ours to give and covers only us. It cannot bind a third party whose service you also touch, and it is not legal advice.
Scope
In scope: the hosted service and its API, the web client we serve, the operator console, the published source, and the way any of them handle keys, sessions, payments or somebody else's data.
Out of scope, because a report about one of these tells us nothing we can act on:
- denial of service, traffic floods, and anything whose impact is "it went slower";
- social engineering of us, our suppliers, or our customers;
- physical attacks, and attacks that assume a device already compromised — a compromised device defeats end-to-end encryption and the threat model says so;
- missing headers, weak ciphers or version disclosure with no demonstrated impact;
- self-XSS, and issues that require a victim to paste attacker-supplied code into their own console;
- reports generated by a scanner with nothing added — we read those last, if at all.
There is no bounty, and here is the honest reason
We do not pay for vulnerability reports. Neither do Signal, Matrix or Element, and we would rather say that plainly than run a programme whose rewards are too small to be worth anyone's time.
What we do instead: we answer, we fix, we credit you, and we say what happened. If that changes — if there is ever a budget for it — this page will say so before anybody has to ask.
What we already know
Haven has not had a professional security audit. That is stated at the bottom of every page on this site and it will stay there until it is untrue. The threat model lists what this product does not defend against, and the security page lists what it does not protect. A report that one of those is true is not a vulnerability report — but a report that one of them is understated very much is, and we would like to receive it.