Security & Vulnerability Disclosure

Email [email protected]. Please include enough detail for us to reproduce the issue: the affected product and version, the steps you took, what you expected, and what actually happened. Proof-of-concept code, screenshots and request/response captures are all welcome.

If you would prefer to encrypt your report, say so in a first message and we will send you a key. Do not include third-party personal data in your report; describe the access you obtained rather than sending us the data itself.

• Acknowledgement within 72 hours of your report reaching us.
• An initial assessment within 7 days — whether we can reproduce it, our severity view, and what we intend to do.
• Progress updates at least every 14 days until the issue is resolved or we explain why it will not be.
• Credit in the release notes for the fix, if you want it. Tell us how you would like to be named.

We do not currently run a paid bug bounty. We will say so plainly rather than leaving it ambiguous: reports are handled on the basis of good faith and public credit, not payment.

If you make a good-faith effort to comply with this policy while researching a vulnerability, we will not pursue or support legal action against you, and we will make it known that your research was authorised if a third party raises it.

Good faith means, concretely, that you:

• give us a reasonable opportunity to fix the issue before disclosing it publicly — 90 days is our default expectation, and we are happy to agree a different timeline;
• access only the minimum data needed to demonstrate the problem, stop as soon as you have demonstrated it, and delete anything you retrieved;
• do not degrade service for others — no denial-of-service testing, no automated scanning that generates significant load, no spam;
• do not access, modify or delete data belonging to anyone else, and do not use social engineering, phishing or physical attacks against our staff or users.

This safe harbour is ours to give and covers our own services and software only. It cannot authorise you with respect to third-party services we happen to use.

In scope: the Ortix Browser macOS application and its update mechanism; systembionic.com, api.systembionic.com and their APIs; the Xified application; and our account, subscription and entitlement systems.

Out of scope: findings in third-party services we use rather than operate (report those to the provider); reports generated solely by an automated scanner with no demonstrated impact; missing security headers or TLS configuration preferences with no exploitable consequence; social engineering of our staff or customers; physical attacks; and denial of service.

If you are not sure whether something is in scope, report it — we would rather triage an out-of-scope report than miss a real one.

We provide security updates for the Ortix Browser for at least five years from the date a version is first made available, or for the expected lifetime of the product if that is shorter. Security updates are delivered through the app's built-in updater.

Updates are signed with an EdDSA key whose public half is compiled into the application, and the application verifies that signature before installing anything. An update that does not carry a valid signature is rejected, so a compromised network or a compromised update server cannot cause Ortix to install modified software.

We will announce the end of the support period for a given version before it takes effect.

Security reports: [email protected].

Machine-readable version of this policy: /.well-known/security.txt (RFC 9116).

For anything that is not a security issue, please use our support page instead — it will reach the right people faster.