Cloud Privacy
What the cloud tier transmits, what is never stored, and what you as the integrator have to do.
Read this before shipping the cloud tier
The claim "raw camera frames are never uploaded" is true of the on-device tier and only of it. The cloud tier transmits cropped images of the user's face to our servers. A 448×448 auxiliary crop, used by the optional module, is a recognisable photograph of a face. Running the cloud tier means biometric personal data is processed on our infrastructure, and both of us have obligations that follow from that.
What is transmitted
| Tier | What leaves the device |
|---|---|
| On-device | Nothing during the measurement. Only the finished result, and only if you choose to submit it. |
Cloud, stream and batch_frames | 36×36 face crops at up to 30 per second, plus optional quality telemetry. With the optional auxiliary module, a 448×448 face crop up to twice per second. |
Cloud, batch_video | The recorded video file you upload. |
The 36×36 pulse crop is a 3 900-byte thumbnail of a face region — not identifiable at a glance, but derived from the face and treated as biometric data regardless. The auxiliary crop is unambiguously a photograph.
What is never stored
These are properties of the system, not policy statements:
- Frames live only in the memory of the running session. They are never written to disk, never written to a log, and never written to object storage.
- They are not part of the measurement. The
rawblock of a measurement result contains RR intervals and the pulse waveform. It never contains pixels. - Recurrent model state is destroyed with the connection. Nothing survives the session.
- Job records hold counters, not content — frames received, frames dropped, seconds processed, status, and the storage key.
- The session token is never in a URL. It is sent as the first WebSocket message specifically so it cannot land in an access log.
The batch exception
Streaming writes nothing to disk at any point. Batch does — an uploaded file has to exist somewhere until it is processed. That is a genuine weakening of the position, and it is bounded by hard rules rather than by assurances:
| Rule | |
|---|---|
| Deletion | Immediately when the job finishes, whatever the outcome |
| Hard TTL | 1 hour from presign, swept independently of job status |
| Backups and versioning on the bucket | Off |
Frames or video in raw, in logs, or in metrics | Never |
uploadUrl | Treated as a credential: not logged, not surfaced |
If that trade is unacceptable for your data, use delivery: 'stream' and accept
that a broken connection loses the measurement, or use the on-device tier.
Consent is mandatory in the API
Both POST /sdk/v1/cloud/sessions and
POST /sdk/v1/cloud/jobs reject a request without
consent: true.
That flag is your assertion, not ours. Collecting a valid, informed, specific consent from the person being measured — and being able to show it later — is your responsibility as the integrator. The API refuses to proceed without the assertion so that "we did not know frames were being uploaded" is never a possible position.
What the person is consenting to, in plain terms:
- Images of their face are transmitted to neccessory for processing.
- The images are not retained; the resulting metrics are.
- The measurement is a wellness estimate, not a medical one — see the disclaimer.
Processing region
Every inference node declares the region it runs in as part of its configuration, and reports it on its own health endpoint. Every finished job records which node processed it, so where a given measurement was computed is answerable after the fact.
The region is a commitment, not a technical constraint
Be precise about this if you are writing it into your own compliance documentation: the region is declared and recorded, not enforced in code. There is no check that refuses a session because a node sits outside the announced region — placement is an operational and contractual matter, and the audit trail is the job record, not a guard rail. Do not represent it to your users or your regulator as something the system technically prevents.
Confirm the current region with us before you commit to it in your own privacy documentation.
If you are subject to data-localization requirements — Russian 152-FZ is the common case — talk to us before integrating the cloud tier. On-device does not have this exposure, because nothing is transmitted at all.
What to get from us before production
- The data processing agreement for the cloud tier.
- The current list of subprocessors.
- The current processing region and retention terms for stored measurements.
What to put in your own documentation
If you ship the cloud tier, your privacy notice cannot say that processing is local. Concretely:
- Say that face images are transmitted to a processor for analysis, and name the purpose.
- Say what is retained: the metrics, not the images.
- Do not copy the on-device wording. The two tiers make genuinely different promises, and only one of them keeps frames on the device.
Our own privacy policy covers the neccessory website, app, and console. It is not a substitute for your notice to your users.
Next: Metrics.