Security

Reporting a vulnerability

If you have found a security problem in this website or in one of our products, please tell us before telling anyone else, and give us a reasonable chance to fix it.

Our security address is published here and in /.well-known/security.txt as soon as the domain is confirmed. Until then, use the security route on the contact page.

A report is most useful when it includes:

• What the issue is, and which site, product or endpoint it affects.
• Enough detail to reproduce it — a request, a sequence of steps, a proof of concept.
• What you think an attacker could do with it.
• How you would like to be credited, or that you would rather not be.

You do not need to write a formal report or assign a severity score. A short email with the steps is better than nothing, and better than a polished report that arrives a month later.

What happens next

• Acknowledgement within 72 hours. A person confirming they have read it, not an automated reply.
• An assessment within five working days, saying whether we can reproduce it, how serious we think it is, and roughly when we expect to have it fixed.
• Progress updates while we work on it, so you are not left guessing.
• Confirmation when it is fixed, and agreement with you on whether and when to disclose it.

If we decide not to fix something, we will tell you that and explain why, rather than letting the report go quiet.

Scope

This website, and any product listed in ourportfolio that is marked as live. Products marked as concept or in development are not deployed for public use; if you have found something in one anyway, we would still like to hear about it.

Out of scope, because they are not ours to fix:

• Services operated by third parties, including our hosting, domain and email providers.
• Findings that only describe a missing hardening header with no demonstrated impact.
• Volumetric denial of service, and anything requiring physical access to a device.
• Reports generated by a scanner with no evidence that the finding is real.

If you report in good faith

We will not pursue legal action against you for security research carried out in good faith under this policy, provided that you:

• Do not access, modify, delete or retain anyone else's data.
• Stop as soon as you have confirmed the issue exists, rather than exploring how far it goes.
• Do not degrade, disrupt or deny service to anyone.
• Do not use social engineering, phishing, or physical intrusion.
• Give us a reasonable period to fix the issue before disclosing it publicly.

If you are unsure whether something you want to try is within these bounds, ask first.

We do not pay bounties

We do not run a paid bug bounty programme, and we would rather say so plainly than imply one exists. We will credit you by name if you want that, and we will say thank you properly.

What we do on our side

• TLS on every connection, with HTTP Strict Transport Security.
• A Content Security Policy, and the standard hardening headers, applied at the edge rather than per page.
• Dependency updates on a schedule, not only when something breaks.
• No third-party scripts, pixels or trackers on this site.

This is a small company and we are not claiming a security programme we do not have. What we have is a short dependency chain, very little running code on the public site, and an address that reaches a person.

Our role addresses are pending a domain decision. The security route on the contact page works in the meantime and reaches the same place.

Machine-readable policy

This policy is also published at /.well-known/security.txt, in the format described by RFC 9116.