Measuring the Answerability of Date-Bound Questions from Mobile Device Extractions

1 Introduction

An examiner who receives a phone is rarely asked what it holds. The question is what happened on a date: was an application installed, was it used, did it use the camera, was there contact with a person, was the phone at a place? A search of the extraction returns nothing for that date, and the report says that there is no evidence of the event. As a statement about the search this is correct. It is a statement about the world only if the phone could have recorded the event on that date.

A motivating example. Take a synthetic case. A phone is acquired on 28 June, and the question is whether a messaging application was opened on 3 March, 117 days earlier. The usage store returns no event for that day. Three different facts give the same empty result. The store may keep only ten days. The phone may have been set up on 20 May. Or the store may hold only the time at which each application was last used. In the first two cases the phone cannot answer the question. In the third it can confirm one date and deny none. The report that says “no events on 3 March” is true in all three cases and informative in none of them.

The problem. The ambiguity of absence is known: reasoning about missing digital data needs its own care [1], [2], [3]. Practitioners describe the time limits of single stores, for example that daily usage files keep detailed events for about a week and that the App Ops access file holds a “last seen” value rather than a history [4]. Earlier reports of this Lab measured how far back volatile stores reach [5], how the App Ops forms differ [6], how reset indicators and their clocks behave [7], where a device’s own life begins and which of its records were carried over from an earlier handset [8], and how a missing setting should be accounted for [9]. What is missing is a definition that decides, for a question, a date and an evidence item, whether the answer could be on the device, and a measurement of how often it could. We ask four research questions.

• RQ1 (Definition). Can answerability be defined from limits that are measurable on the evidence item itself?
• RQ2 (Device life). How old are the devices at acquisition, and how well do indicators fix the start of their own life?
• RQ3 (Profile). For five common question types, how often is a question answerable, by evidence class and by how far the date lies before acquisition, and which limit decides?
• RQ4 (Validation). Are “not answerable” verdicts contradicted by records found on the same device, and which other source would be needed?

Contributions. This report makes four contributions.

• A definition of answerable, partly answerable and not answerable from three limits and a clock cap, written as a rule function over a witness-store table (Section 3).
• A measurement of device age at acquisition and of the agreement of start-of-life indicators on 33 iOS and 14 Android extractions and 7 bug reports (Section 5.2).
• An answerability profile for five question types by evidence class and lag, with the limit that decides each non-answerable case, including the case of grants that carry no usable history (Sections 5.3 to 5.6).
• A validation in which a rule fixed in advance failed, with the size of the failure and the refinement it requires (Section 5.7).

Scope. All results describe the Lab’s research corpus: 33 iOS and 14 Android full file system extractions and 7 Android bug reports readable when the study ran. Most devices run iOS 26 or Android 16, and 12 of the 14 Android phones are Samsung. “Answerable” describes what an evidence item can in principle record about a date; it does not say that the store is complete inside its window, that nothing was deleted, or that the event happened. Cells of fewer than five devices are shown but not generalised. Section 7 states the limits.

2 Background and Related Work

2.1 Absence of data in digital evidence

Casey argued that the uncertainty in digital evidence, which loss and corruption compound, was not being evaluated and that examiners should address it formally [2]. Biedermann and Vuille analysed a court case in which the absence of data was reasoned about, and used probability and graphical models to show how partial presentation misleads [1]. A practitioner column on showing that something was never on a device lists the explanations that remain when a search finds nothing, among them that the technique used missed evidence that is present [3]. These works establish that absence is ambiguous and that it should be reported with its reasons. They do not say, for a given device and date, whether the device could have recorded the event.

2.2 Time limits and last-use records in practice

Fortuna describes Android artifacts for reconstructing a daily routine and states that the daily usage files keep the most detailed events for about a week, that coarser files reach back further, and that the App Ops access file stores only the most recent access of each permission and application, so that it gives a “last seen” value; he advises cross-validating sources [4]. The statements are not backed by a measurement across devices. Our earlier reports supply the measurements this paper builds on. LAB-TR-0021 measured how far back fifteen volatile stores reach on 48 extractions and seven bug reports under a clock rule [5]. LAB-TR-0003 showed that the three forms of the App Ops record store different moments: a database row holds the first event of a time window and a count, the XML file the last access [6]. LAB-TR-0004 showed that each reset indicator has its own clock [7]. LAB-TR-0022 measured base rates of clock anomalies [10]. LAB-TR-0023 measured what SQLite leaves of a deleted row [11]. LAB-TR-0028 measured the first boot, the first user setup and the share of records dated before them on the 14 Android phones used here [8].

2.3 Evidence-state accounting and unanswerable questions

LAB-TR-0019 gives every setting fact on an evidence item one accountable state, with a typed reason when no value was established, among them that the store is not carried by the evidence class [9]. Its subject is the value of a setting, and its reasons concern whether a store was present and readable. It has no date and no lag, no retention window, and no notion of the age of the device. The present report asks a different question, whether the evidence reaches back to a date, and it uses the age of the device and the semantics of the record as limits. In reading comprehension, systems that must decide when a passage does not support an answer lose much of their accuracy on questions designed to look answerable: a strong system fell from 86 to 66 F1 [12]. We borrow the word. In the forensic case unanswerability is a property of the reach of the evidence in time, and it can be derived from the evidence item.

Position of this work. The literature argues that absence needs reasons [1]–[3], gives approximate time limits of single stores [4], and, in our own reports, measures horizons [5] and accounts for missing setting facts [9]. We found no definition that combines the start of the device’s life, the retention horizon and the record semantics into a verdict for a question and a date, and no measurement of how often typical questions are answerable on a collection of devices (searched 28 October 2026: ACM Digital Library, DFRWS, FSI:DI, arXiv, web; practitioner training material not searched exhaustively). The limits are known individually from the cited sources; their combination into a function, the device-age and indicator measurements, the profile by lag, and the failure of the boundary rule are new here, as far as we found.

3 Model

This section defines the question, the evidence item and the three verdicts, then the limits and the function that combines them. The witness stores and the rules were written down before the run (Section 4.4 lists the amendments).

3.1 Definitions

A date-bound question is a triple (type, subject, D): a type, a subject such as an application, a permission, a person or a place, and a date. We use five types: installed (the application was present on D), used (it was opened), permission used (it used a protected resource), contact (a call or message with a person) and place (the device was at a place). An evidence item is one acquisition with a class (iOS full file system, Android full file system, Android bug report) and an acquisition time T. The lag of a question is T − D in days.

A question is answerable from an item when a store of the class records the type with a history, the store reaches back to D, D lies inside the device’s own life, and the clock behind the dates is trusted. It is partly answerable when the item can support a positive or qualified answer but not a negative one: only a last-use or state store reaches D, or D lies in the uncertain part of the device-life boundary, or the records may have come from an earlier handset, or the clock behind the dates is not trusted. It is not answerable when no store of the class can speak for D, because none reaches it or the device did not yet exist. For a device-bound question “inside the device’s own life” means at or after hi (Section 3.2); for a person-bound question, at or after lo. The definition concerns capacity. It does not say that the store is complete inside its window; deletion and partial extraction are a separate limit [11].

3.2 Three limits and a cap

Device-life boundary. A phone that shows records from months ago may have been set up recently. We estimate the start of the device’s life from indicators that the operating system writes at setup (Section 4.2). The earliest valid indicator is lo and the latest is hi. LAB-TR-0028 [8] separates, on Android, the first boot record (W) from the first evidence of user setup (U). Here lo is that W on all 14 Android phones; hi is the latest indicator we measured and is not U. A device-bound question (installed, used, permission used, place) about a date before lo is not answerable, and one inside [lo, hi) is at best partly answerable. A person-bound question (contact) is capped at partly answerable before lo, because call and message records can be carried from an earlier handset.

Retention horizon. The horizon of a store is the time from its oldest dated record to acquisition [5]. A history store covers a lag if the lag does not exceed its horizon.

Record semantics. A store keeps history (H: events dated when they happened), last use (L: one record per subject, dated at its latest event) or state (S: the current value, dated at its last change). A last-use or state store can confirm its one date and cannot deny any other: “used on D?” can be answered yes only if D is the last use, and never no. Such a store yields at most a partly answerable verdict.

Clock cap. If the newest dated record of the history stores read (including log archives) does not lie within 72 hours before and one hour after the acquisition time, or if no such record exists, the dates of the device are not trusted and the verdict is capped at partly answerable (the clock rule of LAB-TR-0021 [5]). A bug report carries one device clock and is not capped.

3.3 The function

Listing 1 combines the limits. The verdict is the weakest of the verdict that the stores allow and the cap that the boundary and the clock impose. The answerable depth of a question type on a device is the largest lag that its history stores reach with a usable clock: the larger of the horizons of its history stores, limited for device-bound types to the time since hi, and zero if the clock cap applies. For contact the boundary does not limit the depth, because it caps the verdict at partly answerable (Listing 1) instead of making it not answerable; the depth of contact is the reach of its stores, and the largest lag with the verdict answerable is shorter wherever lo lies inside that reach.

3.4 Witness stores

Table 2 lists, for each type and class, the stores that can hold the event and their semantics. The semantics follow the platform documentation where it exists [13], our earlier reports [6], [5], and the schemas of the stores themselves. A store is a witness only for the type listed. Other stores that speak indirectly (network statistics, powerlog archives, the interaction store) are used only to count how often another source reaches a lag (Section 5.7).

verdict(type, item, lag):
  witnesses = stores of the class for the type (Table 2)
  covering  = history stores present with lag <= horizon
  weak      = last-use or state stores present
  # 1 device-life boundary [lo, hi]
  if type is device-bound and D < lo:           return N
  if type is person-bound and D < lo:           cap = P
  if type is device-bound and lo <= D < hi:      cap = P
  if type is device-bound and no indicator:     cap = P
  # 2 horizon and record semantics
  if covering:  v = A
  elif weak:    v = P            # confirms last event only
  else:         v = N
  # 3 clock cap
  if v == A and clock rule failed or no anchor: cap = P
  return min(v, cap)               # order A > P > N

4 Evidence and Method

4.1 Evidence

The sample frame was every iOS and Android full file system extraction and every Android bug report in the Lab’s research corpus that was readable on the day of the study, without duplicates, with one extraction per device: 33 iOS extractions, 14 Android extractions and 7 bug reports (54 items). A comparison of device identifiers, recorded in private notes, found one pair of same-day iPhone extractions that is one handset (counted once) and no other repeated handset among the 34 iOS and 14 Android extractions. The seven bug reports come from seven devices (six distinct serial-number hashes recorded in private notes; the seventh report differs in manufacturer). Whether any of them is also one of the extracted phones was not tested; they are treated as seven items and reported as a separate class. The devices were not selected for this study.

The 33 iOS devices run iOS 26 (20), iOS 15 to 18 (12) or an undetermined version (1). The 14 Android phones run Android 16 (9) or Android 10 to 14 (5); 12 are Samsung. The 7 bug reports come from Android 16 (4), Android 15 (1) and Android 10 (2); 4 are Samsung and three come from other vendor families. The acquisition time T was the end time in the extraction record where one existed (18 iOS and 11 Android devices), otherwise the modification time of the archive (15 and 3), a weaker reference; for a bug report it is the header time.

4.2 Boundary indicators

On Android we used three indicators: the file time of the factory-reset marker in the boot-statistics folder (A1), the time of the first settings-history entry that sets the setup-complete flag to one (A2; the flag itself carries no time [8]), and the earliest first-install time of a present, non-system application (A3). On iOS we used the last exit from the setup assistant recorded in the setup preferences (I1), the value stored as the CloudKit start-up time in the same file (I2; we read the key name as stated), and the earliest file time among the setup assistant’s interface residue directories (I3). In a bug report we used the earliest first-install time of a non-system application (B1). An indicator is valid if it lies between 2012 and the acquisition time and does not fall within two days of the image-default time that most system applications share. The setup-state field of the iOS setup preferences records whether setup used the assistant or a restore. LAB-TR-0028 [8] doubts A1 on two phones; Section 5.2 gives the effect. All indicators are events inside the device’s life; each therefore bounds its start from above, and lo, the earliest, is the tightest bound.

4.3 Store measures

Each store was dated by one field and read read-only. File-name stores (usage statistics, App Ops discrete files, Biome segments, powerlog archives, network statistics, DropBox, notification history) were dated by the time in the name, as in LAB-TR-0021 [5]. SQLite stores were copied to a scratch area with their write-ahead logs and the oldest and newest dated record read with SQL (dates only): knowledgeC app-focus events, interactionC, call history, messages (on Android the text and multimedia message tables; LAB-TR-0028 [8] counts the text-message table only, so its message totals are smaller, but both papers find message stores on the same 13 of 14 phones and records older than the first boot record on the same 7), the TCC access table, the Photos asset table (assets with coordinates), the routine cache and the App Ops history databases. The installation log was dated by the first line of each file; its times are device local time with no zone, which does not change a horizon measured in days. For bug reports we read the usage-event, App Ops and package sections of the dump. Records dated before 2007 or after the acquisition were counted and excluded.

4.4 Protocol, amendments and statistics

The question types, witness stores, indicators and the function were written into a dated note before the first full run, after a look at file formats on a few devices. Three amendments were made after the first run and are disclosed: (1) the clock anchors for iOS were extended with powerlog archive names and unified-log header times, because the first run failed 12 of 33 iPhones against 6 in LAB-TR-0021 on the same rule; (2) App Ops history in the discrete-file form, used by Android 11 to 15, was added, because the first run read only the Android 16 database form and found no history on the five earlier phones; (3) a lag of 0.5 days was added to the grid. The sensitivity variants of Section 5.8 and the portable-store refinement of Section 5.7 are post hoc. The lag grid is 0.5, 1, 3, 7, 14, 30, 60, 90, 180 and 365 days. We report counts of devices, medians with quartiles, and a Wilson 95% bound where a count of zero is discussed; no significance test is applied.

4.5 Setup

One runner script measured every item in sequence, each in its own process with a time limit, and a second step applied the function and wrote a report of aggregates. It uses only the Python 3.14 standard library: a streaming reader of the archive’s central directory, zlib to read small members, sqlite3 on scratch copies, and a small decoder for Android Binary XML. All 54 items were read without error in 1,562 s of processing time.

5 Results

5.1 Clocks

The clock rule passed on 26 of 33 iPhones (failed 6, no anchor 1), on 13 of 14 Android phones (failed 1), and on all 7 bug reports. The counts equal those of LAB-TR-0021 on the same rule [5]. Of the 6 iOS failures, 5 had only the archive time as the acquisition reference, so the gap may measure later handling of the archive rather than the device clock. A failed clock caps a verdict at partly answerable; without the cap, messages and calls would be answerable at 30 days on 30 rather than 25 iPhones.

5.2 Device life

Devices were young relative to the lags examined here (Table 3). The median age at acquisition, measured from the earliest valid indicator, was 680 days on iOS (quartiles 157 to 1,283) and 530 on Android (263 to 696). 6 of 33 iPhones were under 90 days old and 3 of 14 Android phones under 180 days; 13 of 33 iPhones and 5 of 14 Android phones were under a year old. A question about a date a year before acquisition therefore reaches before the life of the device on more than a third of these phones.

The indicators do not agree, and the disagreement has a pattern. On Android the factory-reset marker precedes setup completion by more than a day on all 8 devices that have both, by a median of 70 days (range 26 to 195); setup completion and the first user-installed application lie within a day on 6 of 8. On iOS the last setup exit follows the setup residue by more than a day on 29 of 31 devices, by a median of 110 days, and it is the latest indicator on 32 of 32 devices; the two start-type indicators (residue and CloudKit start-up) lie within a day on 5 of 13. Two readings of “the start of the device’s life” coexist: the first provisioning of the hardware and the user’s completion of setup. Their interval is wider than 30 days on 27 of 33 iPhones and 9 of 14 Android phones. The setup-state field records a restore from a backup on 4 of 32 iPhones (2 from the cloud, 2 from a computer). A1 is the first boot record of LAB-TR-0028 [8], which found user setup a median of 98 days later on all 14 phones; the 70 days here are for the 8 phones that have both A1 and A2. That report judges A1 unsupported on two phones (Android 10 and 12), because the first media index lies months after it, and our validity rule kept both values. Without them the median Android age is 484 days (530 with all 14; 5 of 12 phones under a year), Android verdicts at 30 days and longer are unchanged, and short-lag counts change by at most two phones. It also found files named for a restore launch on 29 of the same 33 iPhones (meaning undocumented), so the setup-state field may record only some restores.

5.3 Stores and horizons

Table 4 gives the presence and horizon of each witness store. Biome app-focus segments, the main iOS witness for app use, were present on 25 of 33 iPhones with a median horizon of 38 days; the knowledgeC app-focus stream held records on only 2. On Android, daily usage statistics reached a median of 9.8 days and App Ops history 7.8 days, whereas call logs and messages reached a median of 762 and 994 days. Among history stores, those that reached furthest back were the ones the user fills and keeps: geotagged photographs, messages and calls. The call logs showed no cap at 500 entries (maximum 4,000 records on iOS and 2,500 on Android, held by two phones; a cap was not tested). Bug reports held a usage-event window of about one day (1.0 d) on 4 of 7 reports and an App Ops dump with last-access times reaching back a median of 432 days.

5.4 Answerability by type, class and lag

Table 5 and Figures 2 and 3 give the profile. A question one day before acquisition is answerable for use on 24 of 33 iPhones and 13 of 14 Android phones, but the share falls with the lag. At 30 days, app use is answerable on 17 of 33 iPhones and on none of the 14 Android phones, because the Android store that reaches 30 days holds only last use. Permission use is answerable on none of the iPhones at any lag, since the witness store, the TCC table, is a state, and on 2 of 14 Android phones at 30 days. Messages and calls are the most durable: 25 of 33 iPhones and 12 of 14 Android phones at 30 days, 14 and 8 at a year. A question about whether an application was installed is never answerable from the Android witness store, which is a state of present applications (12 of 14 phones are partly answerable at 30 days), and is answerable on 14 of 33 iPhones through the rolling installation log. At one year, only 1 of 33 iPhones can answer an installation question and 2 a question about a place. Bug reports answer no question as answerable at a lag of one day or more: their usage window is one day, and the other records are last use or state.

5.5 Which limit decides

Table 6 assigns each case that falls short of answerable (partly or not answerable) at 30 days to the first limit that fails. On Android the limit is record semantics: for use, 12 of 14 phones are partly answerable only because the stores that reach 30 days keep last use, and for installed and permission used 11 and 10. On iOS the limits are mixed. For use, 5 iPhones have no witness store at all (Biome and knowledgeC app focus absent), 5 are held back by the boundary, 3 by the horizon and 3 by the clock. For permission use, 27 of 33 iPhones are partly answerable because the TCC table is a state. The horizon, the limit that earlier work emphasises [5], decides few cases at 30 days and many at 90 (13 of 33 iPhones for use).

5.6 Permissions: grants without history

A grant is a standing state; a use is an event. The records that survive on a device keep the state and the last event, not the events. On iOS the TCC table holds a median of 160 rows per device, each with a decision and one date, the last change; 27% of the rows were changed within 30 days and 49% more than a year before acquisition. The table holds one row per service and requesting application, so a question of the type “used the camera on D” is at most partly answerable on iOS from this table (Table 5). On Android the access file holds a median of 2,081 dated entries per device, one latest access for each application and operation, and 39% of them lie within 30 days. App Ops history, where it exists, reaches a median of 7.8 days. On the 13 phones that have both forms, 66% of the last-access entries are older than the oldest history row. Such an entry is the only dated trace of an access beyond the horizon, and it can confirm that date and deny no other. In the bug reports the App Ops dump had 12,761 dated entries over 7 reports, 54% within 30 days.

5.7 Validation

Boundary rule. The function says that a device-bound question about a date before lo is not answerable. The rule is contradicted if a device-bound record of the device’s own life exists before that date. We tested it with the setup indicators alone (A1, A2, I1 to I3), so that records of stores could be compared with an indicator not derived from them (Table 8). Stores written by the device as it runs were never older: Biome app focus on 0 of 25 iPhones, the installation log 0 of 31, Android first-install times 0 of 12, daily usage statistics 0 of 14, App Ops history 0 of 13. Stores that can carry earlier data were: iOS TCC rows on 15 of 32 iPhones (median excess 1,155 days), geotagged photographs on 25 of 29, the routine cache on 5 of 27, interactionC on 4 of 30, Android usage statistics of longer intervals on 2 of 14 and the App Ops last-access file on 1 of 14. Messages were older on 17 of 30 iPhones and 7 of 13 Android phones, as the person-bound exception of the model anticipates. The failure is not confined to devices that record a restore: TCC rows were older than the indicators on 2 of 4 restored iPhones and on 13 of 28 iPhones set up with the assistant. Either the data were carried over without a recorded restore, or the indicators are later than the real start; the data do not separate the two. The refinement is a store attribute: a portable store keeps older records from earlier handsets or syncs, and a device-bound question before the boundary is partly answerable, not unanswerable, when such a store reaches the date. We fitted the attribute to these data; it is not validated on independent devices.

Documented limits. The Android source limits of ten days for daily usage statistics, one day for notification history and three days for DropBox entries [5] predict where the horizon of those stores ends. Of the 14 phones with daily usage statistics, 1 exceeded the limit by more than the tolerance (0.2 days), by 582 days, and that phone had failed the clock rule; none of 9 phones exceeded the notification limit and none of 13 the DropBox limit. On clock-checked devices the documented limits were not contradicted, which repeats the finding of LAB-TR-0021 on the same collection.

Other sources. For use, 16 of 33 iPhones fall short of answerable at 30 days (6 partly, 10 not); on 13 of them another source reaches that lag (interactionC on 13, powerlog archives on 4). On Android 13 of 14 phones have network statistics reaching 30 days (median horizon 98.5 days; powerlog archives on iOS 7.2 days). These sources answer indirect questions, contact with a person or network traffic of an application, not use; they show what could be asked next, not that the original question is answerable. At 180 days the other sources reach the lag on 7 of 33 iPhones and 3 of 14 Android phones.

5.8 Sensitivity

Two post hoc variants show how much the verdicts depend on how the boundary is read. Taking the boundary as a point (hi equal to lo) raises the answerable count for use at 30 days on iOS from 17 to 20 of 33, and for places from 21 to 25; on Android nothing changes at 30 days. Treating portable stores as partly answering before the boundary changes the verdicts only where a portable store reaches the date: geotagged photographs make 24 rather than 17 places questions at one year partly answerable on iOS.

6 Discussion

6.1 What a negative finding should say

A report that finds nothing for a date can state, from the item itself, three things: how far back the store that would hold the event reached, when the device’s life began according to its indicators, and whether the store keeps history or only the last use. With these the sentence “no event on 3 March” becomes one of three different statements: the store did not reach that day, the device did not exist, or the store cannot deny. Only when the verdict is answerable does the empty result support a negative statement, and then only for the capacity of the store, not for its completeness [11].

6.2 Young devices and carried-over records

The median phone was 530 to 680 days old, and more than a third were under a year old. A question about a date a year back therefore often reaches before the device. Yet the records that reach furthest back, messages, photographs and rows of the permission table, are kinds of record that can move from handset to handset, and in these data they were older than every setup indicator on a large part of the devices. The same dates that make a phone look like a long record of its user are the dates that say least about what this phone did. A date on the screen is not a date of this device.

6.3 Which other source would be needed

The limit that fails points to the missing source. If the boundary fails, the earlier handset, its backup, or the account that carried the data over holds the period. If the horizon fails, the source is one that keeps its records longer or elsewhere than the phone; the stores measured here do not. If the semantics fail, only a second acquisition at an earlier time, or a source with history, could add the missing events; the phone cannot. If the clock fails, a check of the acquisition time is the first step. We did not measure these other sources; the classification is a consequence of the model, not a finding.

6.4 Use with automated analysis

An analysis that answers questions over an extraction, by a person or by a program, needs the same three limits to say “cannot tell” instead of “no”. The function is small enough to be written into a report template: three numbers and one store attribute per question type. We did not test any automated reader.

7 Threats to Validity and Limitations

Internal. The witness stores, the five question types and the function were defined by the authors before the run, and another list would give other profiles; Table 2 states the list so that it can be repeated. The record semantics of each store were taken from documentation, earlier reports and the schemas, not from tests on a device with known events. The boundary indicators are events inside the device’s life and bound its start from above only; the earliest one is the tightest bound we have, not the start itself. The failure of the boundary rule was found on the same devices to which the refinement was fitted. The first boot record is taken as valid on all 14 Android phones although LAB-TR-0028 [8] doubts it on two (Section 5.2). The amendments of Section 4.4 were made after the first run.

Construct. Answerable means that a store of the right kind reaches the date; it does not mean that the store holds a record for the subject, that nothing was deleted from it [11], or that the extraction contained it. A history store was counted as present only if it held a dated record. The file times used for two indicators are device-local times in the archive and carry up to one day of uncertainty. A photograph with coordinates shows where a camera was, not that the phone was there. Place questions were measured on iOS only; no Android or bug-report store with coordinates was read, and those cells are marked as not measured.

External. The sample is one research corpus, not a random sample of phones. Most iPhones run iOS 26 (20 of 33), 9 of 14 Android phones run Android 16, and 12 are Samsung. Earlier releases and other vendors appear only as small groups; verdict counts for them are shown but not generalised. The Android phones of earlier releases store App Ops history in other forms, and the five that were read through the discrete-file form are dated by file name only. The bug reports are seven items of unknown relation to the extractions.

Conclusion. The comparisons are counts on a convenience sample; no test is applied and none is needed for the claims made. Shares carry wide intervals at these sample sizes: a count of 0 of 14 allows a true share of up to 22%.

Limitations. We did not read message content, so we cannot say whether a store holds a record for a particular subject; we did not run controlled events on a device, so the semantics of the stores are not checked against known activity; and we did not measure iOS sysdiagnose archives, cloud sources, or application-specific stores, which hold further history.

8 Conclusion

An empty result is an answer only when the phone could have given one. Defined by the start of the device’s life, the retention horizon of the store and the semantics of its records, answerability can be computed from the evidence item and reported with its reason. On 33 iPhones, 14 Android phones and 7 bug reports the device was often younger than the question, the stores that keep history reached from one day (bug-report usage events) to years (messages and photographs), and the stores that reach furthest keep last use or can carry records from other handsets. For a date 30 days before acquisition, app use was answerable on 17 of 33 iPhones and 0 of 14 Android phones, permission use on 0 and 2. A rule that nothing before the boundary belongs to the device failed on the stores that can carry records. Any reader can report the three limits with its results.

Future work, in order of value: (1) controlled events on Lab-owned devices, to test the record semantics and the portable attribute against known activity; (2) the same measurement on the larger pool of extractions, so that earlier releases and other vendors reach the cell minimum; (3) place stores on Android and application-specific stores as further witnesses; (4) a test of whether a reader that states the three limits changes what examiners conclude.