Data collection
This page lists the data the SDK handles, so you can complete Apple's App Store privacy details and Google Play's Data safety form. The SDK uses no data for advertising or tracking. With proofUploadUrl unset (the default) and the default direct transport mode, the SDK sends no coordinates to Octet. Country and state lookups send coordinates to the operating system's geocoder or, in a gateway mode, to the gateway. See Location lookups.
What the SDK handles
| Data | Leaves the device | Purpose | Linked to identity | Tracking |
|---|---|---|---|---|
| Precise location | To Octet: only if you set proofUploadUrl or use a gateway mode. See Uploaded proofs and Location lookups. |
App functionality (location proofs) | No¹ | No |
| Coarse location | To Octet: yes, as region codes in the usage counters, and in uploaded proofs if you set proofUploadUrl. See Usage counters. |
App functionality (country-level proofs), Analytics (region codes in the usage reports) | No¹ | No |
| Device ID (device fingerprint) | Yes: license activation and usage reports, and bound into proofs | App functionality, anti-fraud | No¹ | No |
| Product interaction (usage counters) | Yes, unless telemetryEnabled = false |
Analytics: usage counters and per-proof events, no coordinates | No | No |
| Product interaction (daily usage record) | Yes, always: one record per device per day | Billing (active-device count), no location | No | No |
¹ The device fingerprint is a pseudonymous one-way hash, not an account identity, and the SDK does not link this data to a user identity. On iOS the SDK keeps it in the Keychain, so it survives an app reinstall. On Android it changes when the app is reinstalled. If your app associates proofs with a user account, classify the data accordingly on your own form.
The daily usage record is new in 3.0 and cannot be turned off. See Metrics and usage reporting for what each report contains.
Uploaded proofs
With proofUploadUrl set, the SDK uploads each proof it generates.
A proof that carries a content commitment lists each item's key, content type, size, digest and optional locator, so these travel wherever the proof is uploaded. Choose keys and locators that don't reveal personal data. The values and salts never enter the proof. If you have the SDK upload content, it goes to your own storage, never to Octet. Whatever you send to a verifier yourself, such as the content or the manifest, is your app's own data and belongs on your own form.
Uploads to your storage
If an app uploads committed items, they go only to the storage location the app supplies, never to Octet.
While an upload is pending, the SDK keeps the salt and small items encrypted on the device, for at most 7 days, and deletes them once the upload ends. Uploaded files are your app's own data sent to your own server, so Octet collects nothing from them. Declare them on your own form, as you would any other data your app sends to your server.
Location lookups
To check a country or US state, the SDK turns the device's coordinates into a country or state code. Where that lookup runs depends on the transport mode (see Gateway routing).
- Direct mode (the default). The SDK calls the operating system's geocoder:
CLGeocoderon iOS,Geocoderon Android. Apple or Google receives the coordinates. The SDK sends no coordinates to Octet. - Gateway modes. The SDK sends the coordinates to
{gateway}/ext/geo/reverseinstead of the operating system's geocoder. With your own gateway (integratorGatewayon iOS,INTEGRATOR_GATEWAYon Android), your gateway receives them and forwards the request to Octet. InoctetGateway(OCTET_GATEWAY) mode, Octet's gateway receives them. The request carries the full-precision latitude and longitude and the SDK's activation credential, so the receiver can link the lookup to the activated device.
Two other requests carry no location:
- IP-based country hint (iOS only). In direct mode, the iOS SDK requests the device's country from
ipwho.is. The service sees the device's IP address and the standardUser-Agentheader that iOS adds to every request, which names your app, its build number and the iOS version. In a gateway mode the request goes to{gateway}/ext/ipgeo/instead. SetTransportPolicy.thirdParty = .disableto skip the lookup. Octet can also switch the lookup off through remote configuration. The Android SDK makes no IP lookup. - Border-map updates. The SDK downloads updated border maps from
/ext/geo/borders/on the host it already uses. These requests carry no location and no device data.
Usage counters
The usage counters carry no coordinates. Octet also turns on additional usage reporting through remote configuration, without an app release, and it is on for all licenses. The usage reports also include:
- The ISO 3166 country or subdivision code of each region your app checks (for example
USorUS-NY), with the verdict. - The country or subdivision code the device was resolved to by a background proof, whether or not your app asked about that region.
- How the location was found, for example GPS or the cell network.
- The proof's confidence and the time it took to produce, each reported as a range.
- The app's location-permission state: granted, denied, not determined or restricted.
- The category of an internal SDK error and where in the SDK it occurred.
- Which remote-configuration variant the device received, with a pseudonymous device key.
None of these reports carries coordinates.
Set telemetryEnabled = false to stop all usage counters and the additional reporting. To keep the basic usage counters but not the additional reporting, set flagsEnabled = false, which stops the SDK from receiving remote configuration. These requests continue with telemetryEnabled = false:
- License heartbeat. Renews the SDK's activation in the background.
- Remote-configuration fetch. Sends the SDK version, platform, OS version, your app ID and a pseudonymous device key.
- Daily usage record. See Metrics and usage reporting.
iOS: privacy manifest
The xcframework bundles a PrivacyInfo.xcprivacy privacy manifest. Xcode adds it to your app's privacy report at build time, so no action is needed beyond reviewing it alongside your own disclosures. It declares:
- Collected data types. Precise location, coarse location and device ID, each for App Functionality. Coarse location also for Analytics, because of the region codes in the usage reports. The manifest in SDK 3.0.0 left that out, so if you added it to your App Store privacy details yourself, keep it. Product interaction, for Analytics (the usage counters) and Other (the daily usage record, used for billing). Every type is declared as not linked to the user and not used for tracking.
- Tracking. None, and no tracking domains.
- Required-reason APIs. System boot time, for the SDK's anchored license clock, and
UserDefaults, for a one-time device-ID migration.
When you upgrade, re-check your App Store privacy details: from 2.x, so they include product interaction for the Other purpose, and from 3.0, so they include coarse location for Analytics.
Android: Data safety form
Android has no privacy manifest inside the library, so the table above is the statement to use for your app's Play Console Data safety form. The SDK's permissions merge into your manifest automatically. See Prerequisites for the permission list.
Where to go next
- Metrics and usage reporting. What the counters and the daily record contain.
- Gateway routing. Which hosts the SDK contacts, and how to route them through one domain.