How Much of a Full File System Extraction Is Needed? Measuring Over-Collection and Third-Party Data in iOS and Android Extractions

1 Introduction

A full file system extraction copies the whole user-data volume of a phone: every message, photograph, app container, cache and log the device holds. Examinations rarely need all of it. The question is usually narrow, such as the messages between two people over a period, and the rest of the extraction is personal data of the user and of everyone the user has communicated with. Data protection law and criminal procedure in several jurisdictions ask that collection be limited to what the purpose needs (Section 2.1), and the UK Information Commissioner found that extractions were often excessive [7]. How much of an extraction a typical question needs, and how much of it concerns third parties, has however not been measured.

A motivating example. The Commissioner's report gives the example of an investigation whose obvious parameters are the text messages between two particular people over a specific period [7]. On the 31 Apple devices in our sample that held a message store, the files that answer this question (the message store and the address book that names the person) occupied a median of 65 MB, or 0.053% of a user-data volume whose median size was 106 GB. Within those files, the conversations with the device's most frequent correspondent held a median of 36% of all messages, and those with its median correspondent 0.02%; on a median device only 2.3% of messages were dated within the 30 days before acquisition (Sections 5.3 to 5.5). The data the example needs is therefore a very small part of what a full extraction contains.

The problem. Policy writing on phone extraction and privacy is extensive [6], [7], [12], and data-reduction studies of computer images report how much a reduction rule keeps [9]. What is missing is a measurement on current phones of three quantities that a proportionality judgement needs: what the extracted data consists of, how much of the person data concerns people other than the user, and how small the data needed for a defined question is. We ask four research questions.

• RQ1 (Composition). What does the user-data volume of a full file system extraction consist of, by class of data?
• RQ2 (Third parties). How much of the person-referring records concern people other than the user, and how many distinct third parties does one extraction describe?
• RQ3 (Footprint). How much of an extraction do typical examination questions need, in bytes and in records?
• RQ4 (Time). How much of the person-referring records would a 7-, 30- or 90-day window keep?

Contributions. This report makes four contributions.

• A counts-only measurement protocol for over-collection: a fixed path rule that assigns every file of the user-data volume to one of eight classes, a definition of third-party records and identifiers that is computed in memory and never records a value, and footprints of seven defined questions (Section 3).
• The composition of 46 user-data volumes of current iOS and Android phones, with medians, order-statistic intervals and cells of at least five devices (Section 5.1).
• The third-party share of four kinds of person-referring store and the number of distinct third parties per device, including the share of address-book persons who never appear in the device's communications (Section 5.2).
• The footprint of seven questions in bytes, the record-level footprint of a single-person message question, and the effect of time windows (Sections 5.3 to 5.5).

Scope. All results describe the Lab's research corpus: 34 iOS and 14 Android full file system extractions readable when the study ran, from 47 devices. Most devices run iOS 26 or Android 16, and 12 of the 14 Android phones are Samsung; cells of fewer than five devices are not reported. We measured sizes and counts, not content, and we did not judge what any real investigation needs; the question set is a defined, generic one. Section 7 states the limits.

2 Background and Related Work

This section summarises the minimisation duties that frame the question, then places the work among studies of selective collection, data reduction and third-party privacy in digital forensics.

2.1 Minimisation duties around phone extraction

We summarise texts we read; we do not interpret them for any jurisdiction or case. In the United Kingdom, personal data processed for law enforcement purposes must be adequate, relevant and not excessive in relation to the purpose [4], and the general regime states the same idea as data minimisation [14]. A 2022 statute allows extraction from a device that a user has provided voluntarily only where the authorised person reasonably believes that the information is relevant to a reasonable line of enquiry and is satisfied that extraction is necessary and proportionate; where there is a risk of obtaining other information, the person must be satisfied that no other means avoiding that risk exist or that using them is not reasonably practicable [8]. The Information Commissioner's 2020 investigation found that excessive amounts of personal data were often extracted, stored and made available, noted that the intrusion reaches everyone who has communicated with the user or whose contact details the user has added, found that many kiosks did not allow granular selection, some allowing only all standard text data or all data, and recommended a phased, recorded approach that considers collateral intrusion [7]. In the United States, the Supreme Court held that police generally need a warrant to search a phone seized at arrest, describing the immense storage capacity of modern phones and the many distinct types of information they hold [11]; federal prosecutors' guidance notes that almost every drive holds records unrelated to the investigation and that searches among commingled records should minimise unwarranted intrusion [3]. None of these texts says how much of a phone is unrelated data. That quantity is what this report measures.

2.2 Selective collection and data reduction

Selective imaging into digital evidence bags was proposed for acquiring selected data rather than whole media [13], and sifting collectors image only the disk regions expected to hold forensic value, collecting over 95% of the evidence at more than three times the speed in their authors' tests [5]. Quick and Choo reduced forensic images to a subset of selected file types, reporting subsets of 0.196% and 0.75% of the original volume for police sample data and public test images [9], and later applied reduction to forensic images and other electronic evidence [10]. These studies measure how much a reduction rule keeps; they do not ask which data concern people other than the user, and they predate the container-based storage of current phones.

2.3 Third-party privacy in examinations

Van Staden proposed filtering out the data of people irrelevant to an investigation by comparing it with the data of known targets [15]. Rowe lists violation of third parties' privacy among the privacy concerns of digital forensics and discusses automatic blocking of recognisable private data [12]. Horsman set out principles for preserving privacy in digital forensic examinations [6]. These works argue for limiting exposure; none reports how many third parties an extraction of a current phone describes.

Position of this work. We found no measurement, on current iOS and Android phones, of what a full file system extraction consists of, of how much of its person data concerns third parties, or of how small the data needed for defined questions is. The regulatory texts and the privacy proposals above supply the question; the reduction studies supply a precedent for measuring kept volume. The class composition, the third-party shares and counts, the address-book-only share, and the byte and record footprints of a question set on 47 current devices are new here, as far as we found. The measures are simple by design, so that any laboratory can repeat them on its own extractions without reading content.

3 Method

This section defines the unit of measurement, the data classes, the person-referring stores and how third parties are counted without being recorded, the question set, the time windows, and the sampling rule and statistics (Figure 1). The classes, stores, questions, strata and statistics were written into a dated note before any measure was computed; Section 3.7 states the copy rule, the added measure and the consistency checks.

3.1 Unit: the user-data volume

Archives in the collection differ in what they hold besides the phone's user data: most also carry the iOS system volume or the Android system, vendor and module partitions. To make extractions comparable we measure against the user-data volume: on iOS the volume mounted at /private/var, located in each archive as the prefix of mobile/Library/Preferences/; on Android the /data partition, located from the prefix of data/system/packages.xml. Sizes are the uncompressed member sizes in the archive's central directory; no file content is read for this step. Other volumes are reported separately.

3.2 Data classes

Every file of the user-data volume is assigned to one of eight classes by a fixed path rule applied in the order of Table 2; the first matching rule wins. The rule uses only directory names that the operating system defines, so it can be checked and repeated on any extraction. It cannot attribute a file to a person: a photograph in the camera folder may show the user or anyone else, and an attachment may have been received from a third party. The classes therefore describe what kind of data the bytes are; Section 3.3 measures whom the records concern.

3.3 Person-referring stores and third-party counts

Four kinds of store refer to people by design: the address book, the message store, the call history, and the people and face index of the photo library; on iOS we add the people table of the CoreDuet interaction store (Table 3). On Android we read the stores of user 0 only. For each store we count records and the records that refer to at least one person other than the user. A message counts as referring to a third party if its conversation has at least one participant who is not the user; a call if its peer identifier is not one of the user's own identifiers; an address-book record if it is not the user's own card. Photo-library people and faces are counts only, because no field we read marks the user's face; at most one person cluster can be the user.

Counting without recording. No identifier was written anywhere. Each phone number or e-mail address was normalised in memory (e-mail lower-cased; phone numbers reduced to their digits and to the last ten digits when at least ten are present; shorter numbers of at least three digits kept as they are), placed in a set, and only the size of the set left the function. The user's own identifiers were collected the same way, from the user's own address-book card and the accounts and caller identities of the iOS message store, and on Android from the profile store, the subscriber number of the SIM table and the phone-account address of the call log; they served only to exclude the user. A distinct third-party identifier is a normalised identifier that occurs in the address book, the message store or the call history and is not one of the user's own identifiers. An address-book-only person is an address-book record with at least one identifier, none of which occurs in the message store or the call history of the same extraction.

3.4 Question set and footprints

We defined seven questions that recur in examinations, each with the files that answer it on each platform (Table 4). The footprint of a question is the total size of those files, including write-ahead logs, in bytes and as a share of the user-data volume; the footprint of several questions is the size of the union of their files. A footprint is an upper bound on what a question needs, because it takes whole stores rather than matching records. For the first question we therefore also measure the record level: for every correspondent (an address-book person, all of whose identifiers are merged, or else a single identifier) we count the messages in conversations in which the correspondent takes part. We report the share of all messages held by the device's most frequent correspondent and by its median correspondent, and the number of other people present in the most frequent correspondent's conversations (collateral third parties).

3.5 Time windows

For message, call and photo-library records we computed the share dated within 7, 30 and 90 days before the acquisition. The acquisition time is the end time in the extraction record kept with the archive, converted with its UTC offset, or else the archive file's modification time. Records dated before 2007 or more than one hour after the acquisition were counted and excluded. A device enters the window analysis only if its newest dated record in these stores lies within 30 days before the acquisition; this excludes devices with a wrong acquisition reference as well as devices that had not been used for a month.

3.6 Sampling rule and statistics

Prevalence of each store is reported over every readable extraction. Distributions are reported over devices: one extraction per device (two extractions of one handset made on the same day count once; a comparison of hashed device identifiers found one such pair of iPhone extractions and no other two extractions of one device, so two iPhone extractions stored together count as two devices); a before-first-unlock extraction, which holds almost no readable user data, appears only in prevalence. Strata are platform; OS major version (iOS 26 against iOS 15 to 18 pooled; Android 16 against Android 10 to 14 pooled); and device class where a class has at least five devices. A cell with fewer than five devices is not reported. For each cell we give the median with a distribution-free 95% interval from order statistics (achieved coverage at least 93.8% for five devices and at least 95.7% for every cell of ten or more), the quartiles and the range. Shares of devices carry Wilson 95% intervals. Pooled shares (sums over devices) are given beside medians where they differ.

3.7 Copy rule, an added measure, and consistency checks

Android partitions outside /data are not counted as user data. For a store present at two user-0 paths, the copy holding the most records is used, with ties going to the copy modified last; a rule that used the copy modified last would choose an empty message store over a copy holding all messages. One measure was added: the footprint of the question set without the camera-media question, because media dominate the union. Three consistency checks were fixed in advance: (D1) the largest directories of the app-data and OS classes on one device of each OS stratum, to check that no class hides user media or communications; (D2) a second count of message correspondents by a different route (iOS: handles joined to messages against handles joined to conversations; Android: message addresses against the canonical address table); and (D3) the copy rule above.

4 Evidence and Setup

4.1 Evidence

The sample frame was every iOS and Android full file system extraction in the Lab's research corpus that was readable on the day of the study: 34 iOS and 14 Android extractions (Table 5). An inventory of the collection lists 101 distinct extractions of all kinds; backups, capture packages, bug reports and sysdiagnose archives were out of scope, and further extractions held elsewhere are not part of this sample. The devices were not selected for this study.

Of the 33 Apple devices, 19 are iPhones and the archives of the others do not state the device class; of the 14 Android phones, 12 are Samsung and two come from two other vendors. The archives held 6.5 TB in total, of which 6.0 TB lay in user-data volumes; 31 of the 32 iOS archives in the byte analysis and all 14 Android archives also carried more than 1 GB of other volumes. The acquisition time came from the extraction record for 19 iOS and 11 Android extractions and from the archive file time for the others.

4.2 Setup

One runner script performed every measurement in sequence, each extraction in its own process with a time limit (2,700 s for an iOS extraction, 1,500 s for Android), and wrote a report of aggregates in Markdown and JSON. It uses only the Python 3.14 standard library: a streaming reader of the archive's central directory that classifies every member as it passes, so that archives of several hundred gigabytes are measured without being unpacked; and sqlite3 on scratch copies of the person-referring stores and their write-ahead logs, deleted after each extraction. All archives were opened read-only. All 48 extractions were read without error, and no store failed to open; the run took 1,439 s.

5 Results

5.1 What an extraction consists of

The user-data volume had a median size of 106 GB on Apple devices (95% CI 81 to 145; range 4.5 to 546) and 51 GB on Android phones (37 to 146; range 7.6 to 565). App data, app code, the photo library and caches made up most of it (Table 6, Figure 2). On iOS the largest classes were app data (median 28.8%) and the photo library (18.5%), followed by caches (15.0%) and app code (13.5%); on Android app code came first (30.4%), then app data (23.3%). The system communication stores, which hold the messages, calls and contacts most questions start from, were small: a median of 2.9% of the volume on iOS and 3.8% on Android. Logs and diagnostics stayed under 1%. The OS class was larger on iOS 26 than on iOS 15 to 18 (median 7.3% against 1.4%), mainly through downloaded language, speech and photo-analysis assets (check D1, Section 5.6).

5.2 How much of the person data concerns third parties

The address book, the message store and the call history were present on 31 of 34 iOS extractions and on all 14 Android extractions; the photo-library database on 33 of 34 iOS extractions, and a gallery face index on 12 of the 14 Android phones. In every one of these stores nearly all records concerned someone other than the user (Table 7). Pooled over devices, 98.4% of iOS message records and 99.8% of Android message records lay in conversations with at least one participant other than the user, and 98.7% and 99.6% of call records had a peer other than the user; the per-device medians were at least 99.5%. Of the 18,436 iOS address-book records, 22 were the user's own card, found on 22 of the 30 devices whose address book held records.

Distinct third parties. A device held a median of 841 distinct third-party phone numbers and e-mail addresses on iOS (95% CI 513 to 1,728; n = 30) and 816 on Android (127 to 1,792; n = 14) (Table 8, Figure 3). At least 100 occurred on 28 of 30 Apple devices and 12 of 14 Android phones, and at least 1,000 on 14 of 30 (Wilson 95% interval 30% to 64%) and 6 of 14 (21% to 67%). Many of these people were not in the address book: a median of 480 (iOS) and 224 (Android) identifiers occurred only in the message or call records. Conversely, many address-book persons never occurred in the communications: pooled, 13,095 of 18,119 iOS and 3,500 of 4,842 Android address-book persons with an identifier (72.3% on both platforms) appeared in neither the message store nor the call history of the same device; the per-device median was 54.1% and 57.1%, and the share exceeded one half on 16 of 30 and 8 of 14 devices.

The photo library added people of its own. On iOS the face index held a median of 1,727 person clusters and 3,701 detected faces, and faces were present on 31 of 32 devices; named persons were rare (at least one on 11 of 32 devices). Since at most one cluster can be the user, nearly all clusters describe other people or false detections; the store does not tell which. The iOS interaction store held a median of 243 people with whom the device's apps had recorded an interaction.

5.3 How much the questions need: bytes

Each question needed a very small part of the user-data volume (Table 9, Figure 4). The message question (Q1) needed a median of 65 MB on iOS, 0.053% of the volume, and 15 MB on Android, 0.023%. The call, app, Wi-Fi, app-use and location questions each needed less than 0.05%. Together, the six non-media questions needed a median of 162 MB or 0.17% of the volume on iOS, about one byte in 600, and the five Android ones 17 MB or 0.028%, about one byte in 3,600. Camera media of the 30 days before acquisition dominated the union: with them, all seven questions needed 1,303 MB or 1.2% on iOS and 161 MB or 0.51% on Android. Put the other way, the user-data volume held a median of 83 times (iOS) and 208 times (Android) the data of all seven questions combined, and the archive as a whole more again.

5.4 How much the questions need: records

Below the file level, a question about one person needs only that person's conversations. On iOS the device's most frequent correspondent took part in conversations holding a median of 35.9% of all messages (95% CI 25.9 to 44.9; n = 30), and on Android 21.3% (15.0 to 31.3; n = 13). Even this correspondent's share stayed below one half on 22 of 30 Apple devices and on all 13 Android phones. The median correspondent's share was 0.022% on iOS and 0.071% on Android, because devices had many correspondents (median 314 and 225) and most of them exchanged few messages: a median of 4.0% (iOS) and 8.0% (Android) of a device's correspondents reached 1% of its messages. Group conversations brought others in. On iOS the top correspondent's conversations included a median of four other people (quartiles 0 to 20, at most 221), and at least one other person on 20 of 30 devices; on Android the threads of the top correspondent held no one else on any of the 13 phones.

5.5 Time windows

Person-referring records reached far back, so a date window removed most of them (Table 10). On the 26 Apple devices and 11 Android phones admitted to the window analysis, a 30-day window kept a median of 2.3% (iOS) and 5.9% (Android) of message records, 13.6% and 8.7% of call records, and 1.9% and 8.1% of photo-library assets. Pooled over devices the 30-day share of messages was smaller still, 1.5% and 1.2%, because devices with many messages held long histories. Calls were the most recent of the three: a 90-day window kept a median of 41.5% of iOS call records. Seven Apple devices and three Android phones were not admitted: on six and three of them the newest dated record lay 39 to 713 days before the acquisition reference, and one held no dated record. Eight photo assets dated before 2007 were excluded; no record lay after the acquisition.

5.6 Consistency checks

Table 11 summarises the checks. D1 found what the class names suggest: the largest OS-class directories were downloaded language, speech and photo-analysis assets, swap and model caches on iOS, and system modules, package caches and vendor logs on Android; the largest app-data directories were app containers and shared app groups. One exception lowers the photo class: on one iOS 15 to 18 device the system photo-library folder for shared libraries (2.3 GB) lay under mobile/Library/ and was counted as app data. D2 showed that the two routes to message correspondents rarely agree: the conversation route found more people on 27 of 31 iOS and 13 of 14 Android devices (median relative difference 18% and 28%), because conversations list participants who sent nothing and the Android address table keeps addresses of threads that no longer hold messages. Our identifier counts use both routes and so include such participants. D3 confirmed the need for the changed copy rule: 13 of 14 Android extractions held two or three user-0 copies of the message store, and on every one of them at most one copy held any message; the chosen copy held all of them.

6 Discussion

6.1 Most of an extraction is not needed by these questions

The seven questions are deliberately generic, and an examination may need more; but the size of the gap is the finding. On these devices, the files that answer six common questions occupied about one byte in 600 of the iOS user-data volume and one in 3,600 of the Android volume, and adding a month of camera media still left more than 98% of the volume unused. The largest classes, app data, app code, caches and the photo library, are where the bytes are, while the system stores that most questions begin with are a few percent. A full extraction is therefore dominated by data that a narrow question does not touch, and a selective collection of named stores is small enough to be practical. This matches, for current phones, the scale that data-reduction studies reported for computer images [9].

6.2 Who is in an extraction

The person data in an extraction is almost entirely about other people. This is no surprise for messages and calls, which involve two parties by nature, but the counts give it a size: a median device described more than 800 distinct third parties by phone number or e-mail address, and on 14 of 30 Apple devices more than 1,000. Two findings bear directly on proportionality. First, most address-book persons never appear in the device's messages or calls (72% pooled), so the address book adds hundreds of people to an extraction who are not part of any communication it records. Second, the photo library holds thousands of detected faces with no field that separates the user from others. A collection limited to the conversations of a named person avoided both; on iOS it still brought in the members of shared group conversations, a median of four people.

6.3 What a selective collection can and cannot do

Time windows reduce record counts sharply because the stores reach back far: a month kept a few percent of messages and photographs. Whether a window is safe depends on how far back the evidence of interest lies and on how long each store retains records, which is measured separately [2]. A file-level selection also has limits that a full extraction does not. Stores must be taken with their write-ahead logs, because counts change without them [1]. A store may exist in several copies, of which only one holds data (D3), so a selection by path must check record counts. And a footprint takes whole stores: the files answering a question about one person still hold everyone else's messages, so the record-level selection of Section 5.4 is a second, separate step. Data held by third-party messaging apps, which our classes place in app data, would need questions and stores of their own.

For practice, three measures follow from these results and can be reported with any extraction without reading content: the composition of the user-data volume, the number of distinct third parties per person-referring store, and the footprint of the question at hand. They give an examiner, a reviewer or a court a concrete size for the intrusion that a full extraction adds to what the question needs. We state this as a measurement, not as advice on what any law requires.

7 Threats to Validity

Internal validity. The class rule uses directory names; a file in an unexpected place is misclassed. D1 found one such case (a shared photo-library folder counted as app data), so the photo-library share is a lower bound, and cache directories whose names do not match the rule make the cache share a lower bound as well. Identifiers were normalised by a simple rule; two forms of one number that differ beyond the last ten digits count twice, and one of the user's own identifiers that was not recorded in the stores we read counts as a third party (none of the user's own identifiers was found on 5 iOS extractions and 1 Android extraction). The correspondent count includes conversation participants who sent nothing (D2). D3 shows that a rule that took the copy modified last would have selected empty copies.

Construct validity. A footprint is the size of whole stores and is an upper bound on what a question needs; the questions themselves are defined by us and generic, and real investigations may need other or more data. Camera-media windows use the archive's file time, which for camera files normally follows creation but can change on edits or restores; for devices whose acquisition reference was an archive file time, the window may be displaced. The window analysis excludes devices whose newest record is more than 30 days old, which also excludes devices left unused before acquisition.

External validity. The sample is the Lab's research corpus, not a random sample of phones or of devices examined in cases. Twenty of 33 Apple devices run iOS 26, 9 of 14 Android phones run Android 16, and 12 of 14 are Samsung; other vendors and earlier releases appear only in pooled cells or not at all. The users' habits shape every count. Results are stated per cell and are not generalised to other populations.

Conclusion validity. Cells are small, and intervals for Android medians are wide. Pooled shares are dominated by devices with many records and are reported beside, not instead of, medians.

Limitations. We did not measure third-party messaging and social apps, e-mail accounts, cloud tokens or browser data; the content of any file; deleted records; or backups and other acquisition types. We did not test whether a selective collection made with a commercial tool contains the same files. The question set and footprints describe what files answer a question, not what an examiner should collect in a given case.

8 Conclusion and Future Work

Whether a full extraction is proportionate to a narrow question has been argued without measurements of what an extraction holds. We measured, without recording any value, the composition, the third-party data and the question footprints of 48 full file system extractions of 47 research devices. Six common questions needed about 0.17% of the iOS user-data volume and 0.03% of the Android volume, and a month of camera media raised this to about 1% or less. The person data was almost all about other people: more than 98% of message and call records, a median of more than 800 distinct third parties per device, and a majority of address-book persons who never appear in the device's communications. A month's window kept a few percent of messages. On these devices, the data a typical question needs is a very small and well-defined part of a full extraction, and these measures can be reported with any extraction to size the difference.

Future work, in order of value: (1) the same protocol on the larger pool of extractions the Lab holds, so that earlier releases and other vendors reach the cell minimum; (2) third-party messaging apps, with store lists and footprints of their own; (3) a comparison of selective collections made by acquisition tools with the footprints defined here; (4) record-level footprints for further questions, such as a location history within a date range.