Security model

Resistance, stated honestly.

KairoLock aims to make common self-bypass methods materially harder. It does not claim to prevent every bypass, and no bypass-resistance claim is marked verified before the Windows red-team suite passes.

Pre-release status: Windows enforcement testing is incomplete. Descriptions below are design targets and system boundaries, not verified performance claims.

Threat model

The intended adversary is the authorized device owner acting impulsively and attempting common local bypasses. The model does not promise resistance against a determined expert with physical access, modified hardware, alternate boot media, operating-system compromise, or destructive data loss.

Verification before claims

Release candidates must be tested against the documented red-team matrix. The public changelog and security page will distinguish tested behavior, known limitations, and unresolved cases.

Server-side entitlement

Trial and subscription state live on the authenticated server account in Supabase; entitlement is granted by the server, not by a file on your device. Privileged database and Paddle credentials remain on the server and are never embedded in the desktop client.

Data minimization

The website needs no login, and sets no advertising or tracking cookies; it counts page views in aggregate with Vercel Web Analytics, which uses no cookies and strips the checkout transaction id. The cloud layer stores only the Google sign-in identity, Paddle billing references, entitlement state and release data needed to operate the product. What you block, and when, stays on your device. The privacy notice lists every processor.

What KairoLock does not claim

Mathematical or absolute unbreakability.
Protection after the operating system or account is fully compromised.
Prevention of every recovery, repair, or destructive action available to a device owner.
Verified resistance to any bypass case that has not passed repeatable testing.

Reporting a vulnerability

If you believe you have found a security problem in the KairoLock application, service or website, report it to kairolock0@gmail.com. We do not publish a PGP key; if a finding is too sensitive for plain email, say so in a first message with no detail and we will agree an encrypted channel with you.

Please include what you found, how to reproduce it, and the version or URL affected. Reports in any language are fine. We do not run a paid bug bounty; we will credit you by name in the changelog if you want the credit and the fix is shipped.

What we commit to

We acknowledge a report within 3 business days.
We tell you our assessment and a fix plan within 14 days of acknowledging it.
We ask that you give us 90 days before publishing, and we will tell you if a fix will take longer than that.
We keep you informed while a fix is in progress, and we tell you when it ships.

Please do not

Access, modify or delete data belonging to anyone but yourself.
Run denial-of-service, spam or physical attacks against the service or its providers.
Test against another person's device or account.

Safe harbour

If you research in good faith within the rules above, we will not bring or support a legal claim against you for it, and we will say so to anyone who asks. This is our own commitment: it cannot bind a third party whose systems you reach, and it does not apply to research that harms a user, destroys data, or continues after we have asked you to stop.

Effective 6 October 2026