dsgvo Archives - Appicaptor Blog

Apple designed the “Required Reason” API to enhance user privacy and trust. It helps ensure that app developers clearly communicate the reasons for requesting access to personal data or certain device capabilities. The guideline is now active for almost a year, and we’ve observed that this approach seems to generally work. But in practice, we observe some developers sneaking around these restrictions without Apple acknowledging this fact.

A smartphone with a shield symbol on the screen is shown beside a red apple with a bite taken out of it, symbolizing incomplete privacy.

As we approach the first anniversary of Apple’s Required Reasons API, we feel it’s time to recap it’s privacy gains in practice.

For developers, the Required Reasons API acts as a gatekeeper into the app store. It requires them to provide clear justifications for using certain APIs that access sensitive user data or system capabilities. The users can then inspect and evaluate the provided reason during app install. The principle behind this API is to promote transparency and user control over personal data. A significant contribution is the seamless integration of third-party library required reasons into the main app. This has ensured that the privacy measures extend beyond the core app, covering all the integrated elements.

Diving into the Details: Boot Time Example

To illustrate this, let’s take the example of boot time. The boot time of a device in microseconds is unique and can easily be used for device identification. Thus, such data requires sufficient protection to hinder device fingerprinting and therewith protecting the user’s privacy. Apple has identified two boot time related APIs: systemUptime and mach_absolute_time(). These require developers to provide specified reasons for their use. Apps or libraries accessing these methods must provide a reason in the app’s/library’s PrivacyInfo.xcprivacy file. This XML-file contains among other things a key specifying a resource linked with a reason for accessing this resource. Apple provides different short identifiers which specify a usage purpose as shown here:

<key>NSPrivacyAccessedAPICategorySystemBootTime</key>
<string>35F9.1</string>

In this example, the short identifier specifies the following reason, documented by Apple:

“Declare this reason to access the system boot time in order to measure the amount of time that has elapsed between events that occurred within the app or to perform calculations to enable timers. Information accessed for this reason, or any derived information, may not be sent off-device. There is an exception for information about the amount of time that has elapsed between events that occurred within the app, which may be sent off-device.”

A Year of Practice: The Good…

To evaluate these advancements in practice, we have collected the most popular third-party libraries for iOS apps. Next, we searched for libraries, known for device fingerprinting activities. The Required Reason API typically impacts such libraries the most, since they heavily rely on this data. In practice, the top three libraries leveraging device fingerprinting techniques make up more than 80% market share. Thus, analysing the top three libraries already provides broad coverage. We found that the top three libraries in fact use APIs from the “Required Reasons API” list, but provide a proper reason declaration. This means, that whenever a respective API is used, an appropriate cause in the PrivacyInfo.xcprivacy is provided. Thus, developers are adhering to the rules, and/or Apple is effectively enforcing these rules in the App Store.

…and the Bad

However, we have observed instances in some used libraries where developers have found ways around these obligations. These libraries use other methods for querying boot time, such as sysctl and sysctlbyname.

In iOS, sysctl and sysctlbyname are system calls enabling access to kernel parameters at runtime. They allow developers to query essential information about the system, such as CPU and memory statistics or the boot time. The sysctlbyname call offers a more user-friendly access method by using string identifiers instead of integers. Thus, an alternative way to query the boot time with this function would be:

sysctlbyname("kern.boottime", &bootTime, &size, nil, 0)

Additionally enforcing these APIs would require evaluating the arguments during the static analysis in Apple’s app publishing process. Evaluating the arguments during a static code analysis can sometimes be complicated if the argument isn’t a constant. Advanced techniques like symbolic execution or data dependency analysis might be necessary, features already applied in Appicaptor.

We have already contacted Apple on May 2nd, 2024 and informed them about missing items in their Required Reason API. However, they did not respond up until this day. We think that Apple is well aware of these APIs but doesn’t want to confirm this due to political reasons.

The Road Ahead

In conclusion, we see that Apple strides in the right direction, but there are still loopholes that need to be addressed. We look forward to seeing Apple continue to enhance its privacy measures, closing remaining gaps. Meanwhile, we continue to monitor Apple’s Required Reason APIs usage with Appicaptor and check for violations.

Device Fingerprinting

Device fingerprinting is a technique used to uniquely identify devices and therewith typically also users. Mobile apps make use of different device properties such for example device name, software version and others. They combine such values mostly with a hashing function to a unique identifier. Use cases for device fingerprinting are app usage statistics, fraud detection and mostly targeted advertisement.

When employees install apps with device fingerprinting on their mobile corporate devices, it can lead to the loss of sensitive business data for companies. Attackers can acquire the collected data and potentially identify the devices of company management, spy on trade secrets, and ascertain customer contacts. In practice, the Cambridge Analytica case shows how sufficient data from various sources can be used to analyze users and manipulate them through targeted advertising, thereby influencing even election results.

Identified Device Fingerprinting Activity for the Top 1.000 Android Apps (source)

Our analysis results show that more than 60% of the top 1,000 apps on Google Play employ device fingerprinting techniques. This allows a unique device identification even across app borders.

We extracted 30,000 domains from the most popular 2,000 iOS and Android apps. Afterwards, we filtered out domain names for the most prevalent device fingerprinters covering 90% market share. We were able to prevent device fingerprinting in 40% of the cases by using publicly available domain blocklists. These lists are specialized on tracking and advertisement domains and can be easily applied to for example a firewall. Another 40% would easily be blockable by updating the blocklist: Some fingerprinters use random subdomains for their communication in the form of https://8726481.iFingerprinter.org giving many possibilities to be blocked.

We also proposed an approach to randomize return values of popular properties used for device fingerprinting. Our results prove that this technique dramatically reduces the uniqueness of the device fingerprint. Nevertheless, respective APIs remain accurate enough for their intended use cases. The hope is that our proposed techniques are included in future Android and iOS releases.

In-App DSGVO Consent Banners

Many of the previously mentioned device fingerprinting properties would typically require user consent as stated by the DSGVO. According to recent court decisions and EU regulations, rejecting must be just as easy as accepting consent banners. However, many companies don’t obey such regulations. Those who obey mostly apply dark pattern to push the user into accepting all tracking.

Example DSGVO Consent Banner with the option to reject all tracking on first instance.

We are currently working on detecting if apps provide a reject option on first instance, without having to click through several submenus. In our attempt, we are employing artificial intelligence to analyse such consent banners for reject options on first instance. The results yield a success rate of 82%. Some apps try hard to remain within legal boundaries but make it hard for users to reject data usage. Can you find the first level reject option in the following consent banner? – Yes there is an option.

Example DSGVO Consent Banner that uses dark patterns to hide reject tracking option.

We have collected the most interesting consent banners and bundled them into a game. With the app “Reject all cookies” you need to overcome several consent banners and keep your data private. Having rejected all “cookies” in the app you can win real cookies at our it-sa 2024 booth (6-314).

Permission piggybacking in Android Apps

Traditionally, Android apps comprise a main application and several supporting libraries. These libraries often inherit permissions from the main app, granting them unnecessary access beyond their core functions. This leads to permission piggybacking, where libraries exploit inherited permissions to gather data without requesting them directly. Advertisement and tracking libraries particularly leverage this tactic to collect extensive user data.

We have developed an analysis tool to detect third-party app libraries only probing for already granted permissions, without ever requesting permissions themselves.

Analysing the top 1,000 apps on Google Play reveals that 50% of the libraries exhibit this permission probing behaviour. Presumably, these libraries then adapt their behaviour according to the granted permissions of the main app. Accordingly, they collect more or less data, as available. Most of the identified libraries exhibiting such behaviour are well-known advertising and tracking libraries. This fact underlines the urge for a finer granular permission system to separate main app and third-party libraries.

Tag: dsgvo

Apple’s Required Reason API: Aftermath after one year in practice