Exploring Privacy Leakage and Data Disclosure Violations in the MacOS Application Ecosystem

Exploring Privacy Leakage and Data Disclosure Violations in the MacOS Application Ecosystem Jyotirmay Chauhan

Kostas Solomos

Mir Masood Ali

University of Illinois Chicago Chicago, Illinois, USA jchauh3@uic.edu

Brandeis University Waltham, Massachusetts, USA solomos@brandeis.edu

University of Illinois Chicago Chicago, Illinois, USA mali92@uic.edu

Jason Polakis

arXiv:2608.05474v1 [cs.CR] 5 Aug 2026

University of Illinois Chicago Chicago, Illinois, USA polakis@uic.edu

Abstract

1 Introduction

The systematic and excessive data collection practices of tech companies have rendered online privacy both a necessity and a soughtafter commodity. However, while the privacy risks of the web, mobile, and IoT ecosystems have been extensively examined, desktop environments have been largely overlooked. As desktop apps continue to be widely used, they remain a critical yet understudied dimension of user privacy. In this paper, we address this gap by presenting the first, to our knowledge, comprehensive study of the mechanisms designed to regulate and disclose data collection and sharing practices in the macOS ecosystem. We adopt an app-development-centric view, and shed light on the interactions between the various macOS mechanisms that mediate apps’ data access. Driven by our findings, we develop NutriScan, an analysis framework that incorporates both static and dynamic analysis techniques to create a consolidated view of macOS apps’ data practices and disclosures. We use our system to dynamically analyze 1K macOS apps, and find that 85% of them access user-data APIs without disclosing it. 49.7% also exfiltrate data to advertising entities and hosting providers, 12.5% of which do so without a corresponding disclosure. We find that desktop apps are being leveraged by online trackers to enrich user profiles and device fingerprints, thus shedding new light on the true scope of the online tracking ecosystem. Our analysis reveals how the macOS app ecosystem is comprised of disjoint mechanisms with divergent data abstractions, thus increasing complexity for developers while also facilitating undisclosed privacy-invasive practices. Accordingly, we propose a series of mitigations that aim to both streamline the data disclosure process for developers and improve Apple’s app vetting process.

The proliferation of smartphones and Internet-connected devices has resulted in users constantly interacting with devices that generate, store, and transfer a plethora of private data. This abundance of data has given rise to surveillance capitalism [105], a complex ecosystem powered by pervasive collection and opaque sharing practices, where user data is brokered among corporations [37, 38]. The collected data enables the inference of sensitive and protected [57] user characteristics and behaviors [45, 88], highly effective advertising [59, 99] and misinformation campaigns [53]. Users have since grown increasingly concerned about privacy [50, 95], calling for better technical and legislative measures [83]. Consequently, there have been concerted efforts by browser and operating system (OS) vendors for the deployment of more effective anti-tracking and access control mechanisms, respectively [35, 65, 80]. At the same time, OS vendors have focused on deploying mechanisms that enable the disclosure of data practices in a more userfriendly manner, as opposed to the confusing legalese found in privacy policies. More specifically, Apple’s Privacy Nutrition Labels and Google’s Data Safety Sections provide the means for app developers to inform users about the data they collect, whether they share it with other parties, and how it is used [23, 64]. While the web, mobile, and IoT ecosystems have been extensively studied in regard to potential privacy leakage and violations [5, 7, 10, 36, 52, 66, 71, 77, 79, 84, 85, 92, 94, 98, 101], the desktop ecosystem has been largely overlooked even though 61.5% of online adults accessed the internet via desktop devices in Q3 2024, including 72.7% in the United States [1]. This oversight could be attributed to desktop apps not usually displaying ads and hence not typically being associated with privacy leakage. Nonetheless, it is currently unclear what role desktop apps play in the tracking and advertising landscape. Desktops fundamentally allow broader default access to user data, and macOS introduces a unique security and permission architecture that differs from iOS. These differences collectively motivate our study. Specifically, this includes (i) understanding what access control and disclosure mechanisms exist in a modern desktop OS, (ii) investigating whether desktop apps employ tracking and fingerprinting techniques, and (iii) verifying apps’ data practice disclosures. In this paper, we fill this gap by presenting the first, to the best of our knowledge, exploration of privacy leakage in desktop applications. We focus specifically on the macOS ecosystem, due to

ACM Reference Format: Jyotirmay Chauhan, Kostas Solomos, Mir Masood Ali, and Jason Polakis. 2026. Exploring Privacy Leakage and Data Disclosure Violations in the MacOS Application Ecosystem. In Proceedings of the 2026 ACM SIGSAC Conference on Computer and Communications Security (CCS ’26), November 15–19, 2026, The Hague, Netherlands. ACM, New York, NY, USA, 19 pages. https://doi.org/10.1145/3830454.3832715

This work is licensed under a Creative Commons Attribution 4.0 International License. CCS ’26, The Hague, Netherlands © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2871-6/2026/11 https://doi.org/10.1145/3830454.3832715

CCS ’26, November 15–19, 2026, The Hague, Netherlands

users perceiving it as a more private operating system compared to Windows [91], the presence of multiple OS-level security and privacy mechanisms [3], and Apple’s recent mandatory requirement for apps to release Privacy Nutrition Labels [25]. To that end, we develop NutriScan, a novel framework that leverages both static and dynamic analysis techniques to consolidate information across all relevant application components. This includes analyzing bundle components that define installation and run-time permissions for data access and protected system resources, and dynamically instrumenting native APIs to identify what data and capabilities are made available to the application. We also augment our analysis with network traffic to identify what protected data is transferred off the device. Finally, our system generates Nutrition Labels that accurately capture app behavior, and flags inconsistencies in official Nutrition Labels. Overall, our experiments reveal a troubling pattern of overly intrusive data collection practices alongside incomplete and incorrect data disclosures. Our data suggests that privacy screening procedures currently in place (if any) are insufficient, as developers often fail to disclose what data is being collected and shared by both first-party and third-party components, as reflected by the inconsistencies captured by NutriScan. Specifically, we find that only ∼ 15% of the tested apps correctly disclosed all data labels associated with the sensitive data they accessed. Crucially, developers did not account for the data collected by embedded thirdparty code in over 80% of the apps with manifest files. More importantly, we found sensitive user data, and immutable user and device identifiers being shared with advertising networks, including Google and Facebook. As such, despite Apple’s recent marketing efforts showcasing privacy as a major selling point, we find that even within their heavily guarded desktop environment, data protection and disclosure mechanisms are currently insufficient, necessitating a redesign of their mechanisms and a more stringent vetting process. In summary, our major research contributions are: • We explore the mechanisms that govern data collection and disclosure practices in the macOS ecosystem. • We develop NutriScan, a novel dynamic analysis framework that comprehensively evaluates macOS applications for incomplete or incorrect data disclosures. We have open sourced our system to enable developers to accurately report their applications’ data practices. [47]. • We conduct the first study of tracking and fingerprinting in desktop apps, and uncover the prevalence of inaccuracies and omissions in macOS’ Privacy Nutrition Labels. • We propose a unified data disclosure and verification process for mitigating the privacy violations that stem from the complex and disjoint nature of macOS mechanisms.

2

Background and Threat Model

Here we provide background information on macOS and its app ecosystem, which is pertinent to our work. Figure 1 illustrates a macOS application bundle and its components, resources, and associated metadata.

Jyotirmay Chauhan, Kostas Solomos, Mir Masood Ali, and Jason Polakis

1

Executable Components

2

3 6A

Main Code Frameworks Extensions & Helpers

Info.plist 6B

4

5

Non-executable Code Sign & Components Resources Notary

6

Property Lists

Manifest 6C

Entitlements

Figure 1: Application bundle structure and components.

2.1

App Structure and Lifecycle.

macOS applications are built, distributed, and executed within Apple’s ecosystem that integrates dedicated development tools, distribution infrastructure, and runtime enforcement mechanisms. Apple provides developers with Xcode, an Integrated Development Environment (IDE), which includes interface design, coding, and resource management, as well as integral tools for code signing and configuration [33]. App developers produce their own firstparty code 1 and also include third-party SDKs 2 during the development process. When an application is production-ready, Xcode packages the contents into a structured bundle, which developers can submit to the App Store [29]. A key component of the bundle is the Information Property List (Info.plist) 6A , which specifies app-related metadata, such as the bundle ID, version number, supported platforms, URL schemes, and document types [32]. Developers are also required to define security and privacy-relevant declarations to access protected system resources (e.g., camera, location). Entitlements define the capabilities that the app requests that require elevated privileges [30] 6C . System services use them to grant the app access to restricted APIs or privileged subsystems, such as iCloud storage, push notifications, or hardware devices. Another key component is the Privacy Manifest (.xcprivacy) 6B , a structured file declaring data practices for the app and embedded SDKs, using structured key values. Developers specify whether the app or an embedded SDK engages in tracking, and enumerate the specific data types collected (e.g., device identifiers, coarse location, phone number). Each data item is individually labeled to indicate whether it is “linked” to the user and annotated with the purposes for which it is collected, such as analytics, app functionality, or advertising [24]. Xcode aggregates these manifests into a single report at submission time [24]. Additionally, the macOS security model verifies the app at three distinct stages: (i) during the build via Xcode, (ii) during distribution through the App Store Connect submission and evaluation system, and (iii) at runtime through signature and integrity checks. Each step corresponds to distinct cross-stage verification and enforcement checks applied to bundle components, including metadata that define the app’s identity and capabilities, declarations of access to system resources, and disclosures of data collection practices. 2.1.1 è Build-time Verification. When developers build an app, Xcode assembles the source code, static resources, and configuration files into the bundle where different Apple mechanisms verify their validity and correctness. Specifically, Xcode validates Info.plist

Exploring Privacy Leakage and Data Disclosure Violations in the MacOS Application Ecosystem

entries structurally and semantically 6A , ensuring that declared access to protected resources (e.g., camera, location) is present as required for runtime access. During development, a developer may insert permission entries to the Info.plist file and Xcode automatically signs the binary with the necessary entitlements 6C . It also includes a CodeResources file containing the file hashes in the bundle 4 and signs it to ensure the app’s integrity. When the developer is ready to ship the app, they specify the team identifier, which allows Xcode to sign the bundle with the Apple Development certificate 5 , allowing the app to run on other systems. 2.1.2 Õ Submission & Compliance. Upon submission to the App Store, Apple performs a combination of automated and manual reviews to enforce platform-specific policies [26]. This process aims to verify code-signing integrity, validate entitlements, and ensure compliance with sandboxing requirements. Developers are also required to submit the app’s Nutrition Labels. The labels enumerate the categories of data collected (e.g., contact information, location, device identifiers), specify whether each category is associated with the user’s identity, and if they are used for tracking [21]. Labels are structured into three groups: (i) Data Linked to You (information associated with a personal identity), (ii) Data Not Linked to You (information purported to be anonymized), and (iii) Data Used to Track You (information correlated across apps or services). An example can be found in Figure 9 (Appendix A). 2.1.3 Ń Runtime Validation. When the app first launches, the system validates its origin and integrity. This includes code-signing checks and team identifier checks. The code is also checked for malware signatures by Gatekeeper and XProtect, Apple’s dedicated verification systems [31]. At runtime, access to privacy-sensitive resources (e.g., camera, microphone) is verified by the Transparency, Consent, and Control (TCC) framework [20] which combines checks with user prompts, verifying property list files and the system’s consent database before granting access. 2.1.4 ¿ Data Privacy Communication. Apple enforces a disclosure system that separates reviewer-facing and user-facing privacy information. Privacy Manifests provide machine-readable declarations used during the App Store review 6B , while Privacy Nutrition Labels present a simplified, human-readable summary for users. These mechanisms operate independently, and Apple does not perform consistency checks between them, which can result in conflicting or inaccurate disclosures. On iOS, developers must specify predefined “required reason APIs” when accessing fingerprinting-related interfaces [17]. This requirement does not extend to macOS [24]. Instead, within the macOS ecosystem, App Store disclosures coexist with broader system-level enforcement mechanisms, resulting in a distinct enforcement environment.

2.2

macOS vs iOS.

Mobile operating systems have diverged considerably from traditional desktop operating systems, especially with regard to application isolation and data access control [41, 86, 89]. Here we provide additional details about macOS and highlight some of the key differences with iOS.

CCS ’26, November 15–19, 2026, The Hague, Netherlands

 App Sandbox. macOS implements a sandboxing system for controlling applications’ behavior and capabilities within the system. Sandboxed apps are restricted from accessing files owned by other apps or the user, unless explicitly permitted (e.g., through system file-selection dialogs). The sandbox is enforced by the kernel using the Mandatory Access Control Framework (MACF), which checks policy violations at runtime. Since executing apps distributed outside the App Store is common practice in macOS, it provides more granularity over specific rules and constraints, which can be defined inside .sb files. Nonetheless, for convenience and standardization, Apple provides a default Sandboxing (App Sandbox), applied via the com.apple.security.app-sandbox entitlement, which is mandatory for all apps downloaded via the App Store. Apps distributed through other sources are not required to import this entitlement. Furthermore, each sandboxed app contains a filesystem hosted at /Library/Containers which mirrors a default user’s home directory structure (e.g., Downloads, Desktop). These directories are empty by default, and the app must request permission via the TCC to obtain access. Similarly, access to networking capabilities and Photos is also restricted by a combination of entitlements and TCC-prompts. The macOS and iOS sandboxes differ significantly in several key aspects. While iOS enforces a stricter, more contained sandbox model, macOS adopts a more flexible approach. Apps on iOS execute in strictly isolated containers, while apps on macOS can access standard user location and user-selected files. Developers on macOS also have access to several entitlements that provide exceptions to the App Sandbox [18]. Notably, there is no equivalent mechanism on iOS. These entitlements provide access to the main file system (apple.security.temporary-exception.files.homerelative-path) and the IPC system ( security.temporary-exception.machregister.global-name). Apps can use exception entitlements to directly control the system via Apple Events, a macOS-specific automation feature. Finally, app sandboxing is not mandatory on macOS, while it is enforced for the App Store applications on iOS. ” System settings storage. UserDefaults (also referred to as NSUserDefaults) is a key-value storage mechanism for storing application preferences across restarts and OS reboots [19]. It is an app-specific storage designed to record configuration data, such as UI preferences or language settings. For sandboxed apps, the UserDefaults store is saved under the Preferences subdirectory inside the app’s container. On both macOS and iOS, the UserDefaults file is prepopulated with specific system-derived default values (e.g., localerelated settings) required for the intended app functionality. Notably, Apple acknowledges that the contents of UserDefaults may reveal environment-specific information that can be leveraged for fingerprinting [19]. Summary. While macOS and iOS share several architectural and implementation features at both the system level (e.g., kernel, XPC Mach messaging, executable format) and the application level (e.g., app bundles, entitlements, TCC permissions), they are fundamentally designed around different security models. iOS follows a highly restrictive, closed ecosystem model, in which Apple enforces mandatory code signing for all executable code and discourages application distribution outside official channels. Permissions on iOS are tightly constrained, and apps cannot access arbitrary filesystem

CCS ’26, November 15–19, 2026, The Hague, Netherlands

1 Apple Resources

Jyotirmay Chauhan, Kostas Solomos, Mir Masood Ali, and Jason Polakis

2 Bundled Developer Declarations

3 Runtime Behavior Evaluation a Execution Flow Modification

4 Privacy Nutrition Label Analysis

APP App Store

Package Extraction

Privacy Manifest

Network Proxy

Execution Flow Modification

b User Interaction

Generated App Store Privacy Labels Privacy Label

Label Discrepancy Report

5 Extended Tracking Analysis

</> Developer Documentation

Source Analysis

Entitlements UI Automation

Permission Management

Generated Privacy Manifest

Extended Fingerprint Recognition

Extended Tracking Report

Figure 2: An overview of NutriScan’s components and workflow for evaluating macOS apps. locations outside their containers without explicit user authorization. Crucially, iOS does not expose a multi-user account model and each app operates under a constrained single default user context, reflecting its design as a single-user system. In contrast, macOS is designed to support more flexible and customizable workflows. It supports multiple user accounts and permits application distribution outside the App Store, allowing users to download and execute unsigned or non–App Store–signed code. While macOS employs mechanisms such as Gatekeeper and notarization to mitigate malware risk, these protections are not uniformly enforced across all execution paths, reflecting support for a broader set of development and user workflows. As a result, macOS must address both privacy and system security threats. Apps operate with broader privileges than on iOS, including access to user-selected files, system automation interfaces, and native APIs that are not available on the mobile platform. While prior work has primarily focused on privacy label compliance in the iOS ecosystem, macOS applications operate under a more permissive security model that both extends previously studied attack surfaces and enables additional privacy-invasive risks.

2.3

Motivation and Threat Model.

It is unclear what role, if any, desktop apps play within the broader online tracking ecosystem. Moreover, several of their characteristics are of particular interest when considering potential privacy implications. First, they provide direct access to native APIs that offer a plethora of device-specific information and immutable identifiers, which can be used by trackers to augment user and browserfingerprint profiles. Second, users typically log into desktop apps, thereby providing the identifier (i.e., email) necessary for linking together the user’s various devices [81, 82]. The risk of cross-device tracking is evident in FTC reports and prior studies that explored how companies employ cross-device tracking techniques to correlate different devices that belong to the same user [42, 48, 104]. Third, desktop apps can access other sensitive user data (e.g., address books, photo libraries) which can enable diverse privacy-invasive inferences. We provide a detailed breakdown of native API capabilities compared to browsers in Appendix B, highlighting how these capabilities can be leveraged for extending fingerprinting beyond the browser boundaries. The privacy implications of these characteristics become even more pronounced when considering our analysis of Apple’s data access mechanisms. More specifically, while App Store reviewers

verify the contents of the consolidated app privacy report generated from individual privacy manifest files, they do not use this information to verify the accuracy of the Privacy Nutrition Labels shown to users. This is due to the privacy manifest itself lacking a requirement for explicitly declaring reasons for accessing sensitive APIs (which can be used to fingerprint users, as we discuss in §4.3). While no prior work has evaluated the accuracy and completeness of macOS apps’ Privacy Nutrition Labels, studies have shown that labels for mobile apps are inaccurate [36, 98], further motivating our research. In this study, we are interested in privacy-invasive practices by first- and third-party code. We focus on a wide range of user and device-specific data that can be obtained by apps through native APIs, and misused for various scenarios. Indicatively, we highlight the following scenarios that capture different privacy-invasive behaviors: (i) enriching existing user ad profiles, (ii) correlating different devices operated by the same user, and (iii) deanonymizing an active private browsing session – e.g., code by Tracker is embedded in the active FOOBAR desktop app, while the user is also browsing www.example.com (which includes an iframe from Tracker) over incognito mode [96] in their browser, allowing Tracker to deanonymize the private browsing session. Overall, we are interested in capturing privacy-invasive practices that are not accurately disclosed (or covered by) apps’ Privacy Nutrition Labels.

3 NutriScan: Design and Implementation In this section, we detail the design and implementation of our framework, NutriScan. Figure 2 shows an overview of the framework’s components and workflow, which we detail next. 1 Apple Resources. Apple lists and distributes bundled macOS apps via its App Store (č), which also hosts apps for other platforms, including those aimed at iOS and iPadOS. Apple requires that developers submitting to the App Store ensure that the Nutrition Label and Privacy Manifest, among other declarations, reflect the data collection practices relevant to the submitted version of the app. To ensure the validity of our evaluation, we access app bundles directly from the App Store, instead of using third-party repositories. We also collect the corresponding user-facing Privacy Nutrition Labels that the developer has declared on the App Store. 2 Bundled Developer Declarations. Apps downloaded from the App Store are bundled and structured in a standard format (see §2). MacOS apps declare metadata relevant to the system by

Exploring Privacy Leakage and Data Disclosure Violations in the MacOS Application Ecosystem

CCS ’26, November 15–19, 2026, The Hague, Netherlands

listing key-value pairs in Info.plist, from which we extract the f API Hooking. Native API hooking is a technique often used app’s bundle identifier, version, and other metadata. in reverse engineering to redirect the flow of the execution pointer. f Privacy Manifest. Apple holds developers accountable for We use Frida, a dynamic instrumentation tool that adopts a tramall of the code included in their app, including any third-party poline code injection method, wherein it modifies the system’s exSDKs they include [16]. However, the size and complex nature of ecution flow so that when a target function is called it redirects these third-party codebases make it difficult for developers to inthe system to run custom code before returning to the target funcdependently ensure accuracy and completeness. Apple, therefore, tion [61, 62]. Frida does so by modifying the memory location of a target function on the fly. We modify the flow of the target promandates that third-party SDKs disclose their own data collection cess by adding logic within two event blocks; (a) code within an practices via a key-value list in a privacy manifest file, named onEnter block that executes before the target function is executed, PrivacyInfo.xcprivacy. When bundling the app, XCode (>=v15) and (b) code within an onLeave block that executes after the target includes manifests from all third-party SDKs in the output. We exfunction has executed. The modified function returns a callback, intract and parse all available privacy manifest files, which we then cluding a stacktrace of the current process, to the aforementioned map to the corresponding entries in the Nutrition Labels. event blocks, which allows us to differentiate between first-party To compare manifests with Nutrition Labels, we create a union and third-party execution. of all the manifest files present inside the app. This final file contains a superset of all NSPrivacyCollectedDataType values which Frida’s trampoline injection method adds overhead, especially for frequently called functions. Prior work that analyzed the cost we then compare against the application’s Nutrition Labels. We consider the presence of a manifest-declared data type (e.g., NSPriof hooking system and function calls across platforms found that Frida can add 128x physical memory overhead and 129x CPU User vacyCollectedDataTypeName) coupled with the absence of the corresponding data item (e.g., Name) from the Nutrition Labels as Time while instrumenting macOS APIs [78]). To ensure that our app instrumentation remains effective despite this overhead, we a discrepancy/violation. We note that we only flag a discrepancy when a Privacy Manifest item is found to be missing from the Nubalance program execution with logging, by detaching hooks from a target function after observing 10 calls to it. While this may result trition Label, but not the other way around. in our system missing certain details (e.g., an additional instance f Entitlements. While building the app, developers can add Capabilities to help the app access certain system resources (e.g., aut- of a third-party SDK calling a specific API that has already been logged), it improves our system’s efficiency and reliability. ofill, access to background tasks). The contents of these entitleReading and modifying processes on macOS requires access to ments help us evaluate a set of sensitive resources that the app the task_for_pid Mach (IPC) call, which is denied by default by accesses, a subset of which maps to entries in the Nutrition Labels. System Integrity Protection (SIP, an XNU kernel extension). We We parse Apple’s Documentation[30] and third-party sources [68] to assemble a definitive list of entitlements. Since several entitledisable SIP on the test device by booting it into recovery mode [15]. ments remain undocumented by Apple, we cannot guarantee comDisabling SIP can be detected by apps, which could result in deceppleteness in our list of entitlements; however, our final list of entive apps changing their behavior to avoid detection. As such, our titlements was sufficiently complete to allow us to parse all of the findings in §4 present a lower bound of privacy-invasive behaviors. entitlements encountered when analyzing the apps in our dataset Network Proxy. Apart from recording relevant API access, we (see §4). We also map entitlements to Nutrition Labels’ data items inspect network traffic to detect the exfiltration of collected data. such as name, physical address, coarse location etc. This mapping We use the man-in-the-middle proxy (mitmproxy) [49], which requires installing root certificates on the device so as to capture was done independently by two researchers, who provided the all HTTP(S) and DNS requests sent from the evaluated app. Nusame mapping for over 90% of the cases. For example, ”com.apple.security.personaltriScan parses the collected network traces to identify instances of information.addressbook” was mapped to Name, Physical Address. In the few cases where there was disagreement, the final mapping collected data being transferred, along with details of the domains that receive it. was resolved through mediation and discussion with a third reWe also integrate certificate-unpinning via the SSL Kill Switch [54] searcher. The full mapping can be found in Appendix C. Using our mapping, we create an enriched profile for each app Frida script, which overrides SSL checking functions in several and subsequently compare this against the label to the actual Nupopular libraries. This script is also injected before the entry point trition Label to identify discrepancies. We further analyze the disof the executable allowing us to intercept TLS traffic from applicacrepancies based on the individual data items. Each discrepancy tion launch. Apps may include customized SSL pinning logic which between the generated Label and what the app declared counts as can be hard to generalize and bypass thus leading to a subset of neta single violation. work requests not being intercepted. This is a known challenge, which has affected prior studies as well [98]. 3 Runtime Behavior Analysis. An app’s runtime behavior provides reliable insights into its data collection practices. We develop b User Interaction. UI automation is performed using a a dynamic analysis approach that evaluates app behavior across heuristic-based approach via Apple’s Accessibility API. Our script multiple dimensions. captures the app state as a nested tree data structure, where each UI element forms a node. This tree is fetched after each interaca Execution Flow modification. We follow a two-pronged tion; login pages and forms are detected via heuristics and popuapproach for observing the app’s behavior upon execution: modilated with synthetic data. The interaction script follows a weighted fying memory at runtime (required for Frida) and intercepting netsemi-random approach to select interactable elements and execute work traffic via a proxy. the selected action.

CCS ’26, November 15–19, 2026, The Hague, Netherlands

Jyotirmay Chauhan, Kostas Solomos, Mir Masood Ali, and Jason Polakis

The tool identifies elements such as Text fields and generates our system’s capabilities in detecting application-component disrandom text of varying lengths to fill them. The tool can also procrepancies in bundle-level declarations (§4.1), identifying Nutrivide apps with inputs from the filesystem via Apple’s Finder App tion Label violations via data exfiltration through application be(filepicker), such as picking a media file for a media player or spechavior (§4.2), and also extend our analysis to device-based fingerifying the output directory. Our navigation flow covers a wide printing capabilities in macOS applications (§4.3). range of user interactions, so that our tool can navigate an app Experimental Setup. We use an M4 Macbook Air to run our more effectively than basic monkey testing [58]. experiments, and create a fresh Apple account to download apps onto the device from the official Apple App Store. To collect repref Permissions. Apple enforces runtime checks on sensitive sentative data, each app is individually executed for ∼5 minutes, a resources like the camera, microphone, and filesystem. In such sitthreshold selected after exploratory analysis showed no additional uations, macOS prompts the user to provide explicit permissions. violations beyond this point. This is also consistent with prior reOnce granted (or denied), the system records this choice in a usersearch on mobile dynamic analysis [36, 98] (nonetheless, we note specific database that it queries during future attempts. We enthat our results represent a lower bound, which could be further sured that all user permission prompts that pop-up during interamplified with longer exercise times). For apps requiring an acaction are accepted. This has two benefits: (i) it ensures that our count, a single account was created while all other aspects of the tool’s interaction with the app remains uninterrupted, and (ii) it app interaction, such as logging in and UI clicking, are automated. allows us to capture all observed permission prompts by accessing After completing the dynamic analysis, all callback logs are autothe app’s permission database at the end of its interaction session. matically processed to generate accurate Nutrition Label for each 4 Privacy Nutrition Label Analysis. Subsequently, NutriScan application and to produce an aggregate report including the violacollects the logs generated during the app’s execution and comtions and discrepancies detected by NutriScan across our dataset. pares them against the app’s Nutrition Labels. We consider four Dataset. While Google provides detailed ranking and popularperspectives (marked with f in Figure 2) to an app’s data collecity metrics across app stores (e.g., Google Play Store, Chrome Extion practices. We independently consider each source and develop tension Store), the Apple App store does not disclose specific staunique mappings between its taxonomy and the taxonomy used tistics or a single global ranking for macOS or iOS apps. Instead, it by Apple’s Nutrition Labels. We first map API calls to the data publishes category-specific lists of popular apps that are updated types which should be declared. Then for each API call made by based on proprietary metrics, including recent download activity. the app, we add the mapped labels to create an accurate Nutrition Since download statistics are not publicly available, we use the Label, which is the union of all unique data labels. NutriScan then number of user ratings as an indicator of application popularity. compares the results of the mappings against the actual Nutrition To construct our dataset, we initially assembled a list of all app Labels obtained from the App Store, and flags any discrepancies. URLs via the sitemap[28] of Apple’s website, which we used to 5 Extended Tracking Analysis. While Nutrition Labels proscrape their app webpages. Interestingly, upon closer inspection, vide an overview of the app’s data collection, they do not accuwe found that Apple’s sitemap only includes iOS and iPad apps rately capture its tracking capabilities, as they do not account for while excluding macOS apps. Moreover, when a particular macOS device fingerprinting (in online tracking this is typically achieved app also has an iPad or iOS version, the app’s metrics (such as its through browser fingerprinting [73]). This relies on collecting a rating or number of ratings) correspond to the iPad or iOS version wide range of device characteristics like the screen resolution, model, instead of the macOS version. The macOS version’s ratings, which OS version, GPU vendor, etc. Individual attributes are not unique often differ significantly from the iOS or iPad version, are only but can provide a high-entropy identifier when combined. To acavailable within the dedicated App Store application. count for such practices, we created a table of attributes using MaTo enhance our dataset, we leveraged AppFigures [11], a popucOS’s system_profiler and the test user profile, and mapped it lar app analytics platform. We scraped the top 250 ranked Mac apps to individual data items like user id and device id. We also for each of the 20 different categories, merged them and filtered for included coarser device attributes not covered explicitly by Nutriapps which were designed for macOS. For each selected app, we adtion Label. Our system searches for these attributes in the network ditionally scraped their app store webpage to collect the user rating traffic. This is a well-established strategy for identifying apps exfilcounts. This resulted in over 1,800+ apps, ranging from highly poptrating data of interest; we adapted hashing and encoding techular apps such as Microsoft Word (1.7M ratings) to smaller and less niques from prior work [56, 87]. We consider multiple hashing popular applications such as the Visio File Editor (1 rating). We sub(e.g., MD2/4/5, SHA1/224/256/384/512, MMH3) and encoding (e.g., Base16/32/58/64, sequently excluded 350 applications that employed anti-analysis gzip, LZ-string) functions. For each identifier of interest, we pretechniques, which prevented dynamic instrumentation via Frida. computed a pool of potential multi-layered hashed and encoded Accordingly, our final dataset (referred to as TotalApp) consists of values, which we search for in captured traffic including the Retwo different subsets: (i) 500 popular apps based on the number of quest URL, the body of POST requests, and response bodies. user ratings (TopApp), and (ii) 500 apps randomly selected from the remainder of the collected apps (RandomApp). TopApp spans a wide range of categories, including Productivity (17%) Utilities (15%), Games (5.7%), Photo and Video (8.7%), Business (5.9%) Music (6.9%) 4 Experimental Measurements and Health & Fitness (2.7%) among others. Similarly, RandomApp includes applications from categories such as Productivity (3.3%), In this section, we provide the first measurement study on privacy violations in the macOS desktop environment. We demonstrate Utilities (5.7%), Developer Tools (10%), Graphics & Design (8.1%),

Exploring Privacy Leakage and Data Disclosure Violations in the MacOS Application Ecosystem

Education (5.5%) and Business (5.9%) among other categories. For each app in the dataset, our system parses the Info.plist to extract the bundle identifier, and to also retrieve each application’s information and nutrition label values via iTunes’s public API [34]. We also detected that 14.9% of the applications restricted functionality by requiring an account, for which we manually registered a dedicated test account. In addition, 47 applications in our dataset offered a free trial associated with our Apple account, which we activated during dynamic analysis [46]. Attribution. As part of our analysis, we are interested in attributing data access and potential discrepancies to first- or thirdparty code. We define first-party origin to include both application developer provided components and Apple-provided system libraries and frameworks bundled with macOS, as these are required dependencies for all applications. Any other origin is classified as third-party. For Privacy Manifests, each file is present inside a parent folder which contains the name of the associated framework or the SDK. Since native macOS components do not define manifest files, we use the location of the manifest file in the app bundle to determine whether it is first party or third party. Regarding API hooking and backtrace attribution, our system captures the sequence of binaries, dynamic libraries and frameworks involved in each function call. These typically include Apple frameworks and system libraries (e.g., UIKit [14], CFNetwork [12], libsystem_pthread.dylib, and libobjc.A.dylib), the application’s core binary (e.g., VPN Unlimited [69]), or third-party libraries and frameworks (e.g., FirebaseCore or FirebaseCrashlytics [60]). First-party binaries are identified by matching the binary name to the application name. The primary challenge in this process, is to identify the native framework and SDKs, since there is not available documentation for all system components. To address this, we curated a reference list using a combination of open-source GitHub repositories [6, 93], search engines, and macOS system file listings. Any frameworks, SDKs, or binaries not identified as first-party or native Apple components are classified as third-party.

4.1

Bundle-Declared Privacy Capabilities

In the first stage of our analysis, we analyze each application’s bundle to collect its declared privacy capabilities. We extract the set of permissions specified in its Entitlements and parse the associated Privacy Manifest to determine the declared data-access requirements. Both entitlements and manifests specify these permissions differently (section 2). While manifests contain developer disclosures about the data collected (similar to Nutrition Label), entitlements are more granular and directly affect the app’s runtime privileges. Declarations are then compared against the corresponding Nutrition Labels to identify missing data items, i.e., discrepancies. Entitlements. All 1,000 applications analyzed by NutriScan declare at least one entitlement, consistent with Apple’s development model, which requires applications to be code-signed with a dedicated entitlement (e.g., com.apple.security.app-sandbox) for effective distribution [27]. We identified entitlement discrepancies in 82.8% of the applications (n=828), where applications declared

CCS ’26, November 15–19, 2026, The Hague, Netherlands

Table 1: Distribution of apps with discrepancies between their declared entitlements and corresponding Nutrition Label data types. (For more details see Table 6, Appendix.) Entitlement

Discr. (%)

Top. (%)

Random. (%)

95% 93.6% 93.8% 92.3% 90.8% 88.8% 90.7% 89.4% 87.1% 86.6% 86.1% 84.5% 80.9% 68.7%

94.1% 93.8% 93.9% 93.8% 90% 66.6% 87.7% 88.2% 89.4% 84.7% 87.6% 84.5% 75% 61.5%

95.7% 93.4% 92.8% 89.6% 92.1% 100% 94.5% 90.4% 83.3% 92.3% 84.5% 84.4% 100% 100%

100% 100% 93.6% 90.3% 90.7% 66.6% 65% 50%

100% 100% 90.5% 89.4% 87.1% 50% 66.6% 50%

100% 100% 100% 91.6% 97.3% 100% 64% N.A.

100% 100%

100% N.A.

100% 100%

com.apple.security files.user-selected.read-only personal-information.location personal-information.addressbook files.downloads.read-write personal-information.photos-library files.downloads.read-only files.user-selected.read-write device.microphone assets.pictures.read-write personal-information.calendars device.audio-input device.camera assets.pictures.read-only temporary-exception.files.home-relative-path.read-only com.apple.developer healthkit healthkit.access ubiquity-kvstore-identifier networking.networkextension ubiquity-container-identifiers in-app-payments game-center financekit com.apple mail accounts.appleaccount.fullaccess

at least one entitlement that grants access to data not disclosed in their Nutrition Labels. Table 1 presents the proportion of apps where a declared entitlement’s data type is absent from the Nutrition Label. We find that the majority of apps exhibit high omission rates across all entitlements, with several reaching 100%, indicating that no apps containing that entitlement declared the associated data access in their Nutrition Labels. In the com.apple.security namespace discrepancies span both file operations and user data access. The highest omission rates occur for personal-information.addressbook, files.user-selected.read-only, and personal-information. location. The com.apple.developer namespace exhibits a similar omission pattern, with complete omissions for sensitive APIs, including health data and contact information. Moreover, Apple-related integrations (e.g., mail, and appleaccount.fullaccess lack any corresponding disclosure in the Nutrition Label, indicating that omissions persist even for capabilities tied to highly sensitive, platform-level services. Notably, we found that Apple’s own Swift Playground application doesn’t declare the fullaccess entitlement, an Apple-exclusive entitlement with complete access to the user’s iCloud, Mail, etc. These omissions have a direct and significant impact on user privacy, as users are not aware of the data access capabilities they grant to applications at installation time. We also compare data labels which are tied to explicit user consent [20] against data labels which are not. As Figure 3 shows, entitlement violations rate remained high in both cases. Sensitive Info (Health Data), Emails and Text Messages, and Credit Info exhibit 100% discrepancy, as none of the apps declared the appropriate entitlements in their Nutrition Label.

CCS ’26, November 15–19, 2026, The Hague, Netherlands Disclosure-only

Runtime Permission

Discrepancy Rate (%)

100 80 60 40 20

Em

ai ls

O

rT

ex

tM Se ess ns ag iti es O ve th er Cr In U ed fo se it r C Inf on o te Pa U nt ym ser en Id Pu tI n rc ha N fo a Em se H me Ph ai is ys l A tor Ph ica ddr y ot l A es os dd s O re r V ss Pr Au ide ec di os o C ise Da oa Lo t rs ca a e Lo tion ca tio n

0

Figure 3: Discrepancy rates between declared entitlements and Nutrition Labels data types, grouped by disclosure-only access and TCC-protected runtime permissions.

Privacy Manifests (%)

60

40

20

Oth e

rD ia Oth gnos ti e Pe r Dat c Data rfor a ma Type nce s Da Pu rch Devic ta ase e Id His tory U Pro Cra ser I d duc sh D Co t Inter ata Oth arse L action er U oca ti s Em age D on ail Ad ata dre ss P Cu hone Name sto Nu m m e Ph b oto r Sup er sO p r V ort S e id O Oth ther arch H eos er U Use is ser r Co tory n Co nta tent ct Oth er F Audio Info i Ad nanc Data ia ver tisi l Info ng D Co ata nta c He ts alth

0

Jyotirmay Chauhan, Kostas Solomos, Mir Masood Ali, and Jason Polakis

37.5% of manifest declarations lack a matching Nutrition Label entry. This label represents coarse devices attributes (chipset model, OS versions) and software telemetry (network or GPU performance). This is a catch-all category for “purposes of measuring technical diagnostics related to the app” [21]. Additionally, Nutrition Label omissions were detected for Other Data Types (20.2%), Device ID (12.5%), and Purchase History (9.5%). Manifest files in SDKs are intended for developers when integrating third-party components into their applications. The high rate of discrepancies detected by NutriScan indicates that developers often overlook these files. This may be due to various factors, such as a lack of awareness of Privacy Manifests or confusion caused by Nutrition Labels [76]. Prior work has also reported that developers can be confused or misunderstand the scope of permissions requested by third-party libraries [90]. Other cases may exist due to developers collecting data for debugging and, thus, considering that data collected for testing purposes does not need to be disclosed. Finally, discrepancies could also reflect intentional underdisclosure, as work has found that permission abuse can lead to app removal by users [40]. Privacy Disclosure Inconsistencies. Overall, the divergence between Nutrition Labels and bundle declarations reveals systematic omissions. This misalignment enables applications to collect user and device data without accurate disclosure, thereby preventing users from understanding the apps’ privacy practices. The consistently high omission rates across major functionalities reveal a structural weakness in macOS’s verification process, which detects the presence of a Nutrition Label but does not verify its consistency with declared capabilities. Given the scale and compliance obligations of major third-party services, these omissions demonstrate that the misalignment extends beyond application developers and further weakens the reliability of Apple’s privacy label mechanism.

Figure 4: Discrepancies across Nutrition Label data types and privacy manifests.

4.2 Privacy Manifests. While entitlements declare system-level capabilities, privacy manifests disclose data collection at the SDK level. We extracted 588 privacy manifests in total from our dataset. Of these, 67 (11.3%) applications included a first-party or app-wide manifest, which is generated during the build process, while the majority (88.6%) originated from third-party providers. Over 70% of all apps with Privacy Manifests (n=588) did not declare any CollectedDataTypes. Among the remaining apps (n=168), 135 (80.3%) apps declared CollectedDataTypes in their manifests that were absent from the corresponding Nutrition Labels. Overall, discrepancies were detected in 92.3% of the first-party manifests (n=12) and in 78.2% (n=122) of the third-party manifests. The discrepancies typically involved fields such as Other Diagnostic Data, Device ID, and sensitive fields like Coarse Location and Email Address. While entitlements allow an app to access specific data types, manifests disclose the type of data being collected. Each violation in privacy manifests amounts to a data label being collected without a corresponding disclosure. Figure 4 illustrates the discrepancies between privacy manifests and the corresponding Nutrition Labels. The highest affected type is Other Diagnostic Data, where

Behavior-based Violations

Next, we analyze application runtime behavior to detect privacy violations, defined as cases in which an app accesses or transmits user or device data without a corresponding Nutrition Label declaration. We compare their data flows to declared capabilities, to detect non-disclosed data collection and transmission, and reveal behavior-based inconsistencies beyond the bundle-level analysis. Runtime Traces. We applied our dynamic analysis pipeline (§3) to TotalApp, collecting execution traces, native and third-party API calls, and associated data. NutriScan then maps the runtime behaviors to their corresponding Nutrition Label categories, allowing the direct comparison to their reported disclosures. We evaluated app developers’ adherence to App Store requirements for declaring data collection practices to end users, by comparing the Nutrition Labels with the data collection observed through the hooking of Native API Calls. To quantify the extent of non-compliance we calculate the following metric: Non-compliance = 1 − 𝐴∩𝐵 𝐵 A:= Set of Data Types declared within Nutrition Labels. B:= Set of Data Types observed from Native API Calls. Figure 5 illustrates the distribution of non-compliance for the apps in our dataset. Each undeclared data type (e.g., Name or User ID) is

Exploring Privacy Leakage and Data Disclosure Violations in the MacOS Application Ecosystem TotalApp

RandomApp

CCS ’26, November 15–19, 2026, The Hague, Netherlands

TopApp

1st-party

3rd-party

Violation Origin(%)

100

80

60

40

20

80 60 40 20 0

0 10

20

30

40

50

60

70

80

90

100

Number of Apps (%)

Figure 5: Degree of Nutrition Labels non-compliance across evaluated applications.

Pr Au ec dio i Ad se Da ve Lo ta Ph rtis cat ys ing ion ic a D Ph l A ata d Ph one dre s o O tos Nu s m th er Or be U Vi r se d e Em r C os ai ont l A en dd t r Br ow De ess si vic C ng e oa Id rs His e to Pa Loc ry ym ati en on C t In re di fo tI nf N o am U e se rI d

Non-compliance (%)

100

Figure 7: Breakdown of violations by attribution to first or third party.

100

Apps (%)

80

60

40

20

C

oa

rs

e

Lo

ca

tio

N n am U e s Ad D er ve ev Id rti ice s Pa ing Id ym Da en ta Ph C t In ys red fo ic a it In P l O ho Add fo th ne r es er s U N Ph se um ot r C ber os o O nte r V nt Pr Au ide ec dio os is e D Em Lo ata c Br ail ati ow Ad on si dr ng es H s is to ry

0

Figure 6: Distribution of violations by Nutrition Data Labels. counted as a single violation, regardless of whether it is accessed by one or multiple API calls. Approximately 15% of the apps were fully consistent with their Nutrition Labels, achieving complete compliance and accurate privacy disclosure. Prominent apps among these include Microsoft Excel, One note and Outlook. While these apps collect sensitive identifiers like Device ID, Email address, Coarse Location and Contact Data, they accurately disclose it in their Nutrition Label. Nevertheless, the fact that only 15% of the apps achieving full compliance is a concerning finding and comparable to the extent of non-compliance reported for mobile apps [36]. Moreover, 60% of the apps omitted half the data types that they collect from their Nutrition Labels, and approximately 38% did not declare any of the data types, resulting in total non-compliance. While most of these cases are less popular apps, the popular LetsVPN app [4]1 declares in its Nutrition Label that “No Data is Collected“. To make matters worse, LetsVPN’s privacy policy [74] which is publicly available in the app’s App Store page, states that the app collects Device ID, Purchase Information among other data types. Under Apple’s Nutrition Label guidelines, this type of data collection is required to be disclosed. NutriScan further detected that 1 While the Apple App Store does not provide download numbers, indicatively, LetsVPN has 5M+ downloads in the Android Play Store.

LetsVPN accesses User ID, Device ID, and Coarse Location at runtime, indicating a discrepancy between declared and observed data practices. In contrast, we find that widely used apps (e.g., WhatsApp) are more likely to provide accurate Nutrition Labels. Notably, we detect substantial variance in the non-compliance rate between TopApp and RandomApp. A larger fraction of apps in the randomly selected dataset are non-compliant compared to popular apps. Nearly 45% of apps in the random dataset are fully noncompliant compared to 30% for popular apps. One potential factor contributing to the higher non-compliance among less popular applications is differences in available resources. Popular applications are typically developed by larger organizations with dedicated teams, which allows higher attention to privacy compliance compared to less popular applications. Our results demonstrate that runtime behaviors diverge significantly from declared privacy practices, indicating that Apple’s disclosure mechanism is neither effectively enforced nor consistently adopted by developers. Data type Violations. To quantify the impact of runtime behaviors on the accuracy of Nutrition Labels, we mapped omitted data types for each app and measured their prevalence. As shown in Figure 6, the most frequently undisclosed item was Coarse Location, detected in approximately 70% of the apps and primarily exposed through Apple’s NSUserDefaults API, which exposes the nearest major city. This value is set by macOS when selecting the system’s timezone. Other categories of PII, including Name (30.1%), User ID (24.5%), and Device ID (18%), were also frequently collected without disclosure. Since apps access combinations of identifiers and data in parallel, violations do not occur independently. The most common combination involved was User ID, Name, and Coarse Location, while another frequent pattern involved simultaneous collection of Device ID and Coarse Location. These overlapping violations increase privacy risks as they can be leveraged to cross-link user identities across devices and online contexts. Violation Origin. We further attribute API accesses to first- or third-party based on the Frida backtrace. This backtrace captures the stack at the time of execution, and maps the memory locations

CCS ’26, November 15–19, 2026, The Hague, Netherlands 300

Apps (#)

250 200 150 100 50

eb

W

Am

az

on

R

G oo Se gle ev rvic en es ue M Cat ic ro Fu so nc A tio mp ft na lit u lS d of e tw ar e Fa st ly M M eta ix Pa C lo nel ud Sm flar ar e tb e Ak ar am ai O th er

0

Figure 8: Top third-party entities present in apps.

to the relevant code that resulted in the call. To associate undisclosed data access to the originating party, we apply the attribution process described previously. Each mismatch between an API call and data label item is considered a separate violation. As shown in Figure 7, the majority of violations originates from first-party behaviors. This finding contrasts with prior findings for Android applications, where the majority of the violations were attributed to third-party code [36]. In more detail, for multiple data types (e.g., Audio Data, Precise Location, Browsing History) the majority of violations was attributed to the first-party. In contrast, identifiers such as User ID, Device ID, and Name are more evenly collected by both parties, with up to 40% of violations linked to external SDKs and libraries. We detect a high number of first-party Nutrition Label violations, in contrast to privacy manifests where third-party violations dominate. This discrepancy is driven from the broader availability of third-party manifests, which results in a higher share of violations originating from external SDKs. Notably, one-third of apps exhibits third-party Nutrition Label violations, a proportion comparable to those with third-party manifest violations. Overall, both first- and third-party origins contribute to privacy violations, although this distinction is less pronounced in the manifest analysis. Third-Party Entities. While detecting undeclared access at runtime establishes that apps collect sensitive data without disclosure, it does not determine whether data is directly exfiltrated beyond the application boundaries. To assess whether API access also leads to data leakage, we analyze the network traffic generated during the app’s execution and categorize the prevalence of third-party domains being contacted. Figure 8 illustrates the distribution of entities contacted by all apps across the dataset. Each domain was categorized using the TrackerDB [63] and Disconnect tracker lists [55], and then mapped to their parent service provider based on the eTLD+1. The most common services originate from Google, reflecting their major roles as SDK and service providers. Amazon Web Services is also prevalent, operating primarily as a hosting infrastructure. The “Other” category captures a long tail of third-party domains, each associated with a smaller number of apps. We note that these patterns mirror those measured on web and mobile platforms, where tracking/analytics/infrastructure is concentrated to a limited number of major providers [51].

Jyotirmay Chauhan, Kostas Solomos, Mir Masood Ali, and Jason Polakis

Data Exfiltration. We next assess whether the captures network communications, transmits sensitive user or device data. In total, 497 applications transmitted user and device information over the network. Among these, 204 applications transmitted identifiers explicitly protected by the Nutrition Labels, and 62 of those did not disclose the corresponding data types. The remaining apps transmitted coarser, fingerprint-related attributes, such as kernel or OS version, Mac model identifier, and screen resolution. Table 2 reports the breakdown of undisclosed data types collected, and the top domains receiving the data. Across all data types, the most commonly contacted entities were Google (googleapis.com, 1e100.net), Amazon (amazonaws.com, cloudfront.net), and Facebook (fbcdn.net, facebook.com). These entities primarily provide advertising, analytics, or infrastructure services, highlighting the privacy implications of undisclosed data transmission by desktop apps.

4.3

Extended Fingerprinting Analysis

In the final part of our study, we present a taxonomy of all device identifiers we encountered during our analysis. This analysis is independent of the current design of Nutrition Labels and instead, we consider all device identifier and related attributes transmitted offdevice. We analyze their prevalence in app network traffic and categorize them by the type of information they reveal, demonstrating how third parties can leverage them for augmenting device fingerprinting. The identifier list was generated via the system_profiler command on macOS, which provides a highly detailed technical overview of a device’s hardware capabilities. Table 3 lists the identifiers detected, representative values, and their prevalence across apps. Several device-specific identifiers (e.g., System Version and Kernel Version) are disclosed by default through Apple’s networking stack, as they are embedded in the user-agent string automatically generated by CFNetwork, the default networking library [12]. Interestingly, the version value increments with each operating system update (e.g., macOS 15.6, Darwin 24.5.0), allowing trackers to classify the devices by patch level. This leakage extends the fingerprinting surface beyond Apple’s declared Device ID category, introducing a persistent, fine-grained feature for tracking. Additional identifiers expose detailed device characteristics and configuration information. The Model Identifier directly encodes hardware specifications; for example, Mac16,12 denotes the 13-inch MacBook Air with an M4 chipset [13]. We detected this identifier in the network traffic of 222 apps (44%), representing a significant fraction of our dataset. Apps also transmitted screen resolutions attributes that are considered as high-entropy for fingerprinting within browsers [102]. While native resolution can also be inferred from the model identifier, the HiDPI value varies with user configuration, introducing a distinct fingerprinting modality that expands the range of device-specific attributes available to third parties. Furthermore, identifiers exposed through Apple’s Graphics API, Metal [2], also introduce an independent hardware feature, further enriching the fingerprinting surface. Finally, we detected a specific combination of identifiers (“Darwin 12.3.0” , “15.3.2”, “M4”, “<REDACTED_CITY>”) in 72 apps’ network traffic, directly revealing the device and execution environment. Summary. Our analysis highlights the various shortcomings in the current design of Apple Nutrition Labels. In its current state,

Exploring Privacy Leakage and Data Disclosure Violations in the MacOS Application Ecosystem

Table 2: Applications exfiltrating sensitive data in violation of Nutrition Label, and the corresponding third-party domains. Data Type

Apps

Name

44

Coarse Location User ID Device ID Email

124 10 16 7

Domains cloudfront.net, akamaitechnologies.com, fbcdn.net, amazonaws.com, 1e100.net googleapis.com, 1e100.net, amazonaws.com, facebook.com, braze.com cloudfront.net, amazonaws.com, 1e100.net google.com, unity3d.com, icandesignapp.com 1e100.net, amazonaws.com

Table 3: Access of fingerprintable device attributes. Device Attribute System Version Kernel Version Chipset Model Location Model Identifier Resolution(HiDPI) Email Display Type Name User Name Boot Volume Hardware UUID Metal Support Computer Name Bus Serial Number (system) Hardware Domain Name MAC Address IPv4 Addresses

Description macOS 15.3.2 Darwin 24.3.0 Apple M4 Redacted Mac16,12 1470 x 956 Retina Redacted Liquid Retina XDR Display Redacted Redacted Macintosh HD Redacted Metal 3 Redacted’s MacBook Pro Built-In Redacted AirPort 10.0.5.1 Redacted 10.0.5.14

Apps 362 408 241 145 222 145 24 147 59 59 78 21 54 53 18 11 21 3 6 2

the Nutrition Label framework is insufficient for both developers and end users. Developers must navigate the complex compliance system encompassing entitlements, privacy manifests, and Nutrition Labels. In addition, the lack of Nutrition Label verification during App submission also means that users encounter incomplete or incorrect labels, undermining their trust in the system. Furthermore, given the proliferation of device fingerprinting for user tracking and risk-based authentication, and the extent of deviceidentifier exfiltration detected by NutriScan, the absence of a dedicated fingerprinting category in Nutrition Labels is a significant oversight. While Apple has acknowledged the fingerprinting potential of certain system APIs[22] and requires developers to disclose why they are used, this disclosure is relegated to the privacy manifests which most end users will neither read nor encounter. A ground-up redesign of Nutrition Labels that focuses on simplifying Apple’s data collection nomenclature, and extending it to include device fingerprinting, will provide a more comprehensive and impactful privacy disclosure mechanism.

5

Mitigating Disclosure Discrepancies

A key takeaway from our measurement study and data analysis is that disclosures cannot rely on developer self-reporting, and effective mitigations require replacing this implicit-trust-based model

CCS ’26, November 15–19, 2026, The Hague, Netherlands

with centralized verification. NutriScan demonstrates that automated analysis can generate reliable and accurate disclosures by cross-referencing bundle components. These audits can be integrated directly into build and deployment pipelines. For instance, Nutrition Labels can be pre-populated from SDK manifests embedded in the app, reducing redundancy and minimizing omissions. Xcode already has the ability to combine all third-party manifest files into an app-wide manifest file. Yet, developers are currently required to manually fill out Nutrition Labels. Platform changes. At the platform level, enforcement must combine static and dynamic validation. The submission pipeline should incorporate automated cross-checks between Nutrition Labels, entitlements, and manifests, rejecting apps with inconsistent disclosures. Nutrition Labels can be partially auto-generated from bundle artifacts (e.g., SDK manifests) at build time, ensuring that developer-supplied disclosures cannot fall below a verified baseline. Xcode should partially autofill the Nutrition Label component, and interface with App Store Connect to ensure the presence of baseline disclosures during submission. Finally, runtime enforcement should be extended to detect undeclared access to protected APIs. These measures must be integrated by Apple across deployment and runtime mechanisms to replace the current fragmented model. Unified Disclosure and Verification. Apple uses a combination of property list declarations and user-enforced runtime permissions to regulate access to sensitive data, while other privacy-related declarations (e.g., nutrition labels) remain unverified. This fragmented approach creates opportunities for inconsistencies and omissions. We provide an example that illustrates the problematic nature of the current design: imagine a developer that wants to create an app that can record videos. The app would need to use multiple Native APIs in their code; AVCaptureSession begins an event during which the user takes a picture. Since Apple considers access to this functionality sensitive, the developer would need to request the user for a runtime permission to access the camera via a different object, AVCaptureDevice, whose property requestAccess, is used to trigger a system prompt that is displayed to the user. However, when macOS observes this API call, it looks for an entry in the Entitlements file, com.apple.security.device.camera, which is a static declaration from the developer that the app will access the camera. In the absence of this entitlement, the developer’s code ) will not prompt the user and hence will not receive device permissions. Additionally, if the developer wants to list their app on the App Store, they need to create a privacy manifest file, and include a key, NSPrivacyCollectedDataTypePhotosorVideos, along with details about how the data is used and handled by the app. While the manifest entry does not affect runtime enforcement, it is used by App Store reviewers to approve the app for listing. Finally, the developer must also declare the Photos & Videos type in the Nutrition Label, under the category User Content, to inform users that the app accesses their photos or videos. Listing 1 (Appendix E) provides an example snippet of Swift code a developer might use for this workflow. The developer in this example creates redundant declarations, each of which uses different terminology. Alternatively, Apple could consolidate these components into a single declaration that is used

CCS ’26, November 15–19, 2026, The Hague, Netherlands

for both enforcement and user disclosure. The developer could declare in a single file that the app accesses the camera to record videos, and this declaration would be used by the OS to enforce access restrictions, by App Store reviewers to approve the app for listing, and by users to understand the app’s data collection practices. Considering Xcode’s existing capabilities to populate and consolidate entitlements and privacy manifest files, we propose that a similar approach should consolidate all data access into a single declaration. We provide an example declaration in Appendix E for this specific example, illustrating our proposed unified approach. This strategy would streamline the disclosure process for developers by eliminating redundancy, minimizing accidental omissions, and enhancing the reliability of disclosures, while also facilitating a platform-level automated verification process.

6

Discussion and Limitations

While NutriScan extensively evaluates the runtime behavior of macOS apps, its analysis has the following limitations. NutriScan uses a custom UI-exercising tool to interact with apps, but these interactions are not comprehensive, i.e., we do not evaluate all possible app states or user inputs. As such, our system may miss certain privacy-invasive behaviors and disclosure violations. Moreover, our analysis depends on taxonomical and functional overlaps with Nutrition Labels which can only partially be addressed via Entitlements and Runtime Permissions. Due to the nature of our classification and the absence of platform documentation, a subset of APIs could not be reliably classified into specific label categories. Our results, therefore, offer a lower bound of data collection, which may be even more extensive than what our study demonstrates. Finally, NutriScan reports on observed data collection but cannot determine the purpose or use of the collected data, nor can it identify backend handling practices (e.g., anonymization). These are important for a complete assessment of app privacy, but can only be performed in collaboration with app and SDK developers.

7

Related Work

Here we discuss pertinent prior work, focusing mainly on research addressing privacy labels, and desktop platforms. Privacy Nutrition Labels. Kelley et al. [70] first proposed the idea of creating a nutrition label for apps similar to the mandated Food Nutrition labels governed by the FDA. A privacy nutrition label was designed as a simple and universal disclosure that would accurately indicate the app’s data collection practices. This would allow a user to understand the data they were sharing and dictate their decisions about using an app. The idea gained traction, which led Apple and subsequently Google to implement a version of this nutrition label calling them App Nutrition Labels [25] and Data Safety Labels [64], respectively. While initially introduced for iOS, Apple recently rolled out Nutrition Labels for macOS and made it mandatory for developers to include one for their desktop apps. Subsequently, several dimensions of Nutrition Labels have been studied, including usability from the end-user perspective [103], developer challenges [75], and large-scale analyses [76]. Closer to our work are studies focusing on compliance. Ali et al. [8] compared labels with privacy policies and found significant divergences across iOS apps. Kollnig et al. [72] demonstrated that

Jyotirmay Chauhan, Kostas Solomos, Mir Masood Ali, and Jason Polakis

iOS apps used fingerprinting-derived identifiers for tracking, found evidence of Apple engaging in tracking, and detected that discrepancies were widespread in less popular apps, a finding also verified by our research. Arkalakis et al. [36] conducted a dynamic analysis of Android apps to analyze their data collection practices. That study also correlated apps’ dynamic behavior, including API accesses and network traffic, with the apps’ Data Safety Section. Their research uncovered a high degree of non-compliance with the apps’ stated data disclosure policies. While that study follows a similar methodology (albeit in a vastly different software ecosystem), it focuses on apps’ dynamic behavior depending on users’ runtime consent. On the other hand, our research focuses on the unique aspects of the macOS ecosystem, including identifying system resources that are not sufficiently tracked through entitlements, TCC and Gatekeeper, yet can be leveraged by trackers for uniquely identifying users. Another relevant study [98] examined iOS apps’ compliance with their Nutrition Labels using dynamic analysis and network interception. Their dynamic analysis system, Lalaine, detected 67% of apps to be non-compliant compared to our 85%. Their findings are consistent with ours in identifying User ID, Device ID and Location data as the most frequent non-compliant categories. NutriScan analyzes additional app and system level components, including privacy manifests, entitlements, and fingerprintable identifiers, thus offering a more comprehensive assessment of privacy violations. Desktop Apps. Recent research on desktop apps has focused on the security properties of cross-platform apps. Carettoni developed a static analysis tool, Electronegativity, that identifies potential security vulnerabilities in Electron apps [44]. Xiao et al. [97] found concerning security practices adopted by 640 apps when evaluated with Electronegativity. They then developed a dynamic analysis tool to evaluate Electron apps and identify sensitive data flows that can be exploited to perform Remote Code Execution (RCE) attacks. Similarly, Ali et al. [9] proposed a dynamic analysis tool, Inspectron, that runs apps against an instrumented Electron framework and monitors their runtime behavior to identify potential security vulnerabilities. Jin et al. [67] developed a framework that uses a DOM-tree-based analysis to evaluate and identify unintended modifications in Electron apps. Yang and Yue [100] compared tracking practices between mobile and desktop environments; however, for the desktop component of their research, they studied websites that offer a desktop version of their webpage, they did not study dedicated desktop applications. Blochberger et al. [39] compared the deployment and configuration of sandboxing within macOS applications installed through Apple’s official store to that of applications retrieved from a third-party app store and found that 89% of apps distributed through the third-party app store did not use sandboxing, thereby exposing users to risk. Summary. To the best of our knowledge, no prior work has systematically investigated how tracking and fingerprinting techniques are deployed within desktop apps. This lack of attention is notable given the research on tracking in web and mobile ecosystems, leaving a gap in our understanding of privacy risks in desktop environments. By presenting the first empirical exploration of privacy-invasive practices in a desktop platform, our study directly addresses this gap and helps complete the broader picture

Exploring Privacy Leakage and Data Disclosure Violations in the MacOS Application Ecosystem

of online tracking across different platforms. In addition, we conduct the first systematic evaluation of macOS apps’ compliance with their reported Privacy Nutrition Labels. This dual contribution allows us to assess not only the presence of tracking and fingerprinting behaviors, but also the extent to which apps adhere to their self-disclosed data practices. Taken together, our findings provide a more comprehensive picture of the shortcomings and challenges associated with both data access control mechanisms and data practice disclosure frameworks in one of the most widely used desktop operating systems.

8

Conclusion

Users have become considerably more aware, and concerned, about online tracking and other forms of privacy loss, and a rich body of academic research has explored multiple dimensions of privacy loss within the web, mobile, and smart device ecosystems. However, despite the continuing widespread use of desktops, no prior research has explored how desktop apps can impact users’ privacy. To address that gap, we conducted the first, to our knowledge, systematic evaluation of data practices and violations by desktop apps. We focused on macOS, due to its general perception as a more secure and private OS compared to Windows, as well as its recent adoption of Privacy Nutrition Labels. To that end, we developed NutriScan, an analysis framework and pipeline that consolidates diverse data sources by statically analyzing app components and dynamically instrumenting and exercising app. Using our system we were able to detect privacy violations and disclosure discrepancies across a wide selection of popular apps. Our in-depth analysis of these violations, reveals that known tracking entities often surreptitiously exfiltrate unique user and device identifiers that can deanonymize concurrent private browsing sessions, and other sensitive data that can be used to significantly enrich user’s profiles. Our research calls for more streamlined nutrition-label creation mechanisms, and improved vetting processes within Apple’s App store, to mitigate the significant privacy risk posed by macOS apps.

Acknowledgments We would like to thank the anonymous reviewers and shepherd for their valuable feedback. This work was supported by the National Science Foundation under grants CNS-2211574 and CNS2143363. Any opinions, findings, conclusions, or recommendations expressed herein are those of the authors, and do not necessarily reflect those of the NSF.

Ethical Considerations We conducted this research with strict adherence to ethical guidelines, and upheld principles in accordance with the Menlo report. Purpose and Impact of Research. The primary goal of this work is to understand the data collection practices of desktop applications and their resulting implications for the privacy of end users. We show that desktop environments provide rich data collection capabilities, but offer few guidelines to assist app developers. Our findings can inform the design of more effective privacy controls and tools for desktop environments, as well as guide future research in this space.

CCS ’26, November 15–19, 2026, The Hague, Netherlands

Beneficence. At every step of this research project, we proactively evaluated our findings and its impact on all stakeholders involved, including Apple (especially, reviewers of apps on the App Store), app developers, developers of third-party SDKs, and importantly, end users. We highlight their interactions with various studied components in Table 4 in the Appendix. Below, we outline the specific considerations and impact on each stakeholder. Apple. We gathered our dataset of apps from the official Apple App Store. We fetched individual app bundles and associated metadata one at a time, ensuring that our requests did not overwhelm the App Store infrastructure. Our work demonstrates shortcomings in the App Store’s review process and highlights a need for more comprehensive verification of submissions. App Developers. All apps and associated metadata that we analyzed in this study are publicly available on the Apple App Store. Our research highlights that developers are held responsible for a large array of app components in their app, each of which have partially overlapping semantics and share functional similarities with each other. Our findings show that these components can result in inconsistent privacy practices, and can lead to developers including conflicting privacy declarations for end users to view on the App Store. Third-party SDK Developers. Our analysis highlights the privacy practices of apps, with all included SDKs, as a whole. We recognize that developers of third-party SDKs have limited control over how their SDKs are incorporated within apps, and that the SDKs’ data collection practices can vary based on features accessed by the app itself (i.e., corresponding Native API calls). We clarify in § 2 that the responsibility for accuracy of submissions lays with the app developers, and point out that SDK developers can ease the process by providing their own privacy manifest files. Our proposed system can help SDK developers understand the real-world use of their SDKs, and better support their clients (i.e., app developers) through enhanced documentation and support with communicating privacy practices. End Users. The privacy implications of our work primarily affect end users that download and use apps from the App Store. Our findings show that end users that rely on the Privacy Nutrition Labels on the App Store can be misinformed of an app’s actual behavior once downloaded. Our work aims to raise awareness about these issues and provide insights into how apps collect and use data, thereby empowering end users to make informed decisions about their privacy. Respect for persons. We note that our research does not directly involve human subjects and informed consent procedures are not applicable to our research. Our work does not cause any additional risk to end users, developers, or Apple itself. Our work informs users, researchers, and regulators thereby improving transparency and accountability. The study relies exclusively on empirical measurement of application behavior and analysis of publicly available disclosures, without interacting with end users or collecting personal data. While our results may reflect negatively on certain applications or platform practices, we believe that responsible disclosure of measurement-based evidence serves the public interest and aligns with established norms in security and privacy research. Overall, the expected benefits of increasing awareness and enabling better-informed decisions about privacy risks outweigh

CCS ’26, November 15–19, 2026, The Hague, Netherlands

any minimal potential downsides, justifying the ethical conduct of this research. Responsible Disclosure. Upon completion of our analysis, we provided Apple a detailed description of our findings, including a list of the apps with discrepancies in their data practice disclosures. We have received notification that our reported issues were reproduced and are currently being investigated.

Open Science To promote transparency and to facilitate future research, we have made research artifacts available on Github [47].

References [1] [n. d.]. DATAREPORTAL - Digital 2025: device trends for 2025. https://datare portal.com/reports/digital-2025-sub-section-device-trends [2] [n. d.]. Metal Overview. https://developer.apple.com/metal/ [3] 2024. Apple Platform Security. https://help.apple.com/pdf/security/en_US/ap ple-platform-security-guide.pdf [4] Letsgo Network Incorporated. 2011. LetsVPN MacOS Store. https://apps.apple .com/us/app/letsvpn/id1481327306?mt=12. [5] Gunes Acar, Marc Juarez, Nick Nikiforakis, Claudia Diaz, Seda Gürses, Frank Piessens, and Bart Preneel. 2013. FPDetective: dusting the web for fingerprinters. In Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security. 1129–1140. [6] alexey-lysiuk. 2021. macos-sdk. https://github.com/alexey- lysiuk/macossdk/tree/main/MacOSX10.15.sdk. [7] Muhammad Ali, Angelica Goetzen, Alan Mislove, Elissa M Redmiles, and Piotr Sapiezynski. 2023. Problematic advertising and its disparate exposure on Facebook. In 32nd USENIX Security Symposium (USENIX Security 23). 5665–5682. [8] Mir Masood Ali, David G. Balash, Monica Kodwani, Chris Kanich, and Adam J. Aviv. 2024. Honesty is the Best Policy: On the Accuracy of Apple Privacy Labels Compared to Apps’ Privacy Policies. In Proceedings on Privacy Enhancing Technologies Symposium, Vol. 2024. Bristol, UK, 142–166. doi:10.56553/popets2024-0111 [9] Mir Masood Ali, Mohammad Ghasemisharif, Chris Kanich, and Jason Polakis. 2024. Rise of Inspectron: Automated Black-box Auditing of Cross-platform Electron Apps. In 33rd USENIX Security Symposium (USENIX Security 24). 775– 792. [10] Gianluca Anselmi, Yash Vekaria, Alexander D’Souza, Patricia Callejo, Anna Maria Mandalari, and Zubair Shafiq. 2024. Watching TV with the secondparty: a first look at automatic content recognition tracking in smart TVs. In Proceedings of the 2024 ACM on Internet Measurement Conference. 622–634. [11] Appfigures. 2025. Top Ranked Mac App Store Apps. https://appfigures.com/t op-apps/mac-app-store/united-states/top-overall. [12] Apple. 2025. CFNetwork. https://developer.apple.com/documentation/cfnetw ork. [13] Apple. 2025. Identify your MacBook Pro model - Apple Support. https://supp ort.apple.com/en-us/108052. [14] Apple. 2025. UIKit. https://developer.apple.com/documentation/uikit. [15] Apple Developer. 2025. Disabling and Enabling System Integrity Protection. https://developer.apple.com/documentation/security/disabling-and-enablingsystem-integrity-protection. [16] Apple Developer. 2025. Third-party SDK Requirements - Support: Privacy Manifests. https://developer.apple.com/support/third-party-SDK-requirements. [17] Apple Developer Documentation. 2023. Required reason APIs. https://develo per.apple.com/documentation/bundleresources/privacy_manifest_files/descr ibing_use_of_required_reason_api. [18] Apple Developer Documentation. 2023. Sandbox Exceptions. https://develope r.apple.com/library/archive/documentation/Miscellaneous/Reference/Entitl ementKeyReference/Chapters/AppSandboxTemporaryExceptionEntitlements. html. [19] apple developer documentation. 2026. nsuserdefaults. https://developer.apple. com/documentation/foundation/userdefaults. [20] Apple Inc. [n. d.]. PrivacyPreferencesPolicyControl. https://developer.apple. com/documentation/devicemanagement/privacypreferencespolicycontrol. [21] Apple Inc. 2020. App Privacy Details on the App Store. https://developer.appl e.com/app-store/app-privacy-details. [22] Apple Inc. 2024. Describing use of required reason API. https://developer.apple. com/documentation/bundleresources/describing-use-of-required-reason-api. [23] Apple Inc. 2024. Privacy updates for App Store submissions. https://develope r.apple.com/news/?id=3d8a9yyh. [24] Apple Inc. 2025. Adding a Privacy Manifest to Your App or Third-Party SDK. https://developer.apple.com/documentation/bundleresources/privacy-

Jyotirmay Chauhan, Kostas Solomos, Mir Masood Ali, and Jason Polakis

manifest-files. [25] Apple Inc. 2025. App privacy details on the App Store. https://developer.appl e.com/app-store/app-privacy-details/. [26] Apple Inc. 2025. App Review Guidelines. https://developer.apple.com/appstore/review/guidelines/. [27] Apple Inc. 2025. App Sandbox. https://developer.apple.com/documentation/se curity/app-sandbox. [28] Apple Inc. 2025. App’s Sitemap. https://apps.apple.com/robots.txt. [29] Apple Inc. 2025. Bundle: A representation of the code and resources stored in a bundle directory on disk. https://developer.apple.com/documentation/foun dation/bundle. [30] Apple Inc. 2025. Entitlements. https://developer.apple.com/documentation/bu ndleresources/entitlements. [31] Apple Inc. 2025. Gatekeeper and runtime protection in macOS. https://suppor t.apple.com/guide/security/gatekeeper-and-runtime-protection-sec5599b66df /web. [32] Apple Inc. 2025. Information Property List. https://developer.apple.com/docu mentation/bundleresources/information-property-list. [33] Apple Inc. 2025. Xcode. https://developer.apple.com/xcode/. [34] Apple Inc. 2026. iTunes Search API. https://performance-partners.apple.com /search-api. [35] Apple WebKit Team. 2020. Tracking Prevention in WebKit. https://webkit.org /tracking-prevention/. [36] Ioannis Arkalakis, Michalis Diamantaris, Serafeim Moustakas, Sotiris Ioannidis, Jason Polakis, and Panagiotis Ilia. 2024. Abandon All Hope Ye Who Enter Here: A Dynamic, Longitudinal Investigation of Android’s Data Safety Section. In 33rd USENIX Security Symposium (USENIX Security 24). 5645–5662. [37] Muhammad Ahmad Bashir, Sajjad Arshad, William Robertson, and Christo Wilson. 2016. Tracing Information Flows Between Ad Exchanges Using Retargeted Ads. In 25th USENIX Security Symposium (USENIX Security 16). USENIX Association, Austin, TX, 481–496. https://www.usenix.org/conference/usenixsecu rity16/technical-sessions/presentation/bashir [38] Muhammad Ahmad Bashir and Christo Wilson. 2018. Diffusion of User Tracking Data in the Online Advertising Ecosystem. Proceedings on Privacy Enhancing Technologies (PoPETS) 2018, 4 (July 2018). [39] Maximilian Blochberger, Jakob Rieck, Christian Burkert, Tobias Mueller, and Hannes Federrath. 2019. State of the sandbox: Investigating macOS application security. In Proceedings of the 18th ACM Workshop on Privacy in the Electronic Society. 150–161. [40] Bram Bonné, Sai Teja Peddinti, Igor Bilogrevic, and Nina Taft. 2017. Exploring decision making with {Android’s} runtime permission dialogs using in-context surveys. In Thirteenth Symposium on Usable Privacy and Security (SOUPS 2017). 195–210. [41] Reinhardt A Botha, Steven M Furnell, and Nathan L Clarke. 2009. From desktop to mobile: Examining the security experience. Computers & Security 28, 3-4 (2009), 130–137. [42] Justin Brookman, Phoebe Rouge, Aaron Alva, and Christina Yeung. 2017. Crossdevice tracking: Measurement and disclosures. Proceedings on Privacy Enhancing Technologies (2017). [43] Bytedance Pte. Ltd. 2025. CapCut - video editor. https://apps.apple.com/us/ap p/capcut-video-editor/id1500855883. [44] Luca Carettoni. 2017. Electronegativity - A Study of Electron Security. Blackhat (July 2017). https://infocondb.org/con/black-hat/black-hat-usa-2017/electro negativity-a-study-of-electron-security [45] Claude Castelluccia, Mohamed-Ali Kaafar, and Minh-Dung Tran. 2012. Betrayed by your ads! Reconstructing user profiles from targeted ads. In International symposium on privacy enhancing technologies symposium. Springer, 1– 17. [46] Geoff Charles. 2024. What Is a Virtual Credit Card & How Do They Work? https://ramp.com/blog/virtual-credit-card-guide [47] Jyotirmay Chauhan. [n. d.]. NutriScan. https://github.com/jchauhn/NutriscanCCS-26. [48] Federal Trade Commission et al. 2017. Cross-Device Tracking: A Federal Trade Commission Staff Report (2017). (2017). [49] Aldo Cortesi, Maximilian Hils, and Thomas Kriechbaumer. 2025. mitmproxy an interactive HTTPS proxy. https://www.mitmproxy.org/. [50] Rachel Cummings, Gabriel Kaptchuk, and Elissa M Redmiles. 2021. ” i need a better description”: An investigation into user expectations for differential privacy. In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security. 3037–3052. [51] Savino Dambra, Iskander Sanchez-Rola, Leyla Bilge, and Davide Balzarotti. 2022. When Sally met trackers: Web tracking from the users’ perspective. In 31st USENIX Security Symposium (USENIX Security 22). 2189–2206. [52] Anupam Das, Nikita Borisov, and Matthew Caesar. 2016. Tracking Mobile Web Users Through Motion Sensors: Attacks and Defenses.. In NDSS. [53] Jessica Dawson. 2021. Microtargeting as information warfare. The Cyber Defense Review 6, 1 (2021), 63–80.

Exploring Privacy Leakage and Data Disclosure Violations in the MacOS Application Ecosystem

[54] Alban Diquet. 2025. SSL Kill Switch 2. https://github.com/nabla-c0d3/ssl-killswitch2. [55] Disconnect Tracker List. 2022. Canonical repository for the Disconnect services file. https://github.com/disconnectme/disconnect-tracking-protection/blob/ master/services.json. [56] Steven Englehardt, Jeffrey Han, and Arvind Narayanan. 2018. I never signed up for this! Privacy implications of email tracking. In Proceedings on Privacy Enhancing Technologies Symposium, Vol. 2018. Barcelona, Spain, 109–126. doi:10.1515/popets-2018-0006 [57] Equity and Human Rights Commission. 2021. Protected characteristics. https://www.equalityhumanrights.com/equality/equality-act-2010/protectedcharacteristics. [58] Exforsys. 2011. What is Monkey Testing – IT Training and Consulting – Exforsys. https://www.exforsys.com/tutorials/testing- types/monkeytesting.html [59] Ayman Farahat and Michael C. Bailey. 2012. How effective is targeted advertising?. In Proceedings of the 21st International Conference on World Wide Web (WWW ’12). [60] Firebase(Google). 2025. Firebase SDK for Apple App Development. https://gi thub.com/firebase/firebase-ios-sdk.git. [61] Frida. 2015. The Engineering behind Reverse Engineering. Open Source Developers’ Conference (OSDC) (Oct. 2015). https://frida.re/slides/osdc-2015-theengineering-behind-the-reverse-engineering.pdf [62] Frida Project. [n. d.]. Frida. Dynamic instrumentation toolkit for developers, reverse-engineers, and security researchers. https://github.com/frida/frida. [63] Ghostery. 2025. TrackerDB. https://github.com/ghostery/trackerdb. [64] Google LLC. 2022. Provide information for Google Play’s Data safety section. https://support.google.com/googleplay/android-developer/answer/10787469? hl=en. [65] Google LLC. 2023. Privacy Sandbox. https://privacysandbox.com/. [66] Umar Iqbal, Pouneh Nikkhah Bahrami, Rahmadi Trimananda, Hao Cui, Alexander Gamero-Garrido, Daniel J Dubois, David Choffnes, Athina Markopoulou, Franziska Roesner, and Zubair Shafiq. 2023. Tracking, profiling, and ad targeting in the Alexa echo smart speaker ecosystem. In Proceedings of the 2023 ACM on Internet Measurement Conference. 569–583. [67] Zihao Jin, Shuo Chen, Yang Chen, Haixin Duan, Jianjun Chen, and Jianping Wu. 2023. A Security Study about Electron Applications and a Programming Methodology to Tame DOM Functionalities. In NDSS. [68] Jonathan Levin Morpheus. 2025. OSX iOS Entitlement Database. https://newo sxbook.com/ent.php. [69] KEEPSOLID INC. 2025. VPN Unlimited. https://apps.apple.com/us/app/vpnunlimited-for-mac/id727593140?mt=12. [70] Patrick Gage Kelley, Joanna Bresee, Lorrie Faith Cranor, and Robert W. Reeder. 2009. A “Nutrition Label” for Privacy. In Proceedings of the 5th Symposium on Usable Privacy and Security (SOUPS ’09). Association for Computing Machinery, New York, NY, USA, 1–12. doi:10.1145/1572532.1572538 [71] Konrad Kollnig, Pierre Dewitte, Max Van Kleek, Ge Wang, Daniel Omeiza, Helena Webb, and Nigel Shadbolt. 2021. A fait accompli? an empirical study into the absence of consent to {Third-Party} tracking in android apps. In Seventeenth Symposium on Usable Privacy and Security (SOUPS 2021). 181–196. [72] Konrad Kollnig, Anastasia Shuba, Max Van Kleek, Reuben Binns, and Nigel Shadbolt. 2022. Goodbye Tracking? Impact of IOS App Tracking Transparency and Privacy Labels. In 2022 ACM Conference on Fairness, Accountability, and Transparency (Seoul, Republic of Korea) (FAccT ’22). Association for Computing Machinery, New York, NY, USA, 508–520. doi:10.1145/3531146.3533116 [73] Pierre Laperdrix, Nataliia Bielova, Benoit Baudry, and Gildas Avoine. 2020. Browser fingerprinting: A survey. ACM Transactions on the Web (TWEB) 14, 2 (2020), 1–33. [74] Letsgo Network Incorporated. 2011. LetsVPN Privacy Policy. https://letsvpn. world/privacy. [75] Tianshi Li, Kayla Reiman, Yuvraj Agarwal, Lorrie Faith Cranor, and Jason I. Hong. 2022. Understanding Challenges for Developers to Create Accurate Privacy Nutrition Labels. In Proceedings of the 2022 CHI Conference on Human Factors in Computing Systems (New Orleans, LA, USA) (CHI ’22). Association for Computing Machinery, New York, NY, USA, Article 588, 24 pages. doi:10.1145/3491102.3502012 [76] Yucheng Li, Deyuan Chen, Tianshi Li, Yuvraj Agarwal, Lorrie Faith Cranor, and Jason I. Hong. 2022. Understanding iOS Privacy Nutrition Labels: An Exploratory Large-Scale Analysis of App Store Data. In Extended Abstracts of the 2022 CHI Conference on Human Factors in Computing Systems (New Orleans, LA, USA) (CHI EA ’22). Association for Computing Machinery, New York, NY, USA, Article 356, 7 pages. doi:10.1145/3491101.3519739 [77] Thomas Linden, Rishabh Khandelwal, Hamza Harkous, and Kassem Fawaz. [n. d.]. The Privacy Policy Landscape After the GDPR. Proceedings on Privacy Enhancing Technologies 2020 ([n. d.]). [78] Juan Lopez, Leonardo Babun, Hidayet Aksu, and A. Selcuk Uluagac. 2017. A Survey on Function and System Call Hooking Approaches. Journal of Hardware and Systems Security 1, 2 (June 2017), 114–136. doi:10.1007/s41635-017-0013-2

CCS ’26, November 15–19, 2026, The Hague, Netherlands

[79] Francesco Marcantoni, Michalis Diamantaris, Sotiris Ioannidis, and Jason Polakis. 2019. A Large-scale Study on the Risks of the HTML5 WebAPI for Mobile Sensor-based Attacks. In 30th International World Wide Web Conference, WWW ’19. ACM. [80] Mozilla Corporation. 2019. Enhanced Tracking Protection in Firefox. https://su pport.mozilla.org/en-US/kb/enhanced-tracking-protection-firefox-desktop. [81] Evan Neufeld. 2017. Cross-device and cross-channel identity measurement issues and guidelines: How advertisers can maximize the impact of an identitybased brand campaign. Journal of Advertising Research 57, 1 (2017), 109–118. [82] ChangSeok Oh, Chris Kanich, Damon McCoy, and Paul Pearce. 2022. Cartology: Intercepting Targeted Advertising via Ad Network Identity Entanglement. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security (Los Angeles, CA, USA) (CCS ’22). Association for Computing Machinery, New York, NY, USA, 2401–2414. doi:10.1145/3548606. 3560641 [83] Angelisa C. Plane, Elissa M. Redmiles, Michelle L. Mazurek, and Michael Carl Tschantz. 2017. Exploring User Perceptions of Discrimination in Online Targeted Advertising. In 26th USENIX Security Symposium (USENIX Security 17). USENIX Association, Vancouver, BC, 935–951. https://www.usenix.org/confe rence/usenixsecurity17/technical-sessions/presentation/plane [84] Jingjing Ren, Martina Lindorfer, Daniel J Dubois, Ashwin Rao, David Choffnes, and Narseo Vallina-Rodriguez. 2018. A longitudinal study of pii leaks across android app versions. In Network and Distributed System Security Symposium (NDSS), Vol. 10. [85] Jingjing Ren, Ashwin Rao, Martina Lindorfer, Arnaud Legout, and David Choffnes. 2016. ReCon: Revealing and Controlling PII Leaks in Mobile Network Traffic. In Proceedings of the 14th Annual International Conference on Mobile Systems, Applications, and Services (MobiSys ’16). [86] Franziska Roesner, Tadayoshi Kohno, Alexander Moshchuk, Bryan Parno, Helen J Wang, and Crispin Cowan. 2012. User-driven access control: Rethinking permission granting in modern operating systems. In 2012 IEEE Symposium on Security and Privacy. IEEE, 224–238. [87] Asuman Senol, Gunes Acar, Mathias Humbert, and Frederik Zuiderveen Borgesius. 2022. Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission. In 31st USENIX Security Symposium (USENIX Security 22). USENIX Association, Boston, MA, 1813–1830. https://www.usenix.org/confe rence/usenixsecurity22/presentation/senol [88] Till Speicher, Muhammad Ali, Giridhari Venkatadri, Filipe Nunes Ribeiro, George Arvanitakis, Fabrício Benevenuto, Krishna P. Gummadi, Patrick Loiseau, and Alan Mislove. 2018. Potential for Discrimination in Online Targeted Advertising. In Proceedings of the 1st Conference on Fairness, Accountability and Transparency, Vol. 81. [89] Chad Spensky, Jeffrey Stewart, Arkady Yerukhimovich, Richard Shay, Ari Trachtenberg, Rick Housley, and Robert K Cunningham. 2016. Sok: Privacy on mobile devices–it’s complicated. Proceedings on privacy enhancing technologies (2016). [90] Mohammad Tahaei, Ruba Abu-Salma, and Awais Rashid. 2023. Stuck in the permissions with you: Developer & end-user perspectives on app permissions & their privacy ramifications. In Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems. 1–24. [91] Cem Topcuoglu, Andrea Martinez, Abbas Acar, Selcuk Uluagac, and Engin Kirda. 2024. MacOS versus Microsoft Windows: A Study on the Cybersecurity and Privacy User Perception of Two Popular Operating Systems. In Symposium on Usable Security and Privacy (USEC) 2024. [92] Imdad Ullah, Roksana Boreli, and Salil S Kanhere. 2023. Privacy in targeted advertising on mobile devices: a survey. International Journal of Information Security 22, 3 (2023), 647–678. [93] w0lfschild. 2025. macOS headers. https://github.com/w0lfschild/macOS_head ers. [94] Zhaohui Wang, Bo Luo, and Fengjun Li. 2025. PrivacyGuard: Exploring Hidden Cross-App Privacy Leakage Threats In IoT Apps. Proceedings on Privacy Enhancing Technologies (2025). [95] Primal Wijesekera, Arjun Baokar, Lynn Tsai, Joel Reardon, Serge Egelman, David Wagner, and Konstantin Beznosov. 2017. The feasibility of dynamically granted permissions: Aligning mobile privacy with user preferences. In 2017 IEEE Symposium on Security and Privacy (SP). IEEE, 1077–1093. [96] Yuxi Wu, Panya Gupta, Miranda Wei, Yasemin Acar, Sascha Fahl, and Blase Ur. [n. d.]. Your Secrets Are Safe: How Browsers’ Explanations Impact Misconceptions About Private Browsing Mode. In Proceedings of the 2018 World Wide Web Conference (WWW ’18). 217–226. [97] Feng Xiao, Zheng Yang, Joey Allen, Guangliang Yang, Grant Williams, and Wenke Lee. 2022. Understanding and mitigating remote code execution vulnerabilities in cross-platform ecosystem. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security. 2975–2988. [98] Yue Xiao, Zhengyi Li, Yue Qin, Xiaolong Bai, Jiale Guan, Xiaojing Liao, and Luyi Xing. 2023. Lalaine: measuring and characterizing non-compliance of apple privacy labels. In Proceedings of the 32nd USENIX Conference on Security Symposium (Anaheim, CA, USA) (SEC ’23). USENIX Association, USA, Article

CCS ’26, November 15–19, 2026, The Hague, Netherlands

Figure 9: The Privacy Nutrition Label of CapCut.

62, 18 pages. [99] Jun Yan, Ning Liu, Gang Wang, Wen Zhang, Yun Jiang, and Zheng Chen. 2009. How much can behavioral targeting help online advertising?. In Proceedings of the 18th International Conference on World Wide Web (WWW ’09). [100] Zhiju Yang and Chuan Yue. 2020. A comparative measurement study of web tracking on mobile and desktop environments. Proceedings on Privacy Enhancing Technologies 2020, 2 (2020). [101] Eric Zeng, Tadayoshi Kohno, and Franziska Roesner. 2021. What makes a “bad” ad? user perceptions of problematic online advertising. In Proceedings of the 2021 CHI Conference on Human Factors in Computing Systems. 1–24. [102] Desheng Zhang, Jianhui Zhang, Youjun Bu, Bo Chen, Chongxin Sun, and Tianyu Wang. 2022. A Survey of Browser Fingerprint Research and Application. Wireless Communications and Mobile Computing 2022, 1 (2022), 3363335. arXiv:https://onlinelibrary.wiley.com/doi/pdf/10.1155/2022/3363335 doi:10.1155/2022/3363335 [103] Shikun Zhang, Yuanyuan Feng, Yaxing Yao, Lorrie Faith Cranor, and Norman Sadeh. 2022. How usable are ios app privacy labels? Proceedings on Privacy Enhancing Technologies (2022). [104] Sebastian Zimmeck, Jie S Li, Hyungtae Kim, Steven M Bellovin, and Tony Jebara. 2017. A privacy analysis of cross-device tracking. In 26th USENIX Security Symposium (USENIX Security 17). 1391–1408. [105] Shoshana Zuboff. 2023. The age of surveillance capitalism. In Social theory re-wired. Routledge, 203–213.

A

Privacy Nutrition Example

Figure 9 illustrates the Nutrition Label of a popular video app, CapCut [43]. The app declares the collection of device identifiers, user content, and interaction data, and classifies them as “Linked to You” or “Used to Track you”. While this separation increases disclosure granularity, users face challenges interpreting such information without familiarity with Apple’s labeling system, highlighting a broader limitation of this labelling approach [103]. However, while a simpler label listing only the collected data items may be easier to interpret, it might not accurately capture applications’ data collection practices [76].

B

macOS Privacy Mechanisms

Table 4 provides a taxonomy of macOS privacy components and disclosure mechanisms, evaluated across four dimensions: (i) overlap in taxonomy and functionality, (ii) data collection and handling practices, (iii) tracking and fingerprinting surfaces, and (iv) access and interaction by different entities (e.g., developers, reviewers, users). Privacy Labels are user-facing disclosures that report data collection categories and stated purposes. They rely on the same taxonomy as manifests and permissions, since developers generate them based on bundle-defined components. During the app’s lifecycle, the App Store verifies their presence through internal checks, without however, verifying their accuracy. As our analysis demonstrated, labels remain developer-declared rather than system-enforced or

Jyotirmay Chauhan, Kostas Solomos, Mir Masood Ali, and Jason Polakis

validated. Even if they demonstrate the intended practices, they provide no information about fingerprinting vectors or runtime behavior. Privacy Manifests are developer-supplied metadata files embedded in macOS app bundles and SDKs. They adopt identical datatype taxonomy as Nutrition Label and require structured declarations of collected data, stated purposes, and externally accessed tracking domains (e.g., NSPrivacyTrackingDomains). During app’s submission, Apple’s review pipeline processes manifests to generate the corresponding Nutrition Labels. However, manifests are solely developer-declarative, since they capture developer-stated practices. Similar to Nutrition Labels they do not specify the application’s tracking purposes or runtime functionality. Entitlements are the primary access control mechanism on macOS. They are embedded in the app bundle’s .entitlements file and define the system services and resources an application can access (e.g., push notifications). Entitlements are enforced by macOS at runtime, controlling the app’s effective permissions during execution. Permissions are enforced by macOS at runtime when an application requests access to protected resources such as the camera, microphone, or location. Permissions provide the interface through which users must grant or deny access to sensitive components. They are enforced at runtime and directly tied to application behavior once access is requested. By design, they do not provide information about how resources are used once access has been granted. Native API Calls are used by applications to deliver their functionality. They are widely accessible by both the application developer, and also the third-party SDKs. The APIs invoked during runtime not only reflect the data uses declared by the application, and also expose additional invocations that may be exploited for tracking or other invasive practices. This runtime information can only be obtained through dynamic analysis, which requires additional effort for execution monitoring and attribution. Overall, each mechanism contributes a complementary view of application behavior, but none provides an accurate representation of privacy practices. Moreover, there is no centralized validation mechanism (e.g., the Mac App Store) to enforce consistency. Our analysis demonstrates the fundamental limitations of the current validation process, while our system performed end-to-end analysis to detect inconsistencies in disclosure practices.

C NutriScan: Nutrition Label to Entitlement mapping Table 5 maps Nutrition Label categories to the entitlements and APIs that provide access to the corresponding data. We note that this information does not appear in Apple’s documentation and was constructed from official references during our analysis. As shown in §4, individual label categories correspond to diverse entitlements and APIs. For example, user id is reported under Apple account and Game Center entitlements and is accessible through host and device APIs. Multiple categories, including advertising data, performance data, and crash data, have no associated entitlement and can only be accessed through APIs. This mapping demonstrates that the Nutrition Label taxonomy is technically grounded

Exploring Privacy Leakage and Data Disclosure Violations in the MacOS Application Ecosystem

CCS ’26, November 15–19, 2026, The Hague, Netherlands

Table 4: Overview of privacy-relevant components studied in this work with insights into their relationships and attributes. Overlap (| / F = complete/partial Taxonomy Overlap, Ū / x = complete/partial Functionality Overlap) shows the relationship between components. Data Collection & Handling (î = Data Linking or Anonymization, Ď = Purpose, ͜ = Data Types or Categories) indicates the app’s data collection practices that can be gathered from analyzing the component. User Tracking & Fingerprinting (Á = Apple’s pre-defined Sensitive APIs, ́ = Extended Fingerprinting) indicates the app’s privacy-invasive practices that can be gathered from analyzing the component. Access & Interaction (̲ = Creation, ¬ = Verification, ¿ = Observation) shows how each entity accesses the corresponding component. Overlap

Privacy Label ȷ Privacy Manifest ɚ Entitlements Ù Permissions Native API Calls

|Ū |Ū x x x

ȷ

ɚ

Ù

ĸ

Component

Fx |Ū x x x

x |Ū Fx FŪ

x Fx |Ū FŪ

Fx Fx Fx |Ū

Data Collection & Handling

User Tracking & Fingerprinting

App Developer

îĎ͜ îĎ͜ ͜ ͜ ͜

Á Á Á Á́

̲ ̲ ̲ ̲ ̲

ĸ

var i s A u t h o r i z e d : B o o l { g e t async { l e t s t a t u s = AVCaptureDevice . a u t h o r i z a t i o n S t a t u s ( f o r : . video ) // Determine if the user previously authorized camera access . var i s A u t h o r i z e d = s t a t u s == . a u t h o r i z e d // If the system hasn 't determined the user 's authorization status , // explicitly prompt them for approval . i f s t a t u s == . notDetermined { i s A u t h o r i z e d = a w a i t AVCaptureDevice . r e q u e s t A c c e s s ( f o r : . video ) } return i s A u t h o r i z e d } } func s e t U p C a p t u r e S e s s i o n ( ) async { // Check for camera authorization . g u a r d a w a i t i s A u t h o r i z e d e l s e { return } // Create the capture session . l e t c a p t u r e S e s s i o n = AVCaptureSession ( ) // Find the default video device . g u a r d l e t v i d e o D e v i c e = AVCaptureDevice . d e f a u l t ( f o r : . video ) e l s e { return } do { // Wrap the video device in a capture device input . l e t v i d e o I n p u t = t r y AVCaptureDeviceInput ( d e v i c e : videoDevice ) // If the input can be added , add it to the session . i f c a p t u r e S e s s i o n . canAddInput ( v i d e o I n p u t ) { captureSession . addInput ( videoInput ) } } ca t c h { // Configuration failed . Handle error . }}

Listing 1: Example Swift code to capture a video on macOS.

in concrete entitlements and APIs. However, the absence of corresponding documentation and guidelines leads to developer confusion, resulting in the Nutrition Label violations and discrepancies, as our analysis demonstrated.

D

Entitlement oriented Discrepancies

Table 6 expands Table 1 (§4.1) with the entitlement-to-Nutrition Label mapping and the Nutrition Label data types they correspond

Access & Interaction SDK App Store Developer Reviewer ̲

¿ ¬ ¬

End User ¿

¬ ̲

" Camera " : { " Data Type " : { " V i d e o " : t r u e } , " P u r p o s e " : { " App F u n c t i o n a l i t y " : t r u e } , " Handling " : { " Anonymization " : f a l s e } , " User Permission " : { " Required " : true , " Status " : . notdetermined } , " API A c c e s s " : [ " AVCaptureSession " , " AVCaptureDevice " , " AVCaptureVideoDataOutput " ] }

Listing 2: Example unified declaration for camera access.

to. As our analysis highlights, multiple entitlements map to different and diverse Nutrition Label categories. For example, appleaccount.fullaccess maps to user and device identifiers, contact details, communications, and payment information. The largest discrepancies occur for Identifiers, Name and Contact Information, Photos or Videos, Health, and Financial Information, which are frequently omitted even though the entitlements indicate access. Overall, this result demonstrates that the impact of discrepancies is greater when entitlements map to multiple Nutrition Label categories are omited.

E

Unified Privacy Declaration

In Listing 1 we include a snippet of example Swift code that a developer may use to capture enable a user to capture video using the device camera. The code checks for camera access authorization, requests access if not determined, and sets up a capture session if authorized, before creating a recording session. Listing 2 demonstrates how how multiple fragmented disclosures, that are currently spread across entitlements, privacy manifests, and user-facing labels, can be merged into a single, unified declaration. A developer, may specify the data type collected (video), it’s purpose (functionality), the handling practice (no anonymization) and other metadata about how APIs are invoked. This unified structure allows the same declaration to serve simultaneously for OS-level enforcement, App Store review, and user transparency.

CCS ’26, November 15–19, 2026, The Hague, Netherlands

Jyotirmay Chauhan, Kostas Solomos, Mir Masood Ali, and Jason Polakis

Table 5: Nutrition Label to Entitlement and API mapping Label

Entitlement

user id

accounts.appleaccount.fullaccess, developer.game-center, gethostname, hostinfo, NSUserName, NSHomeDirectory, NSFileManager, developer.ubiquity-kvstore-identifier, developer.upi-device- NSHost, IOBluetoothDevice, NSAppleScript, NSTask, UIDevice validation

email address

accounts.appleaccount.fullaccess, developer.mail-client, mail

ABCopyArrayOfAllPeople, ABGetSharedAddressBook, ABAddressBook, CNContactSaveRequest, CNContactStore, NSAppleScript, CNContactFetchRequest

phone number

accounts.appleaccount.fullaccess, private.contactsui

ABCopyArrayOfAllPeople, ABGetSharedAddressBook, ABAddressBook, CNContactSaveRequest, CNContactStore, EKEventStore, NSAppleScript, CNContactFetchRequest

accounts.appleaccount.fullaccess, private.contactsui, security.personal-information.addressbook, security.temporary-exception.files.home-relative-path.readonly

ABCopyArrayOfAllPeople, NSHomeDirectory, NSHost,

name

API

ABGetSharedAddressBook,

NSUserName,

ABAddressBook, CNContactSaveRequest, CNContactStore, EKEventStore, NSAppleScript, CNContactFetchRequest physical address

accounts.appleaccount.fullaccess, private.contactsui, security.personal-information.addressbook

other user content

developer.contacts.notes, developer.ubiquity-container- LSSharedFileListCopySnapshot, EKEventStore, NSAppleScript identifiers, developer.ubiquity-kvstore-identifier, developer.user-management, security.files.downloads.readonly, security.files.downloads.read-write, security.files.userselected.read-only, security.files.user-selected.read-write, security.personal-information.calendars

browsing history

developer.web-browser

device id

accounts.appleaccount.fullaccess, developer.device- AudioDeviceID, DCDevice, AVCaptureDevice, CWInterface, NSAppleScript, information.user-assigned-device-name, security.temporary- NSTask, UIDevice exception.files.home-relative-path.read-only

precise location

developer.location.push, information.location

security.personal- CLLocationManager, LocationManagerDelegate, NSAppleScript

coarse location

developer.location.push, oper.networking.networkextension, information.location

devel- CLLocationManager, LocationManagerDelegate, NSUserDefaults, NSTimesecurity.personal- Zone, NSAppleScript

payment info

accounts.appleaccount.fullaccess, developer.in-app-payments

LSSharedFileListCopySnapshot, NSAppleScript

developer.financekit,

credit info emails or text messages

ABCopyArrayOfAllPeople, ABGetSharedAddressBook, ABAddressBook, CNContactSaveRequest, CNContactStore, EKEventStore, NSAppleScript, PKPaymentRequest, CNContactFetchRequest

PKPaymentRecurringRequest, PKPayment, SKMutablePayment, NSAppleScript, PKPaymentRequest

accounts.appleaccount.fullaccess

PKPaymentRecurringRequest, PKPayment, SKMutablePayment, NSAppleScript, PKPaymentRequest

accounts.appleaccount.fullaccess, developer.mail-client, mail

MEMessage, MSConversation, MEMessageState, NSAppleScript

performance data

MXCellularConditionMetric, MXCPUMetrics, MXGPUMetrics, NSAppleScript, MXAppLaunchDiagnostic, MXAppExitMetric, MXNetworkTransferMetric, MXCPUExceptionDiagnostic, MXDiskIOMetric, MXMemoryMetric, MXDisplayMetric

advertising data

ASIdentifierManager, NSAppleScript, SKAdNetwork

photos or videos

security.assets.pictures.read-only, security.assets.pictures.read- AVCaptureSession, write, security.device.camera, security.personal- FetchResult information.photos-library

NSAppleScript,

PHFetchResultChangeDetails,

PH-

audio data

security.device.audio-input, security.device.microphone

AVCaptureSession, FetchResult

NSAppleScript,

PHFetchResultChangeDetails,

PH-

purchase history

developer.in-app-payments

NSAppleScript

product interaction

NSAppleScript

crash data

NSAppleScript, MXAppLaunchDiagnostic, MXAppExitMetric, MXCPUExceptionDiagnostic, MXDiskIOMetric, MXMemoryMetric, MXDisplayMetric

customer support other financial info

NSAppleScript developer.financekit

gameplay content sensitive info

NSAppleScript NSAppleScript

developer.healthkit.access, developer.healthkit

NSAppleScript

Exploring Privacy Leakage and Data Disclosure Violations in the MacOS Application Ecosystem

CCS ’26, November 15–19, 2026, The Hague, Netherlands

Table 6: Distribution of apps with discrepancies between declared entitlements and corresponding Nutrition Label data types. Entitlement

# TotalApp (%)

# TopApp (%)

# Rand.App (%)

Label Data Type

files.user-selected.read-only personal-information.location personal-information.addressbook files.downloads.read-write personal-information.photos-library files.downloads.read-only files.user-selected.read-write device.microphone assets.pictures.read-write personal-information.calendars device.audio-input device.camera assets.pictures.read-only temporary-exception.files.homerelative-path.read-only

95% 93.6% 93.8% 92.3% 90.8% 88.8% 90.7% 89.4% 87.1% 86.6% 86.1% 84.5% 80.9% 68.7%

com.apple.security 94.1% 93.8% 93.9% 93.8% 90% 66.6% 87.7% 88.2% 89.4% 84.7% 87.6% 84.5% 75% 61.5%

95.7% 93.4% 92.8% 89.6% 92.1% 100% 94.5% 90.4% 83.3% 92.3% 84.5% 84.4% 100% 100%

Other User Content Precise Location, Coarse Location Name, Physical Address Other User Content Photos or Videos Other User Content Other User Content Audio Data Photos or Videos Other User Content Audio Data Photos or Videos Photos or Videos Device ID, Name

healthkit healthkit.access ubiquity-kvstore-identifier networking.networkextension ubiquity-container-identifiers in-app-payments game-center financekit

100% 100% 93.6% 90.3% 90.7% 66.6% 65% 50%

com.apple.developer 100% 100% 90.5% 89.4% 87.1% 50% 66.6% 50%

100% 100% 100% 91.6% 97.3% 100% 64% N.A.

Health, Sensitive Info Health, Sensitive Info Other User Content Coarse Location Other User Content Payment Info, Purchase History User ID Payment Info, Other Financial Info

mail

100%

com.apple 100%

100%

accounts.appleaccount.fullaccess

100%

N.A.

100%

Email Address, Emails or Text Messages User ID, Device ID, Phone Number, Name, Physical Address, Emails or Text Messages, Payment Info, Credit Info, Health, Fitness

Related documents

• AVP-Inspect: Coordinated Cyber-Physical Testing for Privacy Analysis of COTS Apple Vision Pro Applications#667909
• Developers: Beware of Ad Libraries that Betray Your Users’ Location Privacy#427001
• Security and Privacy Analysis of Mobile Health Applications: The Alarming State of Practice#964604
• Beyond Native Success: Auditing Deployment-Interface Exposure of CLIP Backdoors#282724
• CIPL: A Channel-Aware Framework for Recoverable Privacy Leakage in LLM Agents#1036077