Security

1. Workspaces are kept apart

• Every company’s data sits in a separate workspace. The database enforces that separation itself with row-level security, so a mistake in application code should not be able to read another workspace’s rows. Every signed-in request runs inside the one workspace it belongs to.
• The application’s database account cannot switch the protection off. Our own staff console uses a separate account and separate sign-in, and everything staff do in a workspace is written to an audit log.
• Private tasks and direct chats are visible only to the people in them, not to managers or owners.

2. Encryption

• In transit: the web app and the API are served over HTTPS (TLS), with HTTP Strict Transport Security.
• At rest: the servers’ disks are encrypted. In addition, face templates, review copies of selfies and authenticator secrets are encrypted by the application itself (AES-256-GCM) with keys that are not stored in the database.
• Passwords are stored only as argon2id hashes. Kiosk PINs are hashed too, and device identifiers are stored as keyed hashes.

3. Who can do what

• Roles (member, HR manager, administrator, owner) decide what a person can see and change. HR managers can be limited to their own teams.
• Owners and administrators sign in with a password and an authenticator code. Sensitive actions (billing, changing owners, shortening retention, erasing people, deleting the workspace) ask for the password and a code again. Adding an owner has a safety delay.
• Sign-in sessions use short-lived access tokens (15 minutes) and rotating refresh tokens; if a refresh token is used twice, we treat it as theft and end the session. Ending someone’s access also ends their sessions, calls and live connections.
• Requests are rate-limited, and the sign-in and public forms are protected against automated abuse (Cloudflare Turnstile on the contact form).
• Security-relevant actions are written to an append-only audit log that the application cannot change or delete.

4. Face data

• Face check is optional, off unless the company turns it on, and needs each person’s explicit consent. People who decline can use a kiosk PIN or badge, or a manager’s approval.
• We store an encrypted numerical template, not a photo. The selfie is processed in memory and dropped. A selfie that does not match is kept as a small encrypted review copy for a manager for at most 30 days.
• Matching runs on our own servers with an open-source model; no outside face-recognition service receives anything. Templates are never exported and are deleted when consent is withdrawn.
• Location, where a company asks for it, is reduced to inside or outside; the coordinates are not stored.

5. Files and calls

• Uploaded files are scanned for viruses, kept in private storage and opened only through short-lived links (a few minutes). Data exports are available through a 15-minute link and deleted after 24 hours.
• Audio and video calls run through our own server (LiveKit) and are not recorded. The size of a call depends on the plan.

6. The web app

• A strict Content-Security-Policy with a fresh nonce on every page load: no inline scripts without it, and only the services a page needs. Standard headers (no framing, no content sniffing, a restricted referrer, a locked-down permissions policy where only the attendance pages may use the camera) are on every response.
• Sign-in tokens are kept in the browser’s local storage, which a script injected into the page could read. The strict policy above is our main defence; we plan to move the refresh token to an HTTP-only cookie.

7. Reviews and what we have not done

• The code has been through repeated review rounds carried out separately from the people who wrote it. Every finding is recorded with its severity and how it was fixed, and each fix has a test. Automated tests check, among other things, that people cannot reach another workspace’s data.
• Not done yet: an external penetration test, and certifications such as SOC 2 or ISO 27001. We will say here when that changes, and we do not claim them until then.
• Backups and disaster recovery: [to be completed by the owner before launch]. The breach-notification procedure is [to be completed before launch].

8. Reporting a problem

If you think you have found a security problem, please write to [security@your-domain] with the steps to reproduce it. Please do not access other people’s data, and give us a reasonable time to fix it before you tell anyone else. We will acknowledge your report and keep you informed.