Tag: Privacy

Since May 2024, the inclusion of an iOS Privacy Manifest has been a requirement for app submissions with newly added third-party SDKs. We analyzed first results about data collection practices, compliance issues with Apple’s guidelines, and privacy risks posed by SDK providers.

Apple mandates that all app submissions with specific newly added third-party SDKs have to include a comprehensive iOS Privacy Manifest. This manifest outlines the data collection and usage practices of apps, providing users with transparency and empowering them to make informed decisions about their digital privacy. As outlined in our previous blog post, Appicaptor correlates the privacy manifest contents with additional privacy findings through static analysis.

In our evaluation, we analyzed the iOS Privacy Manifests definitions of our app sample set, that consists of the most popular 2,000 free iOS apps available on the German Apple App Store in June 2024.

Apple mandates that apps with newly added third-party software development kits (SDK) of one of the 86 listed third-party SDKs have to include a iOS Privacy Manifest (see Apple Developer Support). Our analysis of the app sample set revealed the presence of all 86 SDKs in at least one app. We evaluated whether apps integrating these SDKs adhered to the privacy manifest requirement: Our findings indicate that only 47 out of the 86 SDKs were associated with at least one app that defined a privacy manifest. Conversely, the remaining 39 SDKs were utilized at least within one app within the sample set, but no app employing these SDKs defined a privacy manifest. This discrepancy may stem from the following factors: either the SDK developers may have not provided a privacy manifest template for their SDKs, or the app developers have not incorporated SDK versions that include privacy manifest template or explicitly deleted the manifest entry, or the app update does not include a newly added third-party SDK from the list. So our analysis can only investigate the Privacy Manifest declarations of about half of the libraries that Apple has selected. However, these first results already provide interesting insights in the data analytics industry.

What data is requested in real apps and why?

As first evaluation on the manifest content, we evaluated the data types declared within the iOS Privacy Manifests of our app sample set. Our analysis revealed that 50% of the apps declare in the manifest that they collect data types such as OtherDiagnosticData, CrashData, and DeviceID. Especially the data type DeviceID is privacy-sensitive as it provides the possibility to correlate actions of users across the sandbox boundaries of individual apps.

The full list of collected data types and the number of apps in which such data is collected according to the privacy manifest is given in the following graph. It can be seen, that a wide range of data types are defined in the app set, including very sensitive data types as Health (Health and medical data), PhysicalAddress, PreciseLocation and SensitiveInfo (racial or ethnic data, sexual orientation, pregnancy or childbirth information, disability, religious or philosophical beliefs, trade union membership, political opinion, genetic information, or biometric data).

Although Apple clearly specifies how data type classes should be defined in the iOS Privacy Manifest, we found 205 apps within our app sample set that included malformed or self-defined data types in iOS Privacy Manifests. Consequently, these do not align with Apple’s specified requirements and the discrepancy highlights issues in the implementation and adherence to Apple’s guidelines.

Following the evaluation of data types, we proceeded to assess the given purposes. The next graph presents the distribution of purposes defined in the iOS Privacy Manifests per app. Our analysis indicates that collecting data is declared for the purposes of AppFunctionality or Analytics in over 60% of the apps of the sample set. Consistent with our findings in the data type evaluation, we observed that a substantial number of apps (235 apps) which included purpose definitions deviate from Apple’s expected values. These are summarizes in the category Malformed / Self-defined Purpose in the chart below.

Do the declared data type and their reasoning align?

Further analysis was conducted to determine which data types are collected for which specific purpose and in how many apps of the app sample set this occurs. For this evaluation, we analyzed the iOS Privacy Manifest definitions of the 2,000 apps in our sample set, focusing on tuples of data types and associated purposes. The following graphic illustrates which data types are accessed for which purposes. The size of the circles corresponds to the number of apps in which that specific data type-purpose tuple was defined in the iOS Privacy Manifest. It is interesting to see, that collecting certain sensitive data types such as SensitiveInfo, PhysicalAddress, PreciseLocation and Health are declared for purposes besides AppFunctionality and almost all data types are used also for the purpose of Analytics, which could have an effect on user’s privacy.

Are there component providers that stand out in terms of data type and usage?

Data types and purposes are defined for specific components in the iOS Privacy Manifest. For that reason, our next focus was to investigate if specific purposes to collected data types are specific to certain component providers. Therefore, the following analysis examines the purposes for collected data types grouped for each component provider within the iOS Privacy Manifest. The following graph highlights the relationship between purposes and the SDK provider. To do so, we associated the providers to their SDKs and extracted the 20 most frequently contained SDK providers in the Privacy Manifests within the evaluated app set. We analyzed in how many apps each purpose is defined for these top 20 providers within the app set. In the diagram it can be seen that certain providers, such as Firebase, concentrate on a few specific and targeted purposes. In contrast, others, like Adjust, request data for a wide array of purposes. As the purposes relate to the activities of the SDK providers, this can be seen as summary on the functionality aspects provided by the SDK components and their providers.

Similar to the evaluation of the specific purposes related to component providers, we expanded the view to cluster the information according to the data types accessed. To do so, we again took the 20 most frequently mentioned SDK component providers in the Privacy Manifests within the evaluated app set and counted how many apps declare a data type and purpose tuple for these top 20 component providers. In the following graph the size of the circles in the graph corresponds to the number of apps in which each specific data type-purpose tuple was declared in the iOS Privacy Manifest. Like the former evaluation, this graph shows, that certain component providers (like Firebase) focus on certain data type and purpose tuples, whereas other component providers define various data type and purpose tuples (e.g, Google and Facebook).

The data type definition may additionally contain boolean processing flags, that should specify external usage of the data. The processing flag linked specifies that the data type is linked to the user’s identity, whereas tracked specifies that the data type is used to track users. Our final evaluation of the Privacy Manifest data of the app sample set focus on the aspect whether certain data providers specify data types with these processing flags or not.

Data types flagged with tracked can be shared with a data broker. Therefore, if the processing flag tracked or linked/tracked is set, this may threaten the user’s privacy significantly. Therefore, we examined what processing flags are set by different component providers for requested data types. We took the ten most frequently mentioned SDK component providers in the Privacy Manifests within the evaluated app set and analyzed how many apps declare a data type, processing type and purpose tuple for these top ten component providers. The size of the circles in the following graph corresponds to the number of apps in which each specific data type-processing flag-purpose tuple was defined in the iOS Privacy Manifest. The graph groups the data types in relation to the requested purpose in circle groups. The circle group’s label states which processing flags are set to true: If the circle group is labeled with linked, then only the data type is linked to the user’s identity. If circle group is labeled with linked/tracked, then the data type is linked to the user’s identity, and it is used to track users. Elements of a circle group that has no label are neither linked nor tracked.

A significant difference in the processing flag usage can be seen when comparing the results for Google and Facebook. Google defines the processing flag linked or no processing flag for most data types and purposes. In contrast, Facebook sets the processing flag with the most possible extent linked/tracked for most data types and purposes.

Conclusion

The analysis of iOS Privacy Manifests for the 2,000 most popular free iOS apps on the German Apple App Store in June 2024 reveals several insights about data collection practices and compliance with Apple’s guidelines.

About half of the Privacy Manifests in apps have declared to collect data type OtherDiagnosticData, CrashData or DeviceID, with various sensitive data types also being collected. However, the presence of apps with malformed or self-defined data types indicates inconsistencies in adhering to Apple’s guidelines. Additionally, the observed entries for data collection purposes were found to violate Apple’s specification. This undermines the effectiveness of the privacy manifest and hopefully will be addressed with checks by Apple during the app review process.

However, even in this preliminary analysis with a lot of data missing for SDKs, the benefit of the Privacy Manifests can be seen. This way, it is possible to inspect the relations between collected data types, purposes and components, showing that in some apps sensitive data types are collected for purposes not related to the app’s functionality.

The examination of specific data type-purpose tuples and their association with component providers revealed that certain SDK providers, focus on targeted purposes, while others, request data for a broader range of purposes. Notably, the processing flags for data types, particularly those flagged as tracked, pose significant privacy risks. The contrast between providers, which primarily uses the linked flag, and those which extensively use the linked/tracked flag, may underscore the varying levels of privacy impact across different SDK providers.

Device fingerprinting is a technique that got popular at the end of the 90s by websites, to identify and track users. Apps have in contrast to websites often access to a much wider property range usable for fingerprinting. The unique device identification via fingerprinting across sandbox borders of multiple apps is a relevant privacy issue as it increase the possibilities for tracking users, even without requiring permissions. Many smartphone users are unaware of such practices and possibilities because such activities happen unnoticeably in the background.

Just like each person has an individual fingerprint, electronic devices are also uniquely identifiable. Through manufacturing tolerances, different hardware configurations, software properties and individual software configurability such devices become uniquely identifiable. Depending on the number and the variance of properties used, more or less unique fingerprints can be generated. Typically, several hard- and software device properties are combined through a hashing algorithm to an ideally unique bit sequence.

Motivations for app developers to include tracking libraries are: advertisement, bot detection, account takeover, spam, fraud detection and secure environment detection for payments. Mobile operating systems such as Android and iOS are aware of the user’s transparency through fingerprinting and take steps to empower the user to regain privacy whilst trying to maintain legitimate tracking objectives. The advertisement ID was introduced especially to target device tracking with a resettable ID provided by iOS. It allows advertisers to personalize ads and at the same time give the user options to reset it or hide it for individual apps. Also, Privacy Labels are added to the app store to better explain the app’s data usage to the user. Permissions and Privacy Labels should shed light on the usage of tracking, and it’s purpose during app install and usage. Apple AppStore’s licence agreement also states clear rules on data and identifier usage. However, as shown by Deng et al., many apps exist in the AppStore infringing such rules, working their way around permissions and being dishonest with their Privacy Labels. One increasing way to bypass such restrictions is to use fingerprinting techniques not requiring user consent.

Tracking Possibilities with Fingerprinting

The fingerprint generated by each app containing the same fingerprinting SDK are ideally the same on the same device. The user becomes very transparent by correlating the fingerprint with other data provided during app usage. As an example, one could think of a scenario, pictured in the following figure, where a shopping app, a search engine app and a navigation app all contain the same fingerprinting SDK. All user input of each app like recent purchases, search terms and the device location could be accumulated in the cloud under the same fingerprint. The data collection of each app alone is already a privacy risk to the user, but the combination of different app data makes users fully transparent. Such data is extremely valuable for example for advertisement companies to personally tailor advertisements for individual users.

Fingerprinting SDKs and Commonly used Properties

To gain insight into the current state of iOS fingerprinting and the latest techniques being used, we identified real iOS fingerprinting SDKs through systematic internet research and conducted manual static and dynamic analysis. The respective SDKs source-code was manually analysed with Ghidra and if possible, the SDK was tested in a minimal app construct. During the manual analysis we judged the SDK as fingerprinter or non-fingerprinter based on the observed behaviour and used properties. This leaves 13 SDKs that we classify as fingerprinters and further analyse in more detail. The SDKs are listed in the following table. We found that all 13 SDKs use the native iOS API to collect device characteristics. Through dynamic analysis of custom-built test apps, we have found that the collection of features shows up through temporal spikes. Most SDKs send the collected device characteristics to a server for further processing, except for OpenIDFA, DFID and DFIDSwift, which are non-commercial products. Additional passive fingerprinting may be performed on the server side. The SDKs that do not include server communication generate a hash on the device and return it. Nevertheless, we argue that fingerprinting is generally only useful when the fingerprint leaves the device. Therefore, it can be assumed that in these cases the caller of the fingerprinting framework handles the network communication. It is obvious from the following table that fingerprinting SDKs share some
collected properties, while other properties are exclusively queried by some SDKs. Very commonly used properties are: device model, identifier for vendor (similar to advertisement ID), device name, storage space properties, battery level and different locale identifiers. Other properties like device fonts, commonly used in web based fingerprinters, is rather seldom used. We suppose, due to the low entropy of this value on iOS devices. In conclusion, one can say that fingerprinters usually use multiple properties and don’t rely on a unique identifier provided through the advertisement ID in iOS.

Fingerprinting Access Pattern

We were able to observe access to common iOS APIs gathered in the previous step. Frida hooks were written to log access to respective APIs in a dynamic app analysis on a jailbroken iPhone X (iOS 14.4.2). In the next step, we analysed several top apps from the app store to see if fingerprinting can be observed based on API access pattern during execution.

Non-fingerprinting App

Firstly, let’s have a look at an example of an app without fingerprinting in the following figure. One can see that different properties were used during the app execution, some less, some more frequently. The accesses to the observed properties came from different caller modules (packages or libraries) from inside the app. Also, the properties were accessed throughout the whole runtime. Access to properties such as timezone and locale are typically required to properly display and run the app and totally legitimate.

Fingerprinting App

Now, let’s look at an app which we judge as fingerprinting in the following figure. One can see that from second 15 to 17, many properties are accessed in a very short timespan. Furthermore, the accesses come from the same caller module called ForterSDK, which is a known fingerprinting SDK. We observed such behaviour for all fingerprinting SDKs: Many properties are collected by the same caller module in a short time frame.

Fingerprinting Detection

As a proof of concept, we developed a fingerprinting detector to detect fingerprinting on the traces of a dynamic app analysis. The analyser is implemented as a sliding window of a certain width. The window of four seconds width slides over the event timeline and counts the number of accesses to known fingerprinting APIs per caller module. Access numbers above a certain threshold are then justified as fingerprinting. In a first test, we were able to correctly detect fingerprinting in 85% of the cases just by analysing access pattern. As further refinements, machine learning could improve accuracy as well as the inclusion of known fingerprinting SDK properties through a static analysis. Further insights on our used detection mechanism can be read in our extensive paper at ACM, published at the EICC conference 2023.

Conclusion

Fingerprinting as of today is used in many apps. Smartphone users are mostly unaware of the existence and the privacy issues related with such. This research lays the fundamentals to identify device fingerprinting in iOS apps. Future work will be to come up with remediation ideas to balance the privacy interests of smartphone users and fingerprinters.

Acknowledgements

This research work was supported by the National Research Center for Applied Cybersecurity ATHENE. ATHENE is funded jointly by the German Federal Ministry of Education and Research and the Hessian Ministry of Higher Education, Research and the Arts.

Note: Fingerprinting detection is currently work in progress and not (yet) part of the Appicaptor service.

With Apple’s release of iOS 14.5 at the end of April, iOS app developers are required to request permission in order to track their users beyond the app’s border. While there are already complaints about the low opt-in rate published by the app analytics company Flurry, which are updated weekly, we were curious to see how the overall adoption rate for app implementations would look like.

Developers need to provide a tracking description in the apps info.plist file – together with localized versions in file InfoPlist.strings of language’s project directory – called NSUserTrackingUsageDescription that informs the user why an app is requesting permission to use data for tracking the user or the device. However, in 57.3 % of the current German Top 2000 iOS apps no tracking description was provided by the developers although the app contains tracking code. On devices with iOS 14.5 or later this causes iOS to deny the request for access to the identifier for advertisers (IDFA). So the opt-in rate of users could be higher if those 57.3% of the developers would have provided a description, so that the user is at least presented with a decision dialog.

Property	%
No tracking description included but tracking code detected	57.3 %
Tracking description included and tracking code detected	33.5 %
No tracking description included and no tracking code detected	9.0 %
Tracking description included but no tracking code detected	0.2 %

Another effect we observed is a missing individualization and usefullness of the description. The table below lists the Top 10 used descriptions in the Top 2000 Apps, with 77 Apps just repeating the example text provided by Apple. Other just include placeholder text, such as “YOUR TEXT”, “NSUserTrackingUsageDescription”, “none” or even “-“.

Description	#
This identifier will be used to deliver personalized ads to you.	77
Your data will be used to deliver personalized ads to you.	9
Dadurch können wir Ihnen relevantere Werbung anzeigen, ohne deren Anzahl zu erhöhen.	7
Dies wird verwendet, um den Dienst zu identifizieren, der dich weitergeleitet hat, um die ein individuelles Erlebnis zu bieten.	6
Diese Kennung wird verwendet, um Ihnen personalisierte Anzeigen zu liefern.	6
Ihre Daten werden verwendet, um Ihnen personalisierte Werbung zu zeigen.	6
Your data will be used to deliver personalized ads.	5
Datenerhebung zur Verbesserung der App und für Werbezwecke zulassen	4
Deine Aktivitäten werden verwendet, um Dein Nutzererlebnis und Werbung zu personalisieren.	4
Mithilfe dieser ID können wir Dir für Dich ausgewählte Werbung anzeigen.	4

This leaves us with the impression, that creating a fitting description is currently only deamed important for 1/3 of the developers. Obviously the motivation depends on the benefits the developers gain from providing a tracking description.

There are many business cases which rely on or have a benefit from cross-app user tracking. The players of these business cases (e.g., ad providers and app developers who generate ad revenue) have an interest to achieve high opt-in rates. Fitting or at least reasonable descriptions for the permission dialogue will be the key for broad acceptance rates. The current evaluation shows that (1) only a minority of apps have at least a description included and (2) that they are very unspecific.

But there are use cases which currently integrate cross-app user tracking, however it does not have a beneficial effect for the using party. For example, this is the case when an app developer integrates a runtime diagnostic library. As he is only interested in the telematic data of his app, cross-app tracking would not be his interest and for that reason he may not include the description for the permission dialogue. In this case Apple’s initiative would help to reduce user tracking from companies that provide a runtime diagnostic services with a business model of selling retrieved analytics data sets to third parties or similar use cases.