Privacy Policy

What biometric data is collected

Enrolled face photos and embeddings. When someone is enrolled as an authorized person, their photos are processed into face embeddings — fixed-length numerical vectors that represent facial geometry, generated by a neural network. An embedding is not a photo and can't be trivially reversed back into one, but it is still biometric data derived directly from someone's face, and is treated as sensitive. The source photos themselves are used during enrollment and are kept (encrypted — see "How it's stored" below) so re-enrollment (e.g. adding more angles later) doesn't require re-collecting photos from scratch.

Detection snapshots. When the live system flags an unrecognized or low-confidence ("borderline") face — or an authorized match that hasn't yet been liveness-verified — it saves a snapshot image of that moment for operator review. See the About / Tech page for how the three-tier confidence system and liveness detection work.

Face detection and matching run locally, on the same machine and in the same process as the camera capture itself — a frame is compared against the locally-stored, encrypted embeddings database in memory. We have not found, anywhere in this codebase, code that sends a camera frame, a face photo, or an embedding to any external service. We describe this as our best current understanding of the code rather than an absolute guarantee, since a "no such code exists" claim can only ever be as strong as the review that produced it.

Camera recording. Where recording is enabled for a camera, continuous video is written to local storage, encrypted at rest with its own dedicated key — the same "encrypted with a dedicated key" treatment as every other data category on this page, described in "How it's stored" below. This is a materially larger volume of data than the enrolled photos or detection snapshots described above, since it captures continuous footage rather than moments the system specifically flags. Retention is admin-managed rather than fixed to a set number of days; recordings are cleaned up according to that configuration, not kept indefinitely by default.

Why it's collected

Solely for access monitoring — matching faces seen by a camera against the enrolled roster of authorized people, and flagging anyone the system doesn't recognize. Biometric data collected here is not used for any other purpose (no marketing, no profiling, no analytics beyond the access-monitoring function itself).

Consent for enrollment

Enrollment is not automatic or passive — it requires an operator to deliberately add photos of a person and run the enrollment process. As of this update, that process also requires the operator to affirmatively confirm, at the moment of enrollment: "I confirm that the required written consent has been obtained from this person for their biometric information to be enrolled and used for this purpose." That confirmation is recorded — who confirmed it, when, and which version of this notice they were shown — as an internal record.

What this is, stated plainly, and what it is not: this is the operator attesting that consent was already obtained from the enrolled person through some process outside this system (for example, a signed paper form) — it is a record of the operator's confirmation, not a mechanism by which the enrolled person themselves grants consent directly to this system. Clicking this confirmation does not, by itself, constitute the enrolled person's own legal consent under any specific framework. If that person's roster entry is later removed, any consent-confirmation record tied to them is marked withdrawn, but the record itself is kept for our own internal accountability trail rather than deleted outright.

Whether operator attestation of this kind is an adequate legal basis for a specific enrollment, in a specific jurisdiction, is a question this policy does not attempt to answer — see "Jurisdiction" below.

Customer accounts & requesting access

The Request Access form collects your full name, email, and company/organization (all required); a description of your intended use (required); and, optionally, a phone number, an approximate camera count, and any deployment requirements you'd like to share. Every request is reviewed personally by an admin — there is no automatic approval.

If a request is approved, we create an account record (keyed by your email) and send an activation email containing a one-time link, valid for 72 hours and usable only once, so you can set your own password. That activation email is sent through a third-party email provider — see "Third-party services" below. Once activated, your account record stores your full name, company, email, account status, and a randomly-generated account identifier used internally to tie your account to any product license (see "Your Neo license" below) — this identifier is not your email or name, deliberately, so a license record on its own doesn't reveal who you are.

A customer account is a different kind of account from an operator (dashboard) login — see "Operator vs. customer accounts" below. It currently gives you access to a portal showing your account and license/installation status. As displayed plainly in that portal today: camera setup and Authorized People management are not yet available to customer accounts — those remain operator/admin-only functions for now (see "Authorized People" below).

If your request is not approved, or you never hear back, the information you submitted is retained until an admin deletes it — see "Deletion & your rights" below for how.

Your Neo license & installation

If you activate a Neo installation from your customer portal, that installation is cryptographically tied to your account using a signed License Certificate — a record proving your installation is associated with your account and stating your camera-count entitlement. Your installation periodically "checks in" with our server (roughly every 12 hours under normal conditions) and, if everything checks out, receives a short-lived renewal token that lets it keep running. If your installation is temporarily unable to reach our server, it keeps operating on its last valid renewal for a bounded grace period (currently up to 7 days) before it would need to reconnect.

What actually crosses this boundary is deliberately minimal: an installation identifier (generated locally by your installation, not derived from your name, email, computer name, or any other personal identifier), your account identifier (the same random, non-identifying value described above), your camera-count entitlement, and check-in timestamps. This check-in traffic never carries face photos, face embeddings, camera footage, or recognition events — those stay local to your installation, as described in "What biometric data is collected" above.

An admin can revoke an installation (for example, if an account is closed). Revocation stops future renewals rather than shutting the installation off instantly — it continues operating on its last valid renewal until that expires, then requires reactivation. Deleting a customer account revokes every installation tied to that account as part of the same action.

Authorized People (roster access)

"Authorized People" is an internal, operator-managed setting that controls which enrolled-person names a given operator dashboard account can see or manage in the roster/enrollment screens — it is not, today, a customer-facing feature. Customer accounts have no access to this setting, cannot view or manage the enrolled roster, and are not involved in this access-control list at all. This is an explicit, current scope limitation, not an oversight — camera setup and self-service Authorized People management for customer accounts are on our future roadmap but do not exist yet.

How it's stored, and for how long

Everything described on this page is stored locally on the server's own filesystem — there is no cloud storage and no third-party database for any of it. What's encrypted, and what isn't, differs by data type, described honestly below rather than glossed over:

• Face embeddings — encrypted at rest, with a dedicated key stored in a separate file, never committed to source control.
• Enrollment photos — also encrypted at rest, with their own separate dedicated key (distinct from the embeddings key).
• Detection snapshots — not currently encrypted at rest. This is a real, disclosed gap between how enrollment photos are protected and how detection snapshots are protected today, not an intentional design choice we consider finished.
• Customer account and account-request records, consent-confirmation records, and license/installation records — stored as plain (unencrypted) local files. Passwords within these records are one-way bcrypt-hashed, never stored or recoverable in plain text.

None of this protects against someone who gets direct access to the key files themselves, or live access to the running system (data is necessarily unencrypted in memory while actually being used). Stated honestly rather than glossed over: this is encryption at rest for specific sensitive categories, not a defense against a fully compromised host. See this project's README (threat model section) for the full, specific breakdown of what is and isn't protected today.

Retention, by data type:

• Enrolled photos and embeddings — retained until manually removed by an admin; no automatic expiration exists.
• Detection snapshots — no automatic, scheduled, or default retention period exists in the system today. An admin can delete a specific snapshot, or bulk-delete every snapshot older than an age (in days) the admin explicitly chooses at the time they run that action — but nothing deletes a snapshot on its own. Until an admin acts, a snapshot persists indefinitely.
• Consent-confirmation records — kept indefinitely as an internal accountability record, even after the associated person is removed from the roster (at which point the record is marked withdrawn rather than deleted).
• Account requests (submitted via Request Access, whether later approved, rejected, or never actioned) — retained until an admin deletes the record. An admin-operable deletion capability now exists for this specifically (including for rejected requests, which previously had no deletion path at all).
• Customer account records — retained until an admin deletes the account. An admin-operable deletion capability now exists and, when used, also revokes every license/installation tied to that account and deletes the original Request Access record that led to the account, so no separate copy of that intake data is left behind.
• License/installation records — retained indefinitely; revoking an installation sets a flag on its record rather than deleting the record.
• Recognition events (the Alert Log) — retained indefinitely; no automatic cleanup exists for this log today.

Deletion & your rights

Right to decline enrollment. Enrollment is not automatic or passive — see "Consent for enrollment" above. No one is enrolled without that explicit action and confirmation.

Right to request deletion (enrolled biometric data). Anyone enrolled (or previously enrolled) can request their photos and embeddings be removed at any time by contacting privacy@neo-innovations.com. Removing an enrolled person takes effect immediately on live matching.

Right to request deletion of a specific detection snapshot. If you believe you appear in a specific, identifiable detection snapshot and would like it removed, contact the address above. An admin can now delete an individual snapshot by filename — this is a real, working capability, not just a promise, though it currently requires an admin to act on your request rather than being self-service.

Customer account and account-request data. This is genuinely partial today, and we'd rather say so plainly than overstate it:

• If you hold an active customer account and want it deleted, contact us. An admin can delete your account outright, which also revokes any license/installation tied to it and deletes the original Request Access record that led to the account. There is no in-portal, self-service "delete my account" button yet — deletion is admin-operated on request.
• If you submitted a Request Access form that was rejected, never actioned, or that you'd simply like removed regardless of outcome, contact us. An admin can delete that record outright, through a dedicated deletion action — this is a real, working capability, not just a promise, though it currently requires an admin to act on your request rather than being self-service.

No self-service export or account correction yet. There is currently no way for a customer to export their own stored data, or to view/correct their own stored name, company, or email themselves, through the portal. If you'd like a copy of what we hold about you, or need something corrected, email the address above and we'll handle it manually.

Third-party services

Face photos, embeddings, and detection snapshots are never sold, shared, or transmitted to any third party — they stay on the local filesystem this system runs on (see "What biometric data is collected" above). That is not true of every category of data on this site, and we'd rather list the real, complete set of third-party services involved than imply there are none:

• Email delivery (Gmail SMTP). Contact-form submissions and account-activation emails (name, email, and — for activation — a one-time link) are relayed through a third-party email provider (Gmail, via standard SMTP) to actually deliver the notification/activation email. The underlying submission or account record is always saved locally regardless of whether the email send itself succeeds.
• Telegram. An organization can optionally link a Telegram chat to receive detection-alert notifications there instead of (or alongside) email. This is opt-in per organization — nothing is sent to Telegram unless an admin deliberately links a chat. The message itself is deliberately minimized: it names the camera and the type of event, but never a matched person's name, confidence score, or a snapshot image — the same content-minimization already described for email alerts.
• Cloudflare (Tunnel). Public traffic to this site is routed through Cloudflare's tunnel infrastructure, which is how this site is reachable at all from outside the local machine it runs on.
• Font providers. This site loads typefaces from Fontshare and Google Fonts — see the Cookie Policy for the specific domains involved.

No analytics, advertising, or tracking service of any kind is integrated into this site.

Contact form submissions

Name, email, and message submitted via the Contact page are stored locally (encrypted at rest, with a dedicated key), used only to respond to the inquiry, and are not biometric data. As noted above, sending the notification email itself relays that data through a third-party email provider.

Cookies

This site's cookie usage — one strictly necessary session cookie, plus one additional cookie set only if you opt in to "remember this device" at login, no tracking or advertising cookies of any kind — is described in full in the separate Cookie Policy, rather than duplicated here.

Operator vs. customer accounts

Operator (dashboard) accounts. Usernames and bcrypt-hashed passwords for operators who access the live dashboard and admin panel — not visitor or enrolled-person data. These are provisioned directly by an admin; there is no public signup for this type of account.

Customer accounts. A separate account type, created only through the Request Access → approval → activation flow described above. A customer account cannot be granted operator/admin permissions, and an operator account is never exposed to a customer — the two are kept structurally separate in how this system stores and enforces access.

About the demo

The Demo page uses pre-recorded stock footage of anonymous members of the public (licensed stock video), run once through the detection pipeline to produce a sample annotated result. It is not a live feed, and no new footage is captured or processed when you view that page.

This site as a whole is a portfolio/demonstration project, built by a solo, pre-entity founder — it is not currently offered as a commercial product or service with paying customers. The underlying detection system does run live and continuously on real hardware, and its enrolled roster includes a real person beyond the founder — this is not simulated or purely theoretical processing. The customer account, request-access, and license/installation systems described above also exist as real, working code today, not only as a future design.

Jurisdiction — this matters, and it isn't settled here

Biometric privacy law varies significantly by where a system is actually deployed — for example Illinois' BIPA, Texas' CUBI, Washington state's biometric privacy law, the EU's GDPR, and India's DPDP Act each impose different (and sometimes conflicting) requirements around consent, notice, and retention. General data protection expectations (not specific to biometric data) also apply to the customer account information described above — name, email, company, and related fields are personal data under most frameworks, including GDPR and DPDP, independent of the separate, stricter biometric-data questions.

Neo Innovations is not represented anywhere on this site as certified or compliant under GDPR, India's DPDP framework, SOC 2, ISO/IEC 27001, or any comparable framework — because none of those has actually been achieved through the relevant external process. Where this page describes a technical control (encryption at rest, an operator-attestation consent record, an admin-operated deletion capability), that is a description of what the system does today, not a claim that it satisfies any specific law or standard.

This policy does not attempt to satisfy any specific jurisdiction's legal requirements. Any real-world deployment of this system, and any real collection of a third party's biometric or personal data through it, requires jurisdiction-specific legal review before that data is processed for real — that review has not been done, and this document is not a substitute for it. Questions about what constitutes adequate consent, an adequate legal basis for processing, or an adequate response to a data-subject/data- principal rights request in a specific jurisdiction should be directed to qualified legal counsel, not answered by this page.