KindlyQR

Trust & Security · updated September 16, 2026

Security you can check.

What protects your inventory, your family’s estate records and your photos: the controls in place today, who else touches the data, and how to report a problem.

01 · Overview

One product, one server, no badges we haven't earned.

KindlyQR is built and operated by Lightover Inc. It stores things people care about: what they own, where it is, who it is meant for, and the photos and recordings that go with it. This page describes how that data is protected as the system actually runs.

KindlyQR holds no SOC 2, ISO 27001 or similar certification today. It is a small company at launch. What it has instead is listed below, and every item can be verified by asking [email protected].

02 · Infrastructure

Where your data lives and how it gets there.

Hosting
A dedicated server operated by us in the United States (San Diego, California). Not a shared multi-tenant cloud account.
In transit
Every connection is TLS through Cloudflare, with HTTP Strict Transport Security for a year including subdomains. The server accepts traffic only through Cloudflare’s tunnel; the application, the database and the media store listen on localhost alone, with no public ports.
Browser protections
Frames denied, content-type sniffing off, referrer trimmed, and camera, microphone and location usable by KindlyQR only.
At rest
Backups are encrypted at rest by the backup provider, in a bucket only our own systems can reach.

03 · Access

Who can see what, enforced twice.

Sign-in
Passwords are hashed with Argon2 and never stored or logged in the clear. Sign-in confirms with a one-time code sent to your e-mail. Sessions are per device and can be revoked.
Authorization
Every request is authorized in the application, and then again by the database: PostgreSQL row-level security policies on every table that holds your content mean a query can only return rows the signed-in user is allowed to see, even if application code is wrong.
Sharing
Nothing is visible to another person until you share it: to a named user, an e-mail address or a group, at view, edit or admin level, revocable at any time. A 97-case permission test runs against a copy of production before any change to sharing ships.
Abuse limits
Every authenticated call is rate-limited per user, across all server processes.
Operator access
Access to the server is by SSH key over a private network. There is no support tool that browses customer content; the operator queries the database directly only to resolve a problem you have reported.

04 · Your data

Yours. Not sold, not used to train anything.

Ownership
Your inventory, photos, recordings and estate records are yours. We do not sell them, share them with advertisers, or use them to train machine-learning models.
AI scanning
When you choose to scan an item, that photo is sent to Google’s Gemini API to identify it and the result is written into your item. Nothing is sent unless you press the button.
Payments
Card and bank details are entered on Stripe’s forms and stored by Stripe. KindlyQR never receives them.
Error reports
When error reporting is enabled, a report carries the failing request, its stack and your user id, never your content.
Deletion
E-mail [email protected] and your inventory, media, shares and credentials are removed. The audit history other people rely on (who received what in an estate) keeps an anonymised record of your account, never your name or e-mail.
Export
Your items export to a spreadsheet at any time from the items page.

05 · Continuity

If the server dies tonight.

Backups
A full database dump and a mirror of all media go off-site every night to an encrypted bucket, using a key that can write but cannot delete. Retention is enforced by the provider, so a compromised server cannot erase its own backups.
Restore drill
Every week an automated job downloads the latest backup, restores it into a scratch database and checks the data. A backup that cannot be restored fails the check and alerts us.
Monitoring
The site is probed from outside on a schedule and the backup chain is verified daily. /api/health shows the exact release serving right now.
Recovery
A written runbook rebuilds the service on a new machine from the off-site backup.

06 · Engineering

How changes reach production.

Review and tests
Every change is a pull request that must pass automated unit, route and browser tests before it can merge. The main branch is protected; nothing is force-pushed to it.
Dependencies
Locked to exact versions, audited for known vulnerabilities weekly and on every change. A critical or high advisory in a production dependency fails the build and is patched before anything else ships. Build actions are pinned to exact commits.
Secrets
No credential is committed to source; every change is scanned for secrets before it can merge. Secrets live only on the server and in the deployment system.
Releases
Each deploy is an immutable git commit, switched atomically with a health check that rolls back automatically on failure. Rollback to the previous release is one command.
Database changes
Any change to access policies is proven on a copy of production to leave tenant isolation byte-for-byte identical before it ships.

07 · Reporting a vulnerability

Tell us, and here is what happens.

Write to [email protected]. The same address is published at /.well-known/security.txt. Reports about one user seeing another’s data, access that was not granted, or money moving incorrectly are read first.

Acknowledgementwithin 2 business days
Triage and severitywithin 5 business days
Fix for a critical or high findingdeployed within 7 days of triage
Fix for a medium findingwithin 30 days
Fix for a low findingnext scheduled release
Crediton request, once the fix is live

Test only against accounts you created, stop as soon as you have shown the issue, and do not run denial-of-service tests. Reports that follow those rules are treated as good-faith research and will not be met with legal action.

08 · Track record

What has been audited, and what was found.

An internal security audit of authorization, tenant isolation, injection, cross-site scripting and payments was completed in August 2026. Its two high-severity findings were fixed and verified in production the following day. Dependency advisories are patched as they appear; the most recent batch shipped on September 14, 2026.

09 · Subprocessors

Every other company that touches your data.

Cloudflare
TLS, CDN, the tunnel to our server, e-mail routing.All web traffic in transit; no stored content. United States.
Backblaze B2
Nightly encrypted off-site backups.Database dump and media mirror, encrypted at rest. United States.
Stripe
Payments, subscriptions and seller payouts.Card and bank details go to Stripe directly and never touch our servers. United States.
Postmark
Transactional e-mail (sign-in codes, invitations, notifications).Your e-mail address and the message content. United States.
Google Gemini API
Identifying an item from a photo you choose to scan.That photo, for that request; we use the result for nothing else. United States.
Expo
Push notifications to the phone app.A device push token and the notification text. United States.
GitHub
Source code, automated tests and deploys.No customer data. United States.
Sentry
Crash and error reports (being enabled).Error details and your user id only; never your content. United States.

A line is added here before any new service receives customer data.

10 · Documents

Read the rest.

11 · Contact

Lightover Inc.

Security questions, documentation requests and vulnerability reports — [email protected]. Questions about your data — [email protected].