Adobe-Runtime-Support icon indicating copy to clipboard operation
Adobe-Runtime-Support copied to clipboard

Published 20 hours ago • verified publisher icon airsdk

Apple privacy manifests

Open Mintonist opened this issue 11 months ago • 14 comments

I have submitted my app successfully but I have recieved email from Apple:

Although submission for App Store review was successful, you may want to correct the following issues in your next submission for App Store review. Once you've corrected the issues, upload a new binary to App Store Connect.

ITMS-91053: Missing API declaration - Your app’s code in the “Game” file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategorySystemBootTime. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app’s privacy manifest to provide approved reasons for these APIs used by your app’s code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api.

ITMS-91053: Missing API declaration - Your app’s code in the “Game” file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryFileTimestamp. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app’s privacy manifest to provide approved reasons for these APIs used by your app’s code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api.

ITMS-91053: Missing API declaration - Your app’s code in the “Game” file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryDiskSpace. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app’s privacy manifest to provide approved reasons for these APIs used by your app’s code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api.

ITMS-91053: Missing API declaration - Your app’s code in the “Game” file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryUserDefaults. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app’s privacy manifest to provide approved reasons for these APIs used by your app’s code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api.

Apple Developer Relations

Mintonist avatar Mar 14 '24 18:03 Mintonist

Would definitely be interested to hear which pre-defined values we should use in the manifest! And wondering if any of these are from ANEs and we'd have to get information from the ANE developer, or if these are all central to the AIR SDK itself and we'd need to find out from Harman the values to use. I'll be preparing an IPA to upload next week, so I can share then if I'm seeing the same items or anything different.

FliplineStudios avatar Mar 15 '24 22:03 FliplineStudios

The NSPrivacyAccessedAPICategoryUserDefaults will be required by any ANE using User Defaults, including our Application ANE. The others all look file system related so likely something the AIR SDK is accessing. (We'll have an update for this shortly, including docs and airpackage update).

If you are interesting in information on the values to use for each have a look here: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api?language=objc

marchbold avatar Mar 18 '24 04:03 marchbold

Same issue while uploaded to AppStore. Is there way to add the privacy information to app while publishing through Adobe Animation?

yuyuanhua avatar Mar 19 '24 03:03 yuyuanhua

I believe you just have to create a file named PrivacyInfo.xcprivacy in the root of your application and include something like following:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>NSPrivacyTrackingDomains</key>
	<array>
		<string>app-measurement.com</string>
	</array>
	<key>NSPrivacyTracking</key>
	<true/>
	<key>NSPrivacyAccessedAPITypes</key>
	<array>
		<dict>
			<key>NSPrivacyAccessedAPIType</key>
			<string>NSPrivacyAccessedAPICategoryUserDefaults</string>
			<key>NSPrivacyAccessedAPITypeReasons</key>
			<array>
				<string>CA92.1</string>
				<string>DDA9.1</string>
			</array>
		</dict>
		<dict>
			<key>NSPrivacyAccessedAPIType</key>
			<string>NSPrivacyAccessedAPICategorySystemBootTime</string>
			<key>NSPrivacyAccessedAPITypeReasons</key>
			<array>
				<string>35F9.1</string>
			</array>
		</dict>
		<dict>
			<key>NSPrivacyAccessedAPIType</key>
			<string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
			<key>NSPrivacyAccessedAPITypeReasons</key>
			<array>
				<string>DDA9.1</string>
			</array>
		</dict>
		<dict>
			<key>NSPrivacyAccessedAPIType</key>
			<string>NSPrivacyAccessedAPICategoryDiskSpace</string>
			<key>NSPrivacyAccessedAPITypeReasons</key>
			<array>
				<string>DDA9.1</string>
			</array>
		</dict>
	</array>
</dict>
</plist>

I haven't confirmed this yet though.

marchbold avatar Mar 19 '24 03:03 marchbold

We are also working on this issue. In our case, Apple stopped saying anything by including a manifest that set the following four items as pointed out in the email from Apple.

- NSPrivacyAccessedAPICategoryFileTimestamp
- NSPrivacyAccessedAPICategoryDiskSpace
- NSPrivacyAccessedAPICategoryUserDefaults
- NSPrivacyAccessedAPICategorySystemBootTime

Next, we are thinking about how to handle the Privacy Manifest of the SDK included in the ANE we are using. I think that perhaps some ANEs such as Distriqt's Adverts and Firbase will also include PrivacyInfo.xcprivacy in the future. In this case, is it necessary to create PrivacyInfo.xcprivacy by merging these contents?

takazawa-gg avatar Mar 19 '24 06:03 takazawa-gg

I just submitted an app update to the App Store and received a warning about the same four categories (File Timestamp, Disk Space, User Defaults, System Boot Time). We only use a couple Distriqt extensions in this app (In App Billing and System Gestures), so I'm assuming these four items are internal to AIR itself.

@ajwfrost Will Harman provide recommendations of what to supply for this manifest, especially if we ourselves are not using any of these APIs? For example, I have no idea whether AIR needs System Boot Time access for reason "35F9.1" or for reason "8FFB.1" since we don't access this information ourselves for anything, and it sounds like Apple wants us to be precise in supplying our reasoning for access.

And I suppose the further question of whether ADT will eventually be generating a privacy manifest automatically like it does the Info.plist? Where we could alter the default values via a new PrivacyAdditions tag alongside the usual InfoAdditions or something similar? Or will we be responsible for creating the text file ourselves, and making sure we always include it when packaging?

FliplineStudios avatar Mar 21 '24 16:03 FliplineStudios

Hi

We're currently going through the API usage and trying to work out the appropriate codes to add... some of the reasons for our API usage are just to allow developers to use the capabilities, which makes it interesting! So, we are looking to have a "default" manifest that we generate based on the AIR runtime and its API usage. Then we will merge that with: a) any overrides - as you suggest there, we'd have something like PrivacyAdditions in the app descriptor file b) any ANEs - where the ANE object code itself is using one of these APIs etc, they can provide their own privacy manifest

So yes, the idea is that ADT does that part automatically, you shouldn't need to do much/anything here.

thanks

ajwfrost avatar Mar 21 '24 16:03 ajwfrost

@marchbold

I had added a privacy manifest file to the root path of package, which was working, no more warnings. The manifest file must be named PrivacyInfo.xcprivacy, the content could be like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>NSPrivacyAccessedAPITypes</key>
    <array>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>1C8F.1</string>
            </array>
        </dict>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategorySystemBootTime</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>35F9.1</string>
            </array>
        </dict>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>DDA9.1</string>
            </array>
        </dict>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryDiskSpace</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>E174.1</string>
            </array>
        </dict>
    </array>
</dict>
</plist>

Add manifest file to the package looks like easy to go, maybe it's ok to manage privacy this way. One thing to note: the location of privacy manifest file in iOS and macOS is different: macOS: Contents/Resources/ iOS: [package root] see: https://developer.apple.com/documentation/bundleresources/placing_content_in_a_bundle

yuyuanhua avatar Mar 21 '24 23:03 yuyuanhua

@yuyuanhua Yes that location (Contents/Resources/) on macos is the root level of your application content in AIR (i.e. this is where your swf and any packaged assets would end up). So it should be added the same to both iOS and macOS.

marchbold avatar Mar 22 '24 00:03 marchbold

FYI, the latest build of AIR SDK automatically generates a privacy manifest for iOS apps: https://airsdk.harman.com/download/50.2.5.1

Currently it's just using the internal default values, and merging in any information it finds within an ANE. In the next 51,0 beta release, we're also supporting a "PrivacyAdditions" section of the AIR descriptor file similar to the info additions, in order for apps to add in their own values..

ajwfrost avatar Apr 19 '24 11:04 ajwfrost

@ajwfrost Where should the privacy plist be located in an extension for it to be merged?

Is META-INF/ANE/iPhone-ARM/PrivacyInfo.xcprivacy correct?

Also will this update will handle PrivacyInfo.xcprivacy files in packaged frameworks? We are seeing most of the latest framework releases containing them now.

marchbold avatar Apr 22 '24 01:04 marchbold

Also couldn't find any docs on the PrivacyAdditions in the app descriptor. Would something like this be correct:

<iPhone>
    <PrivacyAdditions><![CDATA[
        <key>NSPrivacyAccessedAPITypes</key>
        <array>
            <dict>
                <key>NSPrivacyAccessedAPIType</key>
                <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
                <key>NSPrivacyAccessedAPITypeReasons</key>
                <array>
                    <string>1C8F.1</string>
                </array>
            </dict>
            <dict>
                <key>NSPrivacyAccessedAPIType</key>
                <string>NSPrivacyAccessedAPICategorySystemBootTime</string>
                <key>NSPrivacyAccessedAPITypeReasons</key>
                <array>
                    <string>35F9.1</string>
                </array>
            </dict>
            <dict>
                <key>NSPrivacyAccessedAPIType</key>
                <string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
                <key>NSPrivacyAccessedAPITypeReasons</key>
                <array>
                    <string>DDA9.1</string>
                </array>
            </dict>
            <dict>
                <key>NSPrivacyAccessedAPIType</key>
                <string>NSPrivacyAccessedAPICategoryDiskSpace</string>
                <key>NSPrivacyAccessedAPITypeReasons</key>
                <array>
                    <string>E174.1</string>
                </array>
            </dict>
        </array>
    ]]></PrivacyAdditions>
</iPhone>

marchbold avatar Apr 22 '24 01:04 marchbold

Where should the privacy plist be located in an extension for it to be merged? Is META-INF/ANE/iPhone-ARM/PrivacyInfo.xcprivacy correct?

Yes, just in the root of the platform-specific package..

Also will this update will handle PrivacyInfo.xcprivacy files in packaged frameworks? We are seeing most of the latest framework releases containing them now.

When you say "handle" .. it leaves them there. They should be included in the framework when it's packaged, and the packages are code-signed so we mustn't remove them. The Apple documentation is a little lacking on this point but our expectation is that the frameworks have their own privacy manifests, separately from the main application one.

couldn't find any docs on the PrivacyAdditions in the app descriptor

An app descriptor change would mean we have to change the namespace so e.g. going to a 50.3 release... so instead of that, we've put PrivacyAdditions into the 51.0 namespace and will be pushing out that functionality very shortly.. am hopeful that this kind of manipulation isn't actually going to be needed much, since any API or advertising usage etc that's not in our default-generated manifest should necessarily be provided from an ANE or a separate framework?

thanks

ajwfrost avatar Apr 22 '24 08:04 ajwfrost

That's true of dynamic frameworks, but what about static frameworks, do they need to be handled somehow? I thought their code was merged into the main binary so was assuming the privacy additions would need to be merged somehow?

I haven't done any testing of this yet, was just asking the question :)

marchbold avatar Apr 23 '24 01:04 marchbold