This Privacy Policy explains how the Verigate application (“Verigate”, “we”, “us”, “our”) handles information when you use it on your iPhone or iPad. We are Georgii Shilovskii, an individual developer registered in Mexico, contactable at support@verigateid.app.
If you do not agree with this Privacy Policy, please do not install or use Verigate.
Summary
By default, everything stays on your iPhone. Scan results, guest records, lists, and settings live in the app on your device. There is no account, advertising, tracking, or third-party analytics, and no ID image or raw license number is ever stored. Barcode scanning takes no still image; optional front-ID OCR processes one temporary image on-device and discards it after recognition.
Team events are the one exception, and you choose them. From Verigate 2.0, an organizer can start a team event so that several phones at several doors share guest records. Those records are end-to-end encrypted on the phones with a key that Verigate’s server never has. The server works as a relay: it stores the encrypted records and passes them between the event’s phones without being able to read them. To make this work, the server does see a small amount of technical data — random installation IDs, public keys, whether each Staff phone has Premium, and the type, time, and size of each record — and Google Cloud keeps request logs, including IP addresses, for 30 days. Everything an event leaves on the server is deleted with the event. Details are in section 4.
This policy covers two roles: how we handle data about you (very little, and only for team events), and your own responsibility for the data you collect about your guests when you use Verigate in a business — see section 8.
1. What Verigate stores, and where
All of the following lives locally on your device:
| Data | Where it lives | Why |
|---|---|---|
| Checks — time, ID result, Ban/VIP status at check, age, jurisdiction, method, Event/Location/Door/Staff snapshots, entry decision, and any correction audit | A local SwiftData store inside the app sandbox | The History log, Insights, and reports. |
| Person records — first/last name; date of birth; expiry; jurisdiction; your VIP/banned flag, nickname, and note — plus an issuer-scoped SHA-256 digest when a document has been scanned | Same store | To recognise repeat, VIP, and banned guests by document — never by a photo. |
| Operational catalog — saved Venues, Events, one-off Locations, Doors, Staff names, and an optional local Staff PIN | Same store | To attribute admission records locally and reuse the right Door or Staff setup. |
| Team events you take part in — the team’s guest records and decisions, the event’s doors and Staff names, records waiting to be sent, and the organizer’s event reports | Same store | To show the team’s guests at your door and to build the organizer’s event report. |
| Team keys — event keys, this installation’s private keys, and its server credential | The iOS Keychain on this device; the App Attest key stays in the Secure Enclave | To encrypt and decrypt team records and to prove to the server that requests come from a genuine copy of Verigate. |
| Settings (age threshold, auto-return, log retention, etc.) and a cached Premium flag | iOS UserDefaults |
To remember preferences and unlock Premium instantly at launch. |
We never store a photo or image of any ID, and we never store the raw license number. Old Profile records may remain solely as compatibility data for earlier History/export records. Outside team events, none of this data is uploaded to a server we control: a report or list leaves the device only when you explicitly share it through iOS. We cannot see this data and cannot recover it for you.
2. Data we collect about you
If you never use team events, none. Verigate contains no analytics, telemetry, advertising, or crash-reporting code and no third-party SDKs, and we do not collect usage data or advertising identifiers.
If you start or join a team event, our server receives the technical data listed in section 4. In the categories Apple uses on the App Store, that is:
- Identifiers — Device ID: a random installation ID that Verigate creates on your device (not a hardware or advertising identifier).
- Diagnostics — Other diagnostic data: the IP address and User-Agent (app build and iOS version) of each request, kept in Google Cloud request logs for 30 days.
- Purchases — Purchase history: whether a Staff phone joins with Verigate Premium or without it.
We use this data only to run team events. It is not linked to your name, email, or Apple ID — Verigate has no accounts — and it is never used for tracking or advertising. The guest records themselves are end-to-end encrypted and readable only on the team’s phones.
3. Network behaviour
Verigate opens network connections only in these situations:
- Purchases. Apple’s StoreKit framework communicates with the App Store when you start, restore, or refresh a purchase. That traffic is handled by iOS and governed by Apple’s Privacy Policy; we receive no payment details.
- Team events. When you use team events in Settings → Team — start or join one, or take part in one — Verigate talks to our server over HTTPS and uses Apple’s App Attest service to prove that it is a genuine copy of the app (see section 4).
- Links. The website, support, privacy, and terms links open in your browser only when you tap them.
Verigate makes no other outbound connection. Scanning, verdicts, History, lists, and reports work offline. Transfer Lists produces a Ban/VIP file that you move between devices yourself; it does not go through the server.
4. Team events
A team event lets an organizer with Verigate Premium run several doors as one event: up to 10 Staff phones scan for the same event and see the same guests, Ban list, and VIP list, and the organizer gets one report at the end. Taking part is always a choice — the organizer starts the event, and each Staff phone joins by scanning the organizer’s code and being added by the organizer. A plain-language walkthrough is on How Team events work.
End-to-end encryption
The organizer’s phone creates a secret key for each event and hands it only to the phones the organizer adds, protected by each phone’s own keys. Every guest record, decision, list change, and event detail is encrypted on the phone that makes it and decrypted only on the team’s phones. Our server never has the event key, so it stores and forwards ciphertext it cannot read.
| The server cannot read | The server can see |
|---|---|
| Guest names, dates of birth, expiry dates, jurisdictions, document digests, Ban/VIP flags, nicknames, notes, ID results, and Admit/Deny decisions | Random IDs for the event, each installation, each member, and each record |
| Staff names, door names, event and location names | Each phone’s public keys and App Attest key identifier |
| Anything that would tell us who your guests or your staff are | Whether each Staff phone joined with Premium or without it |
| For each record: its type (for example a scan, a decision, or a list change), which phone sent it, when it was created and received, its sequence number, and its size | |
| The event’s state — when it was created, joined, ended, or deleted, and how many phones are on it |
Inside the team, everyone on the event can read its records. The organizer decides who joins and sets each phone’s name and door. A Staff phone can leave the team on its own at any time; to take every phone off the team, the organizer ends the event, and it is then deleted from the server (see below).
Where it runs
The server runs on Google Cloud (Cloud Run and Firestore) in the us-central1 region in the United States. Like any web service, Google Cloud logs each request the server receives — the IP address, User-Agent, requested path (which contains the event’s random ID), time, status, and size. These logs are kept for 30 days and then deleted. The server’s own log lines record only which operation ran and its result, never IDs or content. Access to the server’s database and logs is limited to the developer’s Google Cloud account.
App Attest
Before a device can use the server, Verigate asks Apple’s App Attest service to certify a key created in the device’s Secure Enclave. The server checks Apple’s certificate itself and does not send your data to Apple. App Attest is provided by Apple under Apple’s Privacy Policy. Team events are available only on devices that support it.
How long the server keeps an event
- When every phone has caught up. After End, as soon as every phone on the event has sent its last records, the organizer’s iPhone deletes the event from the server while Verigate is open on it, and the server erases it right away. If a phone can’t connect, the organizer can delete the event sooner with Delete event from server now; whatever that phone still holds never arrives. (In earlier versions of Verigate, the organizer deletes the event with Delete from relay.)
- Ended but not deleted. If the organizer’s iPhone doesn’t delete the event (for example, because Verigate isn’t opened on it again), the server keeps the encrypted records only while the phones finish sending — late records are accepted for 72 hours after End, and nothing is kept longer than 14 days after End — and then deletes them in its routine clean-up.
- Never ended. An event that its organizer never ends is deleted automatically once it is 30 days old, the same way as when the organizer’s iPhone deletes it.
The routine clean-up runs while the server is in use, so a deletion may happen some time after these deadlines rather than at the exact minute. After an event is deleted, the server keeps for 90 days only a small marker under the event’s random ID recording that it was deleted and how it ended — with no installation or member IDs, keys, records, or content — so the same event ID cannot be reused by mistake. Short-lived counters that limit how often a device can call the server are keyed by a one-way hash of the installation ID and expire on their own.
Leaving, ending, and what stays on the phones
- A Staff phone can leave a team event at any time with Settings → Team → Leave team event. Leaving works offline: the guest records it received from the team are removed from that phone (on a phone without Premium, its own scans from the event too), and records it has not sent yet never reach the team.
- Staff phones remove the guest records they received from the team the next time they connect after the event is deleted from the server (by the organizer’s iPhone or by the server’s routine clean-up described above) or after its 72-hour window for late records closes, whichever comes first. A Staff phone without Premium also removes its own scans from that event; a Staff phone with Premium keeps its own scans. Between End and that point, Staff phones keep the event’s records only to finish sending late ones.
- The organizer keeps the event’s records and report on their phone, like any other local data.
- Data that has already reached another phone stays on that phone under its owner’s control until removed as described above; neither we nor the organizer can erase it remotely.
5. How identity recognition works (and why it’s private)
To recognise a returning, VIP, or banned document, Verigate normalises the license number, combines it with a validated issuer identifier — or, conservatively, its country and jurisdiction — and computes a SHA-256 digest. It stores the digest, never the raw number. The digest is one-way and is derived from the document number, not from a face or fingerprint, so it is not biometric data. In a team event, the digest travels inside the encrypted records so that other team phones recognise the same document; the server cannot read it.
A person added manually or from CSV may initially have only a name and date of birth. If a later scan suggests a match, the operator must decide explicitly whether it is the same person; Verigate never merges people automatically.
6. Permissions
Verigate requests only the Camera, for PDF417 barcode scanning, optional front-ID OCR in Manual Entry, and scanning the organizer’s code when joining a team event. Barcode and code scanning take no still image. If you choose OCR, one temporary image is held in memory, processed entirely on-device, and discarded after recognition. Verigate does not request Photos, Location, Microphone, Contacts, Local Network, or any other permission.
7. Retention and deletion
- You control local retention: Settings → Privacy → Auto-delete logs (Never / 30 days / 90 days).
- Clear scan history deletes checks and unflagged people; your Ban/VIP lists and operational catalog stay. Clear all data deletes entries, people, operational context, and legacy compatibility Profiles.
- Team event data on the server is deleted as described in section 4: as soon as every phone has sent its last records after End (or earlier, if the organizer chooses), no later than 14 days after End, or once the event is 30 days old if it is never ended. Google Cloud request logs are deleted after 30 days.
- Uninstalling the app removes all local data from that device.
8. Your guests’ data — the operator’s responsibility
If you use Verigate in a business (a bar, club, shop, or event), you decide to scan other people’s identity documents and you control the resulting records. In doing so you may be a “data controller” (or equivalent) under the laws of your jurisdiction — for example US state privacy and ID-scanning statutes, Illinois BIPA and similar biometric laws, Canadian PIPEDA, or the EU/UK GDPR.
You are responsible for scanning lawfully, for any notices or consent your local law requires, for retention limits, and for how you use flags and notes. If you organize a team event, you also decide which phones receive your guests’ records, and you are responsible for sharing them with the people you add. We provide privacy-preserving tooling: no stored ID image, no raw number, and end-to-end encryption for team events. Outside team events we have no access to the data you collect about your guests; for team events our server only stores and forwards it in encrypted form that we cannot read. Requests from your guests about their data should be directed to you.
9. Children
Verigate is a business tool for venue staff and is not directed to children. Note that the people an operator scans may themselves be under the age threshold — detecting that is the point of the check. The operator is responsible for handling any such data — including minors’ data — lawfully under applicable law (see section 8).
10. Third parties
- Apple Inc. processes your purchase through the App Store and provides App Attest, under Apple’s Privacy Policy.
- Google LLC (Google Cloud) hosts the team-event server, its database, and its request logs as our service provider, under the Google Cloud Data Processing Addendum. It holds team-event records only in encrypted form that it cannot read either.
- No other third party automatically receives any data. A report or list goes only to the destination you explicitly choose in the iOS share sheet. We never sell data or share it for advertising. Verigate bundles no third-party SDKs.
11. Your privacy rights
Most of your data never reaches us, so the rights typically granted under the GDPR, CCPA, and similar privacy laws — access, correction, deletion, and export — are exercised by you, on the device:
- Access. Every scan is visible in History; every flagged guest in the Ban/VIP lists; team event reports in Settings → Team.
- Correction. Names, nicknames, notes, and flags are editable in-app. Admit/Deny corrections create a visible audit revision rather than silently replacing the original decision.
- Deletion. Clear scan history, Clear all data, or delete the app. For team events: Leave team event on a Staff phone, and End on the organizer’s phone, after which the event is deleted from the server as described in section 4.
- Portability. Premium CSV/PDF export, the event report, and the device-to-device list transfer.
- Withdrawal of consent. Stop using team events, or delete the app.
The technical data the server holds for team events is not linked to any name, email address, or account, so we cannot look it up by person; it is deleted on the schedule in section 4. If you have questions about your rights, contact us at support@verigateid.app and we will help you exercise them.
12. Cookies and tracking technologies
Verigate is a native iOS application. It does not use cookies, web beacons, pixels, or any other web-tracking technology, and it does not track you across apps or websites. Do-Not-Track signals are therefore not applicable — there is nothing for us to track.
13. Changes to this Privacy Policy
If we materially change this Privacy Policy, we will update the Last updated date above and, where required by law, notify you the next time you open the app or update through the App Store. We encourage you to review this Privacy Policy periodically.
14. Contact us
Questions about this Privacy Policy, or about how Verigate handles data, please contact us:
Developer: Georgii Shilovskii, Mexico
Email: support@verigateid.app