What data should never leave the device?

The useful question is not which data is sensitive, but which data a specific purpose needs. The GDPR states this as principles. Article 5 requires personal data to be collected for “specified, explicit and legitimate purposes” (purpose limitation), to be “adequate, relevant and limited to what is necessary” for them (data minimisation), and to be kept in identifiable form no longer than necessary (storage limitation). Article 25 adds that, by default, only the personal data necessary for each specific purpose should be processed, and that this covers the amount collected, how far it is processed, how long it is stored and who can access it.

The NIST Privacy Framework reaches the same place from engineering. Its “disassociated processing” outcomes include processing data to limit observability and linkability, with “data actions take place on local devices” as an example, and system or device configurations that permit selective collection. In practice that means deciding, field by field, what leaves the device and why, and keeping the rest local.

Some data has no legitimate reason to travel at all.

• Private keys and long-term secrets. A device’s signing and decryption keys are what make it trustworthy. Android’s Keystore is designed to make keys harder to extract from the device: an app can use a key for cryptographic operations while the key material itself stays non-exportable. If a key leaves, every message it protects and every signature it makes is in question. See what a device key is.
• Credentials and session secrets beyond the single request that needs them.

Where these live on the device matters too; where app data lives on a phone covers the sandbox, the key stores and what gets copied into backups.

Other data has real uses off the device, but only for specific features, and where possible in a reduced form.

• Message content. If the feature is messaging, the content must travel, but it can travel end-to-end encrypted so that no server can read it. Diagnostics and analytics have no need for it.
• Precise location. A weather lookup needs a rough area, not a street address. Apple’s guidance gives the example of an app that coarsens precise location immediately and stores only the coarse value; that app discloses coarse location rather than precise.
• Stable identifiers. Device IDs, account IDs, phone numbers and email addresses let separate records be joined into a profile. Replacing them with a pseudonym helps, but GDPR Recital 26 says pseudonymised data that could be attributed to a person with additional information is still personal data.
• Free text and contacts. Apple notes that free-form text fields can hold anything a user types, including names and health data, so a crash report or analytics event that captures form contents captures all of that too. An address book also describes people who never agreed to use the app.

Both app stores draw the line at transmission, and their definitions make a practical test.

Apple defines collecting as transmitting data off the device in a way that lets you or your partners access it for longer than it takes to service the request in real time. Data processed only on the device is not collected, but anything derived from it and sent off the device counts separately.

Google Play’s Data safety rules say the same about on-device processing, and add two cases. Data processed ephemerally, held only in memory and kept no longer than needed to serve the request, must still be declared in the form but is not shown in the label. Data sent end-to-end encrypted so that only the sender and recipient can read it, and no intermediary including the developer can, does not need to be disclosed as collected.

Both stores hold the app responsible for third-party SDKs it includes, so an analytics or crash library’s uploads are part of the app’s answer.

• Compute on the device and send the result. A count, a duration or a pass or fail flag can answer the question without the raw readings. Remember that the derived value is itself data leaving the device.
• Coarsen and truncate. Round locations and timestamps, and send ranges instead of exact values, before anything is stored or queued.
• Keep identifiers out of telemetry events. Name what happened, not who it happened to. If you need to count distinct installs, use a random per-install value rather than a hardware or account identifier.
• Make collection opt-in and published. A fixed, documented list of what is sent is easier to audit than free-form logging. Offline Protocol’s SDK, for example, sends no telemetry until the app calls enableTelemetry with a key and App ID, and then uploads a fixed inventory of fourteen event types with no message content and no identifier fields to one endpoint over TLS.
• Expire what you keep. Storage limitation applies after upload too: set a retention period for anything that leaves.