What privacy settings leave behind on a device

Evidence

Confidence: moderate

Device class: Personal iPhones and Android phones in the Lab's research collection, nearly all unmanaged: 34 iPhone and 14 Android full file system extractions, 7 Android bug reports and two decoded iPhone unified logs. Of the Android phones, 12 are Samsung, one a Pixel and one a Motorola. Where one article gives 33 iPhones and another 34 iPhone images, the difference is one iPhone that was extracted twice on the same day: 34 extractions come from 33 iPhones, and the 48 extractions of the corpus from 47 devices (LAB-TR-0024, Section 3.6).
OS build: iOS 15 to 26 on the images, iOS 27.0 and 26.6 for the two logs. Android 10 to 16 on the extractions, Android 10, 15 and 16 on the bug reports. Build strings are withheld.
Acquisition: Existing extractions, bug reports and logs, read only. We recorded which files and keys exist, in what format, and which log lines occur. No setting was switched and no phone was extracted twice.
How to reproduce: On a test phone you own, note a setting, change it at a written time, extract the phone, and look for the files and keys in Figure 3 before and after. The Lab has not run this study, so what a switch writes is the open question.
Confidence: Moderate for where the current state lives. Low for change histories, which rest on two logs and two bug reports.
Does not prove: That a missing key means a setting is off, that a missing change record means no change, or that these counts hold for other builds, vendors or managed devices. Example values are synthetic.

Cite as

Addai, D., SectraTEK Lab (2026). What privacy settings leave behind on a device. LAB-0005, version 1.0. https://lab.sectratek.com/research/lab-0005/

Citation guide

Methodology note

Drafted with AI assistance and reviewed by the author before publication.

Summary

A setting usually has a state record, a key in a file or table that holds the current value. A record of the change is a separate thing, and for most settings we found none in the evidence we read.
Many keys are written only after a setting leaves its default. The iPhone preference file for Lockdown Mode was on 33 of 34 images, but the key was in only 5 of those 33 files. A missing key is not "off".
Change records are rare and short-lived. Of 45 iPhone security controls, 31 left some trace in the unified log, but only 12 had a state change as their strongest trace, and every Lockdown Mode line said the mode was off.
The evidence can write the value. USB debugging was on in all 14 Android full file system extractions, because an acquisition over USB needs it.
Report one of four states: present, absent, unreadable or cannot say. Only the first is a statement about the setting.

One blank, four meanings

An examiner is asked whether a phone had Lockdown Mode on, USB debugging enabled or private notifications hidden on the lock screen. They search the extraction, find no entry and write "not enabled". That sentence reads a blank as an answer. A blank has at least four causes: the setting was never changed from its default, the evidence does not contain the file that would hold it, the file is there and the reader could not open it, or the reader opened another copy of the file.

The Lab's reports sort every empty read into four outcomes. This article gives them plain names: present, a value was read; absent, the key is missing from a file that was read; unreadable, the source is in the evidence and was not read; and cannot say, the source is not in this evidence, or this kind of evidence cannot carry it. Table 1 sets out what each licenses.

Table 1. The four states of a reader's result, and what each allows an examiner to say
State	What happened	May say	May not say
Present	A value was read.	The store held this value when the evidence was taken. Give the file, the key and the evidence item.	That the person chose it. Defaults, policy entries and the acquisition itself can write values. When it was set, or what it held before, unless a change record says so.
Absent	The key is not in a file that was read.	The key is not in the file you read. Give the file, and say whether every copy of it was read.	That the setting is off. That it was never changed or never used.
Unreadable	A source is in the evidence and was not read.	A source for this setting is in the evidence and it was not read. Say why: format, missing journal or decode error.	That the setting is absent, off or unchanged. Never turn a parse error into an empty list.
Cannot say	The source is not in this evidence, or this kind of evidence cannot carry it.	This evidence cannot answer the question. Name the missing source, or the kind of evidence that cannot carry it.	That the setting is off, absent or unused.

Failures that return nothing without an error are common. On Android 12 and later, 53 of 58 settings files in our research collection were Android Binary XML. A standard XML parser rejected all 53 and a text search for a setting name found nothing in any of them, while a decoder for the format recovered between 69 and 505 settings per file. A reader that catches the error and returns an empty list reports every setting on those phones as absent. Our earlier study of open-source parsers found the same symptom: about 18 percent of the iOS artifacts of one suite matched a file and returned nothing (LAB-TR-0006).

Figure 1 shows the second half of the problem. A setting leaves a state record, which the next change overwrites. It may leave a change record, which many settings do not. And taking the evidence can set a value of its own.

Three kinds of record a setting can leave, before the change, at the change and when the evidence is taken
Kind of record	Before the change	The change	When the evidence is taken
State recordA key in a file or table	value = A	value = BA is overwritten.	The reader finds BIt never sees A.
Change recordA log line or a history, for some settings only	Nothing yet	Line: A to B, with a timeOnly if this setting writes one.	Kept, or rolled offA log or history keeps a limited window.
The acquisitionWhat taking the evidence does	Not involved	Not involved	May set a value of its ownFor example, USB debugging.

Figure 1A setting can leave three kinds of record. The state record is overwritten by the next change. A change record exists only for some settings and only for a window. The acquisition can add a value that nobody chose. Source: schematic; the values A and B are a synthetic example.

Where the current state lives

The state record is a key in a file or table. On an iPhone these are property lists: a global preferences file for Lockdown Mode, and one file each for the update switches and Mail Privacy Protection. On Android they are three settings files per user (global, secure and system), a lock settings database, and separate files for grants and device policy. The explorer in Figure 3 lists 19 settings with their locations.

The central fact is that many keys are written only after a setting leaves its default. The preference file usually exists. The key often does not (Figure 2). A reader that finds the file but not the key has learned that the key is absent. It has not learned that the setting is off.

Show this figure as a table

Files present and keys present, four iPhone settings
Setting (key)	Preference file present	Key present in the files that exist
Lockdown Mode (LDMGlobalEnabled)	33 of 34 images	5 of 33 files
Automatic iOS updates (SUAutomaticUpdateV2Enabled)	20 of 34 images	15 of 20 files
Automatic App Store updates (AutoUpdatesEnabled)	30 of 34 images	16 of 30 files
Mail Privacy Protection (LoadRemoteContent-v2)	30 of 34 images	26 of 30 files

Figure 2The file is usually there and the key often is not. A missing key is consistent with a setting never changed. It does not show the setting is off. Source: LAB-TR-0017, Table 2 and Figure 3; 34 iPhone images in the Lab's research collection. Counts of this sample, not rates.

Which file you read matters. A launchd property list with the same name as the update preferences sits under the system directory on 32 images. The Find My accounts file lives in three places, and two copies of different size existed on 20 images. In one test, a Messages preference store existed under two file names that differ only in letter case on 20 of 33 images. On a host that ignores case, staging kept the copy without the key on 8 of them, and a reconstruction of the setting reported a documented default from absence. The default happened to match. The inference needs every copy read.

Presence is also not state. The effective-settings store on iPhone held 40 to 275 restriction entries on every image, more than a person sets, so a key being there does not show a person or a profile set it. A "no maximum" value for a passcode-policy cap, on 23 of 33 images, records that no policy limits the setting. It does not record that the user turned the lock off. On a personal iPhone, 121 of the 176 restriction keys in Apple's schema are supervised-only, so their absence is expected and should read "not applicable".

Android has its own traps. Older guides name keys that current builds no longer write: lock_pattern_autolock was in none of the 14 lock settings databases, while install_non_market_apps, a key guides call legacy, was in all 14. Presence or absence says little until you know which release wrote it. A second user, number 150 on 6 of the 14 phones, has settings files of its own, and a reader that takes user 0 alone misses them.

Is there a record of the change?

Usually not in the file that holds the state. That file keeps the current value, and the value it replaced is gone. A change can show up only in a second place: a log, a history printed inside a report, or a record with its own date.

On an iPhone the main candidate is the unified log in a sysdiagnose. We searched two decoded logs of unmanaged research iPhones for 45 security controls. Thirty-one left a trace and 14 left none. Twelve had a strong trace and 19 a partial one. The strongest kind of trace was a state change for 12 controls, a decision for 7 and a restated status for 12. The passcode-change notification appeared twice, at one moment, in one log. It says neither who changed the passcode nor why. For Lockdown Mode, every line said the mode was off. None recorded a switch and none had an "on" form.

What the log supports for most controls is a last known value with a validity window: the value of the last status line, valid from the first to the last line that restates it. Where a daemon restates a status often, silence has meaning. 3,142 restatements of a "no enrollment found" line support "not enrolled" across the 11.8 days of one log. Where a control is seldom restated, the absence of a line supports nothing on its own.

On Android, a bug report prints each settings table with the package that wrote each entry. On the Android 16 reports in our collection it also prints a history under each setting: old value, new value, the writing package and a time. That history was in 2 of 5 research bug reports and absent from the Android 10 and Android 15 reports. The time has a month, a day and a clock time but no year, so a reader must infer the year, and a change older than a year would get the wrong one. An empty history on a report that does not print one says nothing about the settings.

Permissions show the same split between a standing state and an event. The iPhone permission table keeps one row per service and requesting app, with the decision and the date of its last change. On 32 iPhones the median was 160 rows, and 49% of rows had last changed more than a year before acquisition. On Android, the access file keeps the latest access for each app and operation, and the history that exists reaches a median of 7.8 days. The records that survive keep the state and the last event, not the events.

None of these sources was tested by switching a setting. The Lab has not run that study: no phone was switched and extracted again. We know where the keys are and what the logs we read contained. We do not know what each switch writes, where, or how soon. Retention matters too. For a date 30 days before acquisition, app use was answerable on 17 of 33 iPhones and 0 of 14 Android phones, and a claim that nothing of four kinds happened on such a day could be established on 0 of 47 phones. For now, "no change record" usually means "cannot say", not "no change".

Try it: from a result to a statement

Figure 3 turns the sections above into a working tool. Pick a platform and a setting, then pick what your reader returned. The panel shows where the current state lives, whether a change history exists in the sources we measured, and what you may and may not conclude. Example values are synthetic, and counts describe the Lab's research collection, not a rate.

This figure needs JavaScript. The table under it holds the same content.

Platform

iPhoneAndroid

Setting

What your reader returned

The panel changes as you choose. Every example value is a synthetic example.

Show this figure as a table

All 19 settings: where the current state lives, how often it was seen, whether a change history exists, and what to say for each reader result
Setting	Where the current state lives	How often we saw it	Change history	What to say, by result
Lockdown ModeiPhone	The key LDMGlobalEnabled in .GlobalPreferences.plist, in /private/var/mobile/Library/Preferences/. A managed copy under /private/var/Managed Preferences/mobile/ has the same file name.	File in 33 of 34 images; key in 5 of 33 files. Managed copy: file in 31 of 34 images, key in 0 of 31.	Absent. None seen. In two decoded unified logs every line about the mode restated that it was off. No line recorded a switch and none had an on form.	Present. Read the user's copy, not the managed copy, and give the path. Absent. A missing key is the usual case here (key in only 5 of 33 files). It is consistent with a setting never changed. It does not show the mode is off. Unreadable. Every system preference file we read was a binary property list. A reader that accepts only XML finds nothing, which is a failed read, not an absent key. Cannot say. From a unified log alone you can say the mode was off when those lines were written. The log says nothing about the hours between them.
Automatic iOS updatesiPhone	Keys such as SUAutomaticUpdateV2Enabled in com.apple.softwareupdateservicesd.plist, in /private/var/mobile/Library/Preferences/.	File in 20 of 34 images; SUAutomaticUpdateV2Enabled in 15 of those 20. A launchd property list with the same file name is under /System/Library/LaunchDaemons/ on 32 images.	Cannot say. Not measured. The unified log has a strong trace for software update, but no setting was switched in the study, so what a change of this switch writes is not known.	Present. Name the file you read. A launchd property list with the same name exists on 32 images. Absent. The key was missing from 5 of the 20 files that exist. Consistent with a setting left at its default. Not evidence of off. Unreadable. Parse both property list encodings, and treat a parse error as not read. Cannot say. The file is absent from 14 of 34 images. Say the source is not in the evidence.
Automatic App Store updatesiPhone	The key AutoUpdatesEnabled in com.apple.itunesstored.plist, in /private/var/mobile/Library/Preferences/.	File in 30 of 34 images; key in 16 of 30.	Cannot say. Not measured in the log or in any other source.	Present. A launchd property list with the same file name exists on 32 images. Say which one you read. Absent. The key was missing from 14 of the 30 files that exist, so absence is common. It is not evidence of off. Unreadable. Parse both property list encodings. A parse error is not an empty file. Cannot say. The file is absent from 4 of 34 images. Say the source is not in the evidence.
Mail Privacy ProtectioniPhone	The key LoadRemoteContent-v2 (an integer) in group.com.apple.mail.plist, inside an app-group container whose folder name is a random identifier. The container is found through its metadata file.	Container resolved on all 30 images that had it; key in 26 of 30.	Cannot say. Not measured in the log or in any other source.	Present. The map says where the key is stored, not what each value means. Read the documented meaning for the release before you call it on or off. Absent. The key was missing from 4 of the 30 files that exist. Unreadable. A fixed container path matches nothing because the folder name is random. That is a failed read, not an absent setting. Cannot say. The file is absent from 4 of 34 images. Say the source is not in the evidence.
Passcode and restriction policy (effective)iPhone	EffectiveUserSettings.plist, in /private/var/mobile/Library/UserConfigurationProfiles/ or in the system group configuration profiles container. Values sit in typed wrappers such as restrictedBool and restrictedValue.	File in 33 of 34 images. Each store held 40 to 275 restrictedBool entries.	Present. Rare. A passcode-change notification appeared twice, at one moment, in one decoded log and not in the other. It names neither who changed the passcode nor why.	Present. A key being there proves little: the store held 40 to 275 entries, more than a person sets. A no-maximum value, seen on 23 of 33 images, records that no policy limits the setting. It does not show the user chose it. Absent. Some documented passcode keys were in none of the stores (for example maxFailedAttempts and pinHistory, 0 of 33). On a personal phone that is expected. Unreadable. The store was XML in 26 and binary in 17 of 43 files. Accept both encodings. Cannot say. 121 of the 176 iOS restriction keys in Apple's schema are supervised-only. On a personal iPhone report them as not applicable, not as missing.
App privacy permissionsiPhone	The permission table (TCC): one row per service and requesting app, with the decision and one date, the last change. The log also holds cached verdicts in authorization cache dumps.	Median 160 rows per device on 32 iPhones. 27% of rows had last changed within 30 days of acquisition and 49% more than a year before.	Present. The last change only, kept in the row. The decoded iOS 27.0 log has one access-record update line, with its own time and the requesting app. Its 6,099 and 8,825 decision lines are decisions, not changes.	Present. The row holds the standing decision and the date of its last change, not earlier decisions. On 15 of 32 iOS permission stores, rows were older than every setup indicator, so a date can predate the phone. Absent. No row means no stored decision. It does not show the app never asked. Unreadable. Treat a table that did not decode as not read. Do not report zero rows. Cannot say. In request lines of the log the requester is withheld. The permission table, where it is in the evidence, names the requesting app.
Screen Time restrictionsiPhone	RMAdminStore-Local.sqlite and RMAdminStore-Cloud.sqlite in /private/var/mobile/Library/Application Support/com.apple.remotemanagementd/. SQLite in write-ahead log mode.	Local store in 30 of 34 images, cloud store in 29. A non-empty -wal file sits beside them on 29 and 24.	Present. Partly. The log has a partial trace of the state-change kind for Screen Time. A Screen Time status line appeared in only one of the two decoded logs.	Present. Say whether the -wal file was applied. Absent. Rows missing from a store read without its -wal file are not absent rows. Unreadable. Reading a store without its -wal file can give missing or stale rows. In an earlier study counts changed when the log was not applied on 14 of 17 stores. Apply the log and say that you did. Cannot say. The local store is absent from 4 of 34 images and the cloud store from 5. Say the source is not in the evidence.
Find MyiPhone	FMIPAccounts.plist (com.apple.icloud.findmydeviced). There is no single on/off key: the file holds an account dictionary.	Found in Preferences on 19 images, in a system data container on 14 and in a system group container on 7. Two copies of different size on 20. Absent from 13.	Absent. None seen. The log carries a restated status for Activation Lock and Find My, not a change.	Present. No single on/off key exists, so say what you read: an account entry. Absent. Absent from one location is not absent from the image. The file lives in three places and two copies differ in size on 20 images. Read all copies. Unreadable. Parse both property list encodings. A parse error is not an empty dictionary. Cannot say. Whether Find My is active on Apple's servers is outside a file system. Say the source is not in the evidence.
iCloud Private RelayiPhone	The key NSPServiceStatusManagerInfo in com.apple.networkserviceproxy.plist, in /private/var/mobile/Library/Preferences/. The value is an embedded archive.	File in 29 of 34 images; key in all 29.	Absent. None seen. The log has a partial trace that restates a status, on the telephony side.	Present. The key is on every image that has the file, so its presence says nothing about whether the service was on. The meaning of the fields inside was not verified. Absent. The key was in all 29 files that exist, so a missing key points to a failed read first. Unreadable. The value is an embedded archive. Decode it before you read it. Cannot say. The file is absent from 5 of 34 images. Say the source is not in the evidence.
App Privacy ReportiPhone	Stream files under /private/var/mobile/Library/PrivacyAccounting/Biome/com.apple.privacy.accounting.stream*/local/. They hold records of accesses, not a switch.	Stream files on 9 of 34 images. Records inside were not counted.	Absent. None seen in the unified log. The log has no trace for it, because the accesses are kept in files.	Present. Folders and files exist on some images. The records are the evidence, and a folder is not a state. Absent. No stream file on 25 of 34 images. That does not show the report was off: the map covers the stream files only. Unreadable. Stream files are a binary format. Treat a file that did not decode as not read. Cannot say. The log cannot answer this. Say the source is not in the evidence.
USB debugging and developer optionsAndroid	adb_enabled and development_settings_enabled in settings_global.xml, in data/system/users/0/. Global settings exist for user 0 only.	Both keys in 14 of 14 extractions. 53 of 58 settings files are Android Binary XML.	Present. Only where a build prints it. On the Android 16 bug reports in the research collection, the settings dump lists a history under each setting: old value, new value, writing package and a time without a year. It was in 2 of 5 bug reports and absent from the Android 10 and Android 15 reports.	Present. On in all 14 full file system extractions, the state an acquisition over USB needs. In 7 bug reports, developer options were on in 6 and USB debugging was off in all 7. Report these as observed at capture, not as the user's choice. Absent. Both keys were in all 14 extractions, so check the user number and the file format before you call the setting unchanged. Unreadable. On Android 12 and later the files are Android Binary XML (first bytes 41 42 58 00). A standard XML parser rejected all 53, and a text search found nothing. Decode first. Cannot say. A bug report carries the settings tables, so the value can be read there as well. If the settings section is not in the report, say so.
Install unknown appsAndroid	install_non_market_apps in settings_secure.xml, per user.	Key in 14 of 14 extractions, although guides describe it as a legacy key.	Present. Same source as every Android setting: a history printed in a bug report, in 2 of 5 research bug reports (both Android 16). The settings files were read for key presence only, so whether they keep older values was not examined.	Present. The key is written on current releases, so its presence does not date the setting to an old release. Read the value. Absent. Key present on 14 of 14 extractions. A missing key points to the wrong user or a failed read first. Unreadable. Android Binary XML on Android 12 and later. Decode before you look up the key. Cannot say. If the settings files are not in the evidence, say the setting cannot be determined from it.
Location modeAndroid	location_mode in settings_secure.xml. An older key, location_providers_allowed, is in the same file.	location_mode in 14 of 14 extractions; location_providers_allowed in 3 of 14.	Present. Same source as every Android setting: a history printed in a bug report, in 2 of 5 research bug reports (both Android 16). The settings files were read for key presence only, so whether they keep older values was not examined.	Present. Read the value of the current key. The older key may be missing. Absent. location_providers_allowed was missing from 11 of 14 files. A missing older key does not show location is off. Look for the current key. Unreadable. Android Binary XML on Android 12 and later. Decode before you look up the key. Cannot say. If the settings files are not in the evidence, say the setting cannot be determined from it.
App verification before installAndroid	package_verifier_user_consent and package_verifier_enable in settings_global.xml; package_verifier_state in settings_secure.xml.	Consent key in 14 of 14 extractions; enable key in 2 of 14; state key in 3 of 14.	Present. Same source as every Android setting: a history printed in a bug report, in 2 of 5 research bug reports (both Android 16). The settings files were read for key presence only, so whether they keep older values was not examined.	Present. Say which of the three keys you read. Absent. Which of these keys a build writes differs. One missing key says nothing until the other two are read. Unreadable. Android Binary XML on Android 12 and later. Decode before you look up the key. Cannot say. If the settings files are not in the evidence, say the setting cannot be determined from it.
Screen lock setAndroid	The table locksettings in data/system/locksettings.db (SQLite). The key sp-handle points to the credential blob.	Database in 14 of 14 extractions. sp-handle in 14; lockscreen.disabled in 8; lockscreen.password_type in 2; lock_pattern_autolock in 0.	Cannot say. Not examined. The study read key presence in this database, not older rows.	Present. Say which key you read. Older guides name keys that current builds no longer write. Absent. lock_pattern_autolock was in none of 14 databases and lockscreen.password_type in 2. A missing legacy key is not an unlocked phone. Unreadable. Rollback journal on 13 of 14 and write-ahead log on 1 (Android 10). Check header byte 18 and open the database with its journal. Cannot say. A bug report does not carry the lock settings database: 60% of lock-state facts were not carried by that evidence and 34% were determined. Say the lock state cannot be determined from it. Do not say it is off.
Notifications on the lock screenAndroid	lock_screen_show_notifications and lock_screen_allow_private_notifications in settings_secure.xml.	Both keys in 14 of 14 extractions.	Present. Same source as every Android setting: a history printed in a bug report, in 2 of 5 research bug reports (both Android 16). The settings files were read for key presence only, so whether they keep older values was not examined.	Present. A bug report's settings tables also carry these keys, so the value can be read from either source. Absent. Both keys were in all 14 extractions. A missing key points to the wrong user or a failed read first. Unreadable. Android Binary XML on Android 12 and later. Decode before you look up the key. Cannot say. If the settings files are not in the evidence, say the setting cannot be determined from it.
Always-on VPNAndroid	always_on_vpn_app and always_on_vpn_lockdown in settings_secure.xml.	Both keys in 0 of 14 extractions. They are written only when configured.	Present. Same source as every Android setting: a history printed in a bug report, in 2 of 5 research bug reports (both Android 16). The settings files were read for key presence only, so whether they keep older values was not examined.	Present. Say which key you read, and whether the lockdown key is also set. Absent. Zero of 14 is the expected result for phones where nothing was configured. It is consistent with never configured. It says nothing about whether a VPN was used. Unreadable. Android Binary XML on Android 12 and later. Decode before you look up the key. Cannot say. If the settings files are not in the evidence, say the setting cannot be determined from it.
BackupAndroid	backup_enabled in settings_secure.xml.	Key in 14 of 14 extractions.	Present. Same source as every Android setting: a history printed in a bug report, in 2 of 5 research bug reports (both Android 16). The settings files were read for key presence only, so whether they keep older values was not examined.	Present. Read the value and the user number. Absent. Key present on 14 of 14 extractions. A missing key points to the wrong user or a failed read first. Unreadable. Android Binary XML on Android 12 and later. Decode before you look up the key. Cannot say. If the settings files are not in the evidence, say the setting cannot be determined from it.
App permissions (grants and use)Android	Grants: runtime-permissions.xml (plain XML) under data/misc_de/<u>/apexdata/com.android.permission/. Use: appops.xml and appops_accesses.xml in data/system/.	Grants file in 13 of 14 at the Android 12 and later path and 1 at the Android 10 path. App Ops files in 7 and 10 of 14.	Present. Use only, not grants. App Ops keeps the latest access for each app and operation (median 2,081 dated entries on 14 phones). Its history, where it exists, reaches a median of 7.8 days.	Present. A grant is a standing state and a use is an event. The grants file shows what was permitted. The access records show the latest access. Absent. An app with no entry in the grants file is not shown to have been denied. Check the user and the path for the release. Unreadable. appops.xml is Android Binary XML on Android 12 and later; runtime-permissions.xml is plain XML on every release we read. Do not assume one format for every system file. Cannot say. A last-access entry can confirm a date and deny no other. On the 13 phones that have both forms, 66% of last-access entries were older than the oldest history row.

Figure 3Setting explorer. For each of 19 settings it shows where the state lives, whether a change history exists, and what a reader may conclude from each of the four results. Source: LAB-TR-0017 (locations and counts), LAB-TR-0012 (iPhone log traces), LAB-TR-0029 (permissions), LAB-TR-0019 (bug reports) and the ALEAPP #1796 post (settings history). Values are a synthetic example.

Two habits come from using it. Name the file you read, and every copy of it. And choose the weaker of two honest statements: "the key is not in the file" is true, while "the setting is off" is a guess.

When the evidence writes the value, or cannot carry it

Some values describe the capture. Developer options and USB debugging were on in all 14 Android full file system extractions, the state an acquisition over USB requires (Android Debug Bridge documentation). In 7 bug reports, developer options were on in 6 and USB debugging was off in all 7, which fits a report taken from the developer options on the device. A reader that judges those values judges the examiner, not the user. They belong in a report as observed at capture.

The kind of evidence also decides what can be established. Figure 4 shows, for one catalogue of security-setting facts, how much each evidence source could establish: 94% on Android full file systems, 82% on bug reports and 63% on iPhone images. The iPhone figure is low mostly because keys were never written, not because files are missing: 57% of the stored-settings facts on iPhone images stayed undetermined. A bug report carries the settings tables, build properties and service counts, but not the lock settings database. Of its lock-state facts, 60% were not carried and 34% were determined. The statement for those is "cannot say", not "off".

Show this figure as a table

Share of facts in each state, by evidence source, percent
Evidence source	Determined	Absent at default	Not in item or not carried	Other not determined
iPhone full file system (33 images)	62.6	0.0	0.0	37.4
Android full file system (14 extractions)	93.9	5.0	0.3	0.8
Android bug report (7 reports)	82.4	5.3	12.3	0.0

Figure 4How much of a phone's security settings each kind of evidence could establish. "Other" is a non-qualifying store, no typed reason, or an inconclusive value. Source: LAB-TR-0019, Section 5.1 and Figure 2; 33 iPhone images, 14 Android extractions and 7 bug reports. Catalogue facts, not all of a phone's posture.

The reason is part of the answer. When we damaged copies of Android settings files, a truncated file was labelled "absent at factory default" for 23 lost facts: a read failure reported as an unchanged setting. No value changed, but a reader who sees "absent at default" may conclude the user never changed the setting, where "present, not read" sends them to look again. The reason should be decided for each store file: absent, present but not decoded, or decoded without the key.

What this does not prove

Read these before you report a finding

A missing key does not prove a setting is off, and a present key does not prove a person set it. Defaults, policy entries and the acquisition write values too.
A missing change record does not prove there was no change. No phone was switched and extracted again, so what each switch writes is unmeasured.
The counts describe 34 iPhone and 14 Android extractions, 7 bug reports and two logs from personal phones, mostly iOS 26 and Samsung phones on Android 16. Other builds, vendors and managed devices may differ. They are not rates.
Settings held in the keychain, in secure hardware or in a server-side account are outside a file system, and so are outside this map.
Nothing here detects compromise, says who changed a setting, or scores a phone against a benchmark.
The example values are synthetic. They show the form of a record, not a real one.

Sources

Every number and claim, and where it comes from. Five of the sources are Lab Technical Reports available on this site (no DOI yet): LAB-TR-0017, LAB-TR-0019, LAB-TR-0012, LAB-TR-0029 and LAB-TR-0034. LAB-TR-0006, Empty Is Not Absent, is on Zenodo (doi:10.5281/zenodo.23717928). The settings history rests on the open-source post ALEAPP #1796. Numbers that could not be sourced were left out.

Sources for the numbers and claims in this article
Claim or number	Source
Four reader states: value read, key absent in a file that was read, source absent, source not read. Only the first is a statement about the setting.	LAB-TR-0017, Section 5 (Recommendations).
Reason classes: absent at default, store not in item, present but not read, not carried by class.	LAB-TR-0019, Section 3.3, Table 2.
53 of 58 settings files were Android Binary XML; an XML parser rejected all 53; a text search found nothing; a decoder recovered 69 to 505 settings per file. First bytes 41 42 58 00.	LAB-TR-0017, Section 1 and Sections 2.1, 4.5 (Table 7, P5).
Lockdown Mode: file in 33 of 34 images, key in 5 of 33; managed copy in 31 of 34, key in 0 of 31. Update switch: file 20 of 34, key 15. App Store switch: file 30, key 16. Mail switch: file 30, key 26.	LAB-TR-0017, Section 4.1, Table 2; Figure 3. Pitfall P7 in Table 7.
A launchd property list with the same name on 32 images. Find My file in Preferences on 19 images, a system data container on 14, a system group container on 7, absent from 13; two copies of different size on 20.	LAB-TR-0017, Section 4.1 and Table 7 (P2, P3).
A Messages preference store under two names differing only in letter case on 20 of 33 images; on 8 the copy without the key was kept and a documented default was reported from absence.	LAB-TR-0019, Section 5.2.
40 to 275 restrictedBool entries per profile store; 26 XML and 17 binary of 43 profile store files; passcode keys maxFailedAttempts and pinHistory in 0 of 33 stores.	LAB-TR-0017, Section 4.1 and Table 5.
A no-maximum value for a passcode-policy cap on 23 of 33 images.	LAB-TR-0019, Section 5.2.
121 of 176 iOS restriction keys are supervised-only.	LAB-TR-0017, Section 4.6 (Apple device-management schema).
Android keys: lock_pattern_autolock in 0 of 14, lockscreen.password_type in 2, lockscreen.disabled in 8, sp-handle in 14; install_non_market_apps in 14; location_mode 14 and location_providers_allowed 3; verifier keys 14, 2 and 3; lock screen notification keys 14; always-on VPN keys 0; backup_enabled 14; user 150 on 6 of 14.	LAB-TR-0017, Section 4.2 (Tables 3 and 4) and Section 4.3 (Table 5).
Rollback journal on 13 of 14 lock databases and a write-ahead log on 1. Header byte 18 tells which. Screen Time stores 30 and 29 of 34 with non-empty -wal files beside 29 and 24; counts changed without the log on 14 of 17 stores.	LAB-TR-0017, Section 2.1 (which cites LAB-TR-0009), Table 2 and Table 6.
Grants file in 13 of 14 at the Android 12 and later path and 1 at the Android 10 path; App Ops files in 7 and 10; App Ops files ABX on Android 12 and later.	LAB-TR-0017, Table 3 and Table 6.
45 controls; 31 left a trace and 14 none; 12 strong and 19 partial; strongest kind a state change for 12, a decision for 7, a restated status for 12.	LAB-TR-0012, Abstract and Section 5.1, Table 4, Figure 3.
Passcode-change notification twice, at one moment, in one log; neither who nor why. Lockdown Mode lines only restated off: 2 and 1 lines from the daemon, 8 and 2 from the telephony daemon, none with an on form.	LAB-TR-0012, Section 1 (Figure 1) and Section 5.2.
Log windows of 11.8 and 32.5 days. A state is a last known value with a validity window. 3,142 restatements of a no-enrollment line support not enrolled across one window; the absence of an on line for Lockdown Mode supports nothing alone.	LAB-TR-0012, Section 4 (Table 2), Section 5.2 and Section 6.1.
One access-record update line in the iOS 27.0 log, with its own time and the requesting app; 6,099 and 8,825 permission decision lines; requesters withheld in request contexts. Screen Time status line in one of two logs. Find My and Private Relay restated status only; App Privacy Report no trace.	LAB-TR-0012, Sections 5.2 and 5.3, Table 4 (rows 7, 15, 24, 26), Section 6.3.
The settings history in bug reports: old value, new value, package, caller, a time without a year; present in 2 of 5 research bug reports (both Android 16), absent from the Android 10 and 15 reports; a change older than a year would be given a year too late.	Open-source post ALEAPP #1796: sections The essence, The issue, The value; Figures 3 and 4.
iOS permission table: median 160 rows per device on 32 iPhones; 27% last changed within 30 days and 49% more than a year before acquisition; 15 of 32 permission stores held rows older than every setup indicator.	LAB-TR-0029, Section 5.6 (Table 7) and Abstract.
Android access file: median 2,081 dated entries per device on 14 phones; App Ops history median 7.8 days; 66% of last-access entries older than the oldest history row on 13 phones.	LAB-TR-0029, Section 5.6.
For a date 30 days before acquisition, app use was answerable on 17 of 33 iPhones and 0 of 14 Android phones.	LAB-TR-0029, Abstract.
Nothing of four kinds could be shown absent for a day 30 days before acquisition on 0 of 47 phones. A last-use store can confirm and never deny.	LAB-TR-0034, Abstract and Section 3.2.
No phone was switched and extracted again; the map shows where a key is stored, not what each switch writes.	LAB-TR-0017, Section 6; LAB-TR-0012, Section 1 (Scope) and Section 8; LAB-TR-0019, Section 7.
Developer options and USB debugging on in all 14 Android full file system extractions; in 7 bug reports, developer options on in 6 and USB debugging off in all 7.	LAB-TR-0019, Section 5.4.
Determined shares: iPhone images 63% (62.6), Android full file systems 94% (93.9), bug reports 82% (82.4). Other shares in Figure 4; the not-carried and other columns are sums of the report's reason classes.	LAB-TR-0019, Section 5.1 and Figure 2.
Lock state in bug reports: 34% determined, 60% not carried by the evidence class. Stored-settings slots on iPhone images: 43% determined, 57% not.	LAB-TR-0019, Table 4.
54% of the undetermined iPhone facts had no typed reason; on 79% of those the store was present and the key absent.	LAB-TR-0019, Section 5.2.
When one Android settings file was truncated, emptied or overwritten, 23 slot losses were labelled absent at factory default; no value changed. Decide the reason per store file.	LAB-TR-0019, Sections 5.5 and 6.2.
About 18 percent of the iOS artifacts of one suite matched a file and returned nothing; a parser can return an empty table instead of an error.	LAB-TR-0006, Abstract (Zenodo, concept DOI 10.5281/zenodo.23717928).
Explorer, iPhone rows: counts and file names as in the rows above, plus 4 of 34 App Store, Mail and local Screen Time files absent; 5 of 34 Private Relay and cloud Screen Time files absent; 9 of 34 with App Privacy Report stream files.	LAB-TR-0017, Table 2; the not-present counts are 34 minus the present count.
Explorer, Android rows: counts as in the rows above; the cannot-say wording for bug reports and lock state.	LAB-TR-0017, Tables 3 to 5; LAB-TR-0019, Table 4 and Section 5.1.
Public documentation: Android Debug Bridge, used by an acquisition over USB; bug report capture.	developer.android.com/tools/adb and developer.android.com/studio/debug/bug-report (cited in LAB-TR-0019).

Version history and corrections

Version history
Version	Date	Change
1.0	2026-11-06	First publication.

Corrections log

No corrections have been published for this article. Corrections to any article are listed on Corrections, with the version they apply to.

Summary

One blank, four meanings

Where the current state lives

Is there a record of the change?

Try it: from a result to a statement

When the evidence writes the value, or cannot carry it

What this does not prove

Sources

Version history and corrections

Corrections log

Related

Not Found Is Not Off

Where Device Security Settings Live on Disk

Android bug reports, category by category