Trust & Safety
Reporting a security issue
If you have found a vulnerability in DiemDesk, we want to hear about it and we will not come after you for telling us. This page says where to send it, what is in scope, what we will do, and how long we will take.
Last updated August 2026
Where to send it
[email protected]. If that bounces, use [email protected] with “security” in the subject. Machine-readable details are at /.well-known/security.txt.
What to include
A report we can act on quickly usually has:
- the URL or tool affected, and which browser you were using;
- the steps to reproduce it, in order — a short recording is welcome;
- what an attacker could actually achieve with it;
- anything that would help us confirm it, such as a request or a payload.
Please do not include real personal data belonging to anyone else in a report. If a proof of concept needs a document, use one you made up.
What we will do
- Acknowledge within 3 working days — a human, not an autoresponder.
- Give you an assessment within 10 working days: whether we could reproduce it, how serious we think it is, and what we intend to do.
- Keep you updated while we fix it, and tell you when it ships.
- Credit you if you would like it, by whatever name you choose. We will not name you without asking.
- Say so if we disagree, with our reasoning, rather than going quiet.
We are a small team and we do not run a paid bounty programme. We would rather be straight about that than imply a reward that is not coming.
In scope
diemdesk.comand its subdomains- the API at
diemdesk.com/api - the in-browser tools, including anything that would cause a file to leave the device when it should not
- File Vault, and anything touching its end-to-end encryption
- authentication, session handling and the billing flow
The finding we most want
Our central claim is that the in-browser tools never transmit your file. If you can show one of them sending file content anywhere — through any request, any beacon, any error report — that is the most valuable report you could send us, and we will treat it as critical.
Out of scope
- reports generated by a scanner with no demonstrated impact
- missing headers or a missing best-practice flag with no working exploit
- issues that need a rooted, malware-infected or physically compromised device
- social engineering of our team or our users, and phishing
- rate limiting on unauthenticated public pages
- vulnerabilities in third-party services we use — report those to them; their policies are linked from our subprocessors page
Please do not
- run denial-of-service or volumetric testing against production;
- access, alter or keep data belonging to anyone but yourself — stop as soon as you have proved access is possible;
- use a finding to reach further into our systems than the finding requires;
- publish before we have had a reasonable chance to fix it.
Safe harbour
If you research in good faith and within this policy, we will treat it as authorised. We will not pursue legal action against you, we will not ask your internet provider to act, and if a third party brings a claim about research that followed this policy we will make clear that it was authorised.
If you are not sure whether something is allowed, ask first. We would much rather answer a question than receive an apology.
Disclosure timing
We ask for 90 days before public disclosure, and less if we have already shipped the fix. If we go quiet or you think we are not taking it seriously, tell us that too — we would rather be pushed than have you sit on it indefinitely.