Reporting a security problem

How to report

Write to [email protected]. Put “Security report” in the subject so it is not read as an ordinary support question.

Encrypt the message if you can. Our public key is at private.ki/pgp/[email protected], and the contact page shows the same key with its fingerprint so you can compare the two before you encrypt to it. An unencrypted report is still welcome — do not let the lack of a PGP setup stop you from writing.

Please include:

What you found: the vulnerability in one or two sentences.
Where: the exact host, URL, app screen or endpoint.
How to reproduce it: step by step, from a clean state, with the account or client you used.
A proof of concept: a request, a short script, a recording. Anything we can run ourselves.
What an attacker could actually do with it: the impact as you see it, including what it would take to pull off.

If you need a reply to reach you at an address other than the one you wrote from, say so in the message.

What we will do

Acknowledge within 72 hours. A person confirms the report has arrived.
A substantive update within 7 days. Whether we could reproduce it, how we rate the impact, and what happens next.
A fix for critical issues within 30 days. That is our aim, not a guarantee. If something will take longer we will tell you so, and why, rather than going quiet.

Safe harbour

If you research in good faith and stay within the scope below, we will not take legal action against you and we will not refer you to law enforcement. We will treat your work as authorised. This is the part of the policy we take most seriously: nobody should have to weigh up a lawyer before telling us our software is broken.

The conditions are the ordinary ones:

Use your own accounts. Do not access, modify, delete or copy out anyone else's data. Sign up for as many test accounts as you need.
Stop at proof of concept. Once you have shown the problem exists, stop. Do not go further to see how much more you could reach.
Do not degrade or disrupt the service. No load testing, no flooding, nothing that affects other people's use of Private.Ki.
No social engineering. Not against our people, not against our users, not against our suppliers.
Keep it confidential until the issue is fixed, or for 90 days from your report, whichever comes first.

This promise is ours and ours alone. We cannot give you safe harbour from anyone else — our hosting providers, app stores, network operators, or any third party whose systems you touch on the way. Their rules still apply to you, and we cannot waive them.

In scope

The web app and the API behind it.
This website, private.ki, including the help center.
The Private.Ki apps for Android and iPhone, pre-release builds included.
Our mail infrastructure.

The reports worth most to us are the ones that touch key handling, the end-to-end encryption, or the boundary of what our servers can see. Anything that would let our servers — or anyone who compromised them — read what they are not supposed to read is the most valuable thing you can send us, whatever its formal severity rating.

Out of scope

These are not accepted, because they cost us time we would rather spend on real problems:

Output from an automated scanner with no working proof of concept.
Missing security headers with no demonstrated impact.
Opinions on our SPF, DKIM, DMARC or DNS configuration without a real attack built on them.
Self-XSS — anything that requires the victim to paste something into their own console.
Clickjacking on static pages.
Missing rate limiting with no demonstrated impact.
Denial of service and volumetric attacks of any kind.
Social engineering and phishing, including reports that you could phish our users.
Physical attacks on our offices, our staff or our hardware.
Third-party services we do not run.
Outdated library versions with no working exploit against us.
Anything already publicly known, or already reported by someone else.

Rewards

We do not run a paid bug bounty. There is no published reward table, no severity-to-money scale, and no entitlement to a payment.

We may offer a reward at our discretion for a report that is genuinely high-impact and well made, and we will say so when we do. What we offer as a matter of course is credit: your name, handle or project on this page, if you want it.

Acknowledgements

We name the people who report security problems to us, with their permission, here. You can ask to be credited under any name you like, or to stay anonymous — we will not publish anything about you that you have not agreed to.

The list is empty today. This policy is new; the first entries will appear as reports come in and are fixed.

Why there is no bug bounty

A published reward table mostly attracts scanner output. Sorting through it would take the same hours we use to fix the problems people actually find, and we are a small team. We would rather answer every real report quickly than process a large volume of automated ones slowly.

Machine-readable version

The same contact details are published as /.well-known/security.txt in the format of RFC 9116, with this page as its policy URL.

Our What our servers can and cannot see page sets out the boundary this policy asks you to test. How our encryption works describes the key handling. Abuse of an account — spam, phishing, harassment — is not a vulnerability report; use Report abuse for that.