Security & vulnerability disclosure

Machine-readable version: /.well-known/security.txt

Reporting something

Email security@onbetterterms.com with enough detail to reproduce the issue. You do not need to have a working exploit, and you do not need to be sure — a clear description of something that looks wrong is worth sending.

We aim to acknowledge a report within three working days and to tell you what we intend to do about it, including when we think it is not a problem and why.

What we ask

  • Use your own accounts. Do not read, modify, or retain anybody else’s data — the content in this product is the most private thing most people write down, and access obtained to prove a point is still access.
  • Stop at proof. Confirming that a door opens is a finding; walking through it and looking around is not necessary and we will treat it differently.
  • Give us a reasonable chance to fix it before publishing. We will not ask you to stay quiet indefinitely, and we will not ask you to delete a report.
  • Do not run denial-of-service tests, send bulk automated traffic, or attempt social engineering against staff or members.

What we commit to

  • We will not pursue legal action against anybody who follows the above in good faith, and we will say so in writing if you ask.
  • We will credit you when a report leads to a change, unless you would rather we did not.
  • If a flaw exposed member data, we will say so publicly — including when it would have been easier not to.

What happens after you send one

  1. Acknowledgement, within three working days, from a person rather than an autoresponder.
  2. An assessment, with our reading of the impact and whether we agree it is a problem. If we do not agree, you get the reasoning rather than a form letter, and you are welcome to argue with it.
  3. A fix, or a decision not to. Anything that exposes member content is treated as the most urgent thing we are doing. For the rest we will tell you what we intend and roughly when.
  4. Confirmation when it is done, so you can check the fix rather than take our word for it.

Where to send other things

Reports about a person rather than the software — abuse, harassment, or concern about somebody’s safety — should go to support@onbetterterms.com, which is read by people who can act on them, and which is watched more closely than this address.

Low-severity and scanner findings

Send them. Configuration findings — a missing header, a TLS setting, an exposed version string — are welcome and we would rather hear the same thing three times than not hear it once. We will tell you whether it was already on our list, and we will tell you honestly: claiming to have known about something after being told is the cheapest way to lose the next report, and the next report is the one that matters.

Two practical notes rather than rules. Raw scanner output with no reading of the impact takes longer to answer, because the assessment work moves to us — a sentence on why you think it matters here usually gets a faster and more useful reply. And a finding with no demonstrated impact is still a finding; it just gets a shorter answer, not a dismissive one.

There is no paid bounty programme at this time. We would rather say that plainly than imply one.