legal / security

Security.

What protects the data, how the service is run, and what is not in place. The last of those is section seven, and it is the reason to read the rest. Last updated 2026-09-14. Questions go to security@kehai.io.

How to read this page

Two kinds of statement appear below and they are kept apart on purpose. Some describe how the software is built, which anybody can hold the operator to by looking at what the product does. Others describe how it is run, which is an assertion by one person.

There is also a section for what is not in place. A security page without one is a sales document. Kehai is run by a single operator and says so, because a buyer needs to weigh that rather than discover it.

The design decisions that matter most

The strongest security property of this product is how little it holds. That is not a control layered on afterwards; it is what the measurement was built to do.

visitor identityA one-way visitor code derived from the site, address, and browser, scoped to one site and one UTC day; a separate code groups each visit

salt lifetimeA new salt is used at midnight UTC. The previous day's salt is no longer used for counting, and visits do not continue into the next UTC day

raw addressesUsed for geolocation, the daily code, and rate controls. Raw IP addresses stay in rate-limit memory for up to three minutes, outside the analytics database. Infrastructure processes requests separately

browser storageNone. No cookie, no local storage, nothing written to a visitor's device

page titlesNever collected

cross-site recognitionThe visitor hash includes the site, so Kehai does not use a shared visitor code across sites

A breach of the analytics store exposes pseudonymous event rows, including their visitor and visit codes. For new measurements, those codes are scoped to one site and one UTC day. Older rows can retain visit links across midnight UTC. Page paths, query values, times, and customer-supplied properties can also provide links between events: a customer who puts an identifier in a URL has put it in the data. Salt rotation does not erase those records.

Access to an account

passwordsPassword credentials are stored as salted, one-way hashes

second factorTime-based codes and passkeys, both available to every account

stored secretsAuthenticator secrets and backup codes use XChaCha20-Poly1305 encryption. Import and Stripe connection credentials use AES-256-GCM. Google and Apple sign-in tokens are stored by the authentication library without that additional encryption layer

API keysKehai verifies keys against stored hashes. User-created keys are shown once. Managed Stripe delivery keeps an additional encrypted copy of its dedicated commerce key

sessionsKept without an address or device fingerprint, and revocable one by one

sign-in attemptsTen failed sign-in attempts lock the account for fifteen minutes

A shared report link works for anyone who has the address. That is what lets you send a report to somebody without an account, and it is said plainly rather than hidden behind a word. Links can be revoked. The panel shows recorded openings, but a failed counter update can miss an opening.

Where it runs

primary infrastructureOVHcloud, Warsaw, Poland

backupsOVHcloud object storage in Warsaw, verified on September 10, 2026. The recovery test scope is described below

public trafficCloudflare, which decrypts requests and can therefore read them

databasesNot reachable from the public internet

error reportsKehai's own error tracker on the same OVHcloud server. Request headers, cookies, bodies and queries are removed, and recognized identifying or secret patterns are redacted before sending. Unrecognized information can remain in error text or paths. The tracker is configured for a 30-day event retention window, followed by scheduled cleanup. Backup expiration is separate

deploymentNo release ships without passing the automated checks

Cloudflare processes public requests. Email providers also receive account messages and enabled aggregate reports. The sub-processor list describes those separate paths.

Backups and recovery

Product backups coordinate a recovery point for both databases, with a daily schedule and a seven-day pruning window. Separate machine backups also run. The OVHcloud bucket is in Warsaw and its lifecycle makes backup objects eligible for expiration after eight days. Provider deletion is asynchronous, so eligibility is not proof that every copy has already gone.

visitor saltsCoordinated product backups exclude visitor salts. Machine backup logical dumps are also configured to exclude them. This is not a guarantee about every older archive or storage copy. Event rows and recorded codes have their own backup window

immutabilityNot claimed. Product copies are pruned after seven days and the bucket has an eight-day expiration rule. Object Lock and versioning were not enabled at the September 10, 2026 verification

credentialsBackups use the project's storage bucket, shared across its customer accounts. The bucket mapping does not by itself establish the credentials' effective permission scope

failureThe coordinated product backup rejects a failed dump. The separate machine backup script was corrected on September 10, 2026 to stop on failed database captures and withhold publication of an incomplete recovery point

testingOn September 10, 2026, isolated exercises restored synthetic product data through OVHcloud object storage and existing production cloud archives. Fresh captures from the corrected machine script were then restored into five disposable PostgreSQL instances and one ClickHouse database. Kehai's fresh restored salt table was empty. These checks did not boot all applications on a rebuilt host or establish a production recovery time

The recorded exercises verify those archives and database recovery paths. Complete-machine recovery and validation of every historical archive remain separate operational checks. Older archives were not rewritten by the repair.

Deleting things

a siteStops being readable at once, then is erased after a grace period

erasure scopeEvery analytics row for that site, checked against the hostnames it holds

retentionPer site, ten choices from 30 to 3,650 days, within the retention allowance. Expired rows become eligible for deletion in database background merges. Backups have a separate window

auditWho did it and when, kept under the account that owned the data

The erasure check exists because a store number means different things in different databases, and an erasure aimed with one database's answer at another's data is the mistake that cannot be taken back.

What is not in place

Stated because a buyer's risk assessment needs it, and because a page that omits this is not worth reading.

A single operator

Kehai is built and run by one person. There is no team to separate duties between, no on-call rotation, and no second pair of eyes on a production change. Support hours and response targets are what the Terms say and no more.

No enforced second factor for administrators

Two-factor authentication is available to every account. It is not a requirement for accounts with administrative access.

No external audit or certification

There is no SOC 2 report, no ISO 27001 certificate, and no third-party penetration test. Nothing here has been verified by anyone but the operator.

No automated dependency scanning

Dependencies are reviewed and updated deliberately. No scanner watches them and opens a ticket when an advisory lands.

Reporting something

Write to security@kehai.io with enough detail to reproduce it. We aim to reply within one business day. This is a target for the first human reply, not a guaranteed response or resolution deadline. Business hours are Monday to Friday, 9:00 to 17:00 Europe/Warsaw (CET/CEST), excluding Polish public holidays.

No bounty is offered and none is implied. Nobody will be pursued for a report made in good faith that stops at demonstrating the problem and does not reach other people's data.