Apple cracks down on apps using fingerprinting to track users

Apple's App Store has already been rejecting apps that collect user data to circumvent privacy measures, but soon developers will be required to justify their use of certain features.

With its iOS 14 introduction of App Tracking Transparency, Apple improved privacy for all users, and made life harder for advertisers. Some marketing companies switched instead to more complex ways of identifying and tracking users through the use of device fingerprinting.

In a new update to Apple's developer documentation, though, the company says it is going further. Where a developer wants to use an Apple API that could potentially contribute to fingerprinting, they will have to justify using it.

"From Fall 2023 you'll receive an email from Apple if you upload an app to App Store Connect that uses required reason API without describing the reason in its privacy manifest file," says Apple. "From Spring 2024, apps that don't describe their use of required reason API in their privacy manifest file won't be accepted by App Store Connect."

Apple uses the term "required reason API" to distinguish APIs that developers have to justify using, but it also notes that it can change the list as needed.

At present, there are around 30 required reason APIs, and they are applicable across all of Apple's platforms. They cover issues to do with accessing the keyboard, in calculating free disk space left, and how long the user's device has been running.

While there are exceptions within even these APIs, Apple's documentation repeatedly says that "Information accessed for this reason, or any derived information, may not be sent off-device."

8 Comments

bwilllius 3 Years · 3 comments

About 1 year ago

The linked documentation describes super awful API calls to creation date and modification date of a file. Also getting free space is now a sin. All calls are harmless.

BiCC 1 Year · 59 comments

bwilllius said:

The linked documentation describes super awful API calls to creation date and modification date of a file. Also getting free space is now a sin. All calls are harmless.

The MacOS kernal is a Sandbox. Getting access to free space is going Blockchain style. I would just like to add - if a kernal is a Sandbox you are 100 percent correct, the API calls are harmless. Why is Apple not giving you access to memory is mindboggling. Through JavaScript you can do a lot, and Apple admits it for URL. I think the management at Apple are spacing out!! It's out reaching. Good on you b.

auxio 19 Years · 2766 comments

I'm a developer too, and I understand the frustration. But turn your ire on those who feel the need to use their technical ability for scams rather than creating technology which is actually useful to people (and thus worth more than just advertising revenue).

It's really a sad day when the predominant business model for app developers is: create a free app which will capture people's attention and then milk them for all the data they're worth while using it. And of course, being scammers who don't understand the meaning of the word "ethics" and feel it's their right to do whatever they please to others for profit, as soon as Apple tries to limit what data they can get, they start doing "clever" things like this (using uptime, free space, etc. to create a unique fingerprint).

For myself, I'll be happy to explain to Apple why I use certain APIs if it means less scammers and more genuinely useful apps in the world. Good riddance to a business model which is moving humanity backwards, not forwards.

BiCC said:

bwilllius said:

The linked documentation describes super awful API calls to creation date and modification date of a file. Also getting free space is now a sin. All calls are harmless.

The MacOS kernal is a Sandbox. Getting access to free space is going Blockchain style. I would just like to add - if a kernal is a Sandbox you are 100 percent correct, the API calls are harmless. Why is Apple not giving you access to memory is mindboggling. Through JavaScript you can do a lot, and Apple admits it for URL. I think the management at Apple are spacing out!! It's out reaching. Good on you b.

Honestly have no idea what you're talking about. Let's define these words:

Kernel - The core of the operating system which manages system resources (CPU time, memory, access to devices, etc) for things which need to use them. Applications typically don't know/care about what happens at this level, and almost never directly interact with it.

Sandbox - A contained environment in which applications run. Applications get their own reserved storage, memory, etc and can't access the resources allocated to other applications (or the operating system). This is typically done at a higher level in the tech stack than the kernel, which has no knowledge of what applications even are. The kernel only knows how to manage access to low level hardware/resources for whatever is using them on the system (could be a device driver, could be a system daemon, could be an application, doesn't matter).

So calling the kernel a sandbox is meaningless. They're two completely separate concepts.

And applications always have access to memory/storage to do whatever they need to. What Apple is doing is limiting is apps which ask "how much memory/storage is left on the entire system?". The vast majority of apps don't need to care about how much is left, only that they have access to what need. The kernel is the only thing which needs to know how to manage memory based on how much is left on the system.

And then you throw in the term JavaScript, an interpreted programming language typically contained within a web browser environment. So the web browser controls what it has access to. Which is typically far less than what a native/non-web application has access to because the web browser can only give it access to things which are common across every single platform it runs on (from tiny embedded Linux systems to Mac Pros). The lowest common denominator of all those systems.

"Apple admits it for URL" - what does that even mean? A URL is an address for a resource on the internet (web page, image, etc). Sure, it's been hijacked as a means for web apps to send data (URL parameters), which are a classic source of buffer overflow security issues, but URLs have nothing to do with how much an app can do on the system.