Security you can check.

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].

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.

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. An account has at most one session in the phone app and one in a web browser: a new sign-in ends the earlier session of its kind. Settings → Security on the website lists your sessions and signs out any other one; a browser signed out this way can keep working for up to five minutes. A password reset ends every session.

Authorization

Every request is authorized in the application. On the tables that hold your inventory, comments, messages, history, shares, groups and estates, the database checks again: PostgreSQL row-level security, enabled and forced on each of them, returns only the rows the signed-in person may see, even if a query in the application forgets to filter. Another person’s account record is readable that way only by KindlyQR’s administrators and by people related to them through a share, a group, a comment or a dibs request, or through a conversation, which any KindlyQR user can start with any account. Marketplace listings, their photos and store pop-ups have no row-level security: who may see a listing and who may change it are checked by the application alone. The table that records which accounts share with each other, which the database fills from the shares, has none either. Routes that work on credentials or across accounts, such as sign-in, notifications to other people, estates, the marketplace and payments, use a database role that bypasses row-level security: there the application limits every query to what the caller may see or change, and the database does not check it again.

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 permission test of more than 400 cases 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.

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

Delete your account in Settings, or e-mail [email protected]. Your inventory, media, shares and credentials are removed. Messages and comments you wrote to other people stay with them as written, shown as from “Deleted user”. In other people’s records that name you (who received what from whom, their item history, activity feed and notifications), your name is replaced with “Deleted user” and your e-mail is removed. Copies that remain: anything other people typed that names you, such as comments and messages; activity-feed and usage records from before a September 2026 database change, until a later change drops them; nightly database backups, each kept 30 days and deleted a day later; the off-site media mirror, which only ever adds files, so your photos and recordings stay in it with no expiry; the customer and payment records Stripe holds; and e-mails and push notifications already sent.

Export

Your items export to a spreadsheet at any time from the items page.

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.

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.

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.

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.

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. A second internal audit, in October 2026, reviewed the application, its database roles, the phone app and the production server. It found no critical issues and three high-severity ones, which were fixed and deployed on October 22, 2026. The most recent dependency security updates shipped the same day.

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.

OpenStreetMap (Nominatim)

Turning a home or pop-up address into map coordinates.The address, sent by our server with no name or account details. United Kingdom.

OpenStreetMap (map tiles)

Map images on the Near me map and the store location picker.Your browser loads them directly, so the tile servers see your IP address and the map area you view. United Kingdom.

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.

Privacy Policy

What we collect, why, and what you can do about it

Terms of Service

The agreement between you and Lightover

security.txt

Machine-readable security contact (RFC 9116)

Live release

The commit serving kindlyqr.com right now

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