Google, Meta ‘break’ Apple’s device fingerprinting rules

Last week, Apple began requiring iOS developers justify the use of a specific set of APIs that could be used for device fingerprinting. Yet the iGiant doesn’t appear to be making much effort to ensure that Google, Meta, and Spotify comply with the rules, it’s claimed.

Device fingerprinting involves collecting information about various device settings and components, then combining those into a single identifier that’s likely to be unique and thus useful for targeting people with ads and other stuff tailored to their individual interests and circumstances.

There are other forms of fingerprinting involving browser settings, the HTML Canvas element, WebGL, fonts, and so on, some of which have legitimate commercial applications, such as bot detection. But digital fingerprinting can also be used to violate privacy and track people online.

We found out that apps such as Google Chrome, Instagram, Spotify, and Threads don’t adhere to their declared reasons

While Apple allows user tracking if permission has been granted, it mostly forbids device-level fingerprinting on iOS, at least in theory. It made that policy official in a recent blog post.

As such the iBiz now requires app developers to supply among other things reasons for using any of its designated “required reason APIs” that can be used for device fingerprinting.

Crucially, data collected from these interfaces, which could be used for fingerprinting, must stay on the user’s device to maximize privacy.

The iPhone maker explains as much in its developer documentation. “Some APIs that your app uses to deliver its core functionality — in code you write or included in a third-party SDK — have the potential of being misused to access device signals to try to identify the device or user, also known as fingerprinting,” the Apple’s developer website states. “Regardless of whether a user gives your app permission to track, fingerprinting is not allowed.”

Examples of these fingerprint-friendly APIs include: File timestamp APIs, System boot time APIs, Disk space APIs, Active keyboard APIs, and User defaults APIs.

As of May 1, 2024, apps that fail to include reasons for using these APIs in their privacy manifest file won’t be accepted in the iOS App Store. Previously, Apple just sent non-compliant developers an email warning.

According to developers Talal Haj Bakry and Tommy Mysk, several major app makers are simply ignoring Apple’s requirements, and using tracker-happy APIs without sticking to the rules. Big Tech players like Google, Meta, and Spotify – the duo claim – are providing reasons for this API usage, collecting that data, and then not abiding by the requirement to keep that information on the device.

In other words, Google, Meta, and Spotify are all collecting at least some info from these APIs and then sending that data off to base against Apple’s rules, we’re told.

“To prevent misuse of these APIs, Apple will reject apps that don’t describe their use of the APIs in their privacy manifest file,” the pair explain in an advisory. “However, we found out that apps such as Google Chrome, Instagram, Spotify, and Threads don’t adhere to their declared reasons.”

The Register asked Google, Meta, and Spotify whether they are in fact using these “required reason APIs” for iOS device fingerprinting and beaming that data off to backend servers, and we’ve not heard back from the last two. A Google spokesperson confirmed it is looking into the report, but didn’t immediately have a response.

“It’s hard to tell if the apps are using the information for fingerprinting or not,” said Mysk in a message to The Register. “But Apple already classified a set of APIs that can potentially be used for fingerprinting. Apps accessing such APIs must declare the reasons why they need such access.”

Apple has published a list of valid reasons for using certain APIs that reveal information useful for fingerprinting. For example, iOS provides an API called systemUptime that can be queried to provide the time elapsed since the device was last restarted.

Developers who want to use this API can select from several allowed reasons, one which must be declared in a manifest file. Google for example has chosen 35F9.1, with italics added by us for emphasis:

Although Apple’s rule plainly states that uptime data cannot be sent off-device, Google Chrome appears to be doing just that, based on network data analysis from Bakry and Mysk. The rule does allow for an exception, but one that doesn’t apply to Chrome.

“No, this exception is about using the system uptime on-device locally to order events for example,” Mysk told The Register, explaining that Google has the option to transmit relative time intervals between two events but not the absolute device uptime number.

Mysk argues that Apple’s “required reason APIs,” like its Privacy Nutrition Labels, amount to privacy theater because there appears to be no enforcement.

“Just like the Privacy Nutrition Labels, developers are free to enter what they please,” said Mysk.

“Apple doesn’t seem to review if the description is accurate or not. While the nutrition labels are visible to the users, the required reason API isn’t. So, it is not clear how that is going to prevent fingerprinting and enhance user privacy if Apple doesn’t check the reasons developers submit.”

Cupertino did not respond to a request for comment. ®