Data and privacy
Face Matcher processes biometric data, so the questions a data protection review asks come up in every deployment: what is stored, where, for how long, how it is protected and whether anything leaves the site. This page answers them for the default package. The settings that let you store less, or nothing, are described in Data retention and the Data retention and cleanup guide.
Types of data
| Data | Format |
|---|---|
| Watchlists, cameras, detections, matches and configuration | Relational records |
| Face templates | Numeric vector |
| Enrollment pictures of watchlist members | Image |
| Detected face crops | Image |
| Detected pedestrian and object crops | Image |
| Full frames of detections | Image |
A face template is the mathematical representation of a face that the extraction network produces from a detected face. It carries no name, ID or other personal detail, and the face image cannot be reconstructed from it; its only use is comparison with other templates. Identification is the comparison of a fresh template against the templates of enrolled watchlist members.
Note that pedestrian and object crops, and full frames in general, can contain faces of bystanders who were never detected or matched. If you enable those detectors or keep full frames, treat those images as personal data too.
Where data is stored
| Data | Storage | Storage can be disabled |
|---|---|---|
| Relational records | PostgreSQL | No |
| Face templates | PostgreSQL | No |
| Enrollment pictures | S3 (SeaweedFS by default, or AWS S3) | Yes |
| Face, pedestrian and object crops | S3 | Yes |
| Full frames | S3 | Yes |
Both stores run as containers on the Face Matcher host by default; the S3 endpoint can point to a managed AWS S3 bucket instead. Disabling image storage (NoSqlDataStorageDisabled) keeps identification working but removes the possibility of re-extracting templates later when the extraction algorithm changes, because the source images are gone.
Retention
Detections and their images are kept for a configurable number of days, from one day to unlimited. A cleanup job runs daily and deletes everything older than the configured age; the default is 14 days. Match results can be included in the cleanup or kept. Image storage can also be switched off entirely, or limited per camera to matched faces only, so that unidentified passers-by leave no picture behind.
Encryption
At rest: full-disk encryption of the host is the baseline recommendation. PostgreSQL additionally supports its own encryption options; when you use AWS S3, enable server-side encryption on the bucket.
In transit: communication between the services, the database, the broker and the storage can be switched to TLS. It is disabled by default because it needs your own certificates; see HTTPS. Edge cameras talk to the server over MQTT, which can run over TLS as well.
Data transfer
Face Matcher does not send data to the internet. The only outbound traffic is pulling the Docker images from the Innovatrics registry during installation and upgrades; the images can be pulled on another machine and carried into an isolated network on removable media. Optional usage metering (Transaction Counting System statistics) is off by default and sends counts only, never biometric data, when you enable it.
Isolation models
- Single machine: the server and its cameras on one host, or on a closed LAN with IP cameras and no internet access. No data leaves the host or the LAN.
- Server with edge cameras: smart cameras publish crops and templates to the server over MQTT; on a closed LAN nothing leaves the site, over a public network the MQTT link must run on TLS.
- Data center: the server in a data center with edge devices at remote locations sending data over TLS-secured connections; all storage is in the data center.
- Multiple sites: one Face Matcher per site with watchlists synchronized between a Leader and its Followers over TLS. Detections and matches stay at the site where they happened. See Leader and Follower setup.