Apple Privacy Manifest File

[mattiacantalu]

Third-party software development kits (SDKs) can provide great functionality for apps; they can also have the potential to impact user privacy in ways that aren’t obvious to developers and users. As a reminder, when you use a third-party SDK with your app, you are responsible for all the code the SDK includes in your app, and need to be aware of its data collection and use practices [...]

Privacy manifest files outline the privacy practices of the third-party code in an app, in a single standard format. When you prepare to distribute your app, Xcode will combine the privacy manifests across all the third-party SDKs used by your app into a single, easy-to-use report. With one comprehensive report that summarizes all the third-party SDKs found in an app, it will be even easier for you to create more accurate Privacy Nutrition Labels.

Starting in spring 2024, you must include the privacy manifest for any SDK listed below when you submit new apps in App Store Connect that include those SDKs, or when you submit an app update that adds one of the listed SDKs as part of the update.
Describe the solution you'd like 🤔
A clear and concise description of what you want to happen.

Any update about the privacy manifest file?

[ericnordebaeck]

Hi @mattiacantalu, we will look into this in March/April.

[ZahraMammadli]

Hi @mattiacantalu ! Thanks for your comment. Please review comments below:

1. please review the privacy usage description provided in Info.plist file located in the following folder --> https://github.com/UPcload/FitAnalytics-WebWidget-iOS/tree/master/Resources
2. Identify the specific privacy usage descriptions that need to be included in the privacyInfo.xcprivacy file.
   Check keys located under "", "", ""
3. Copy and paste these descriptions into your privacyInfo.xcprivacy file.
4. Verify integration and proceed with your update process. All subsequent updates will be compliant upon the addition of these descriptions.

[mattiacantalu]

Hi @ZahraMammadli , thank you for your response.
Anyway isn't better providing the manifest on your side for everyone download and use the SDK?
Additionally the compliance is also about required reason API.

[ZahraMammadli]

@mattiacantalu our solution is web-view that wraps our web widget, so we are not using any native API directly.

[zarghol]

Hello, as this SDK is the way we consume the web widget, the SDK should include a privacy manifest file. This way it ensures we, as a user of a sdk, don't miss any way you use app user data.
Moreover, it allows to be merged automatically with other dependencies manifest when we generate our report, instead of manually handling all dependencies.

[ZahraMammadli]

@zarghol thanks for the input. We will update it on our side and get back to you shortly.

[nicolasjuarezn]

@zarghol this should be already solved, we made a new release with the added PrivacyInfo.xcprivacy file. Let me know if any further support is needed.

[zarghol]

Thank you to add the file ! however it is missing in our end, because you need to add it to Podspec for Cocoapod, and Package.swift for SPM
For reference :

• Podspec : https://github.com/onevcat/Kingfisher/blob/master/Kingfisher.podspec
• Package.swift : https://github.com/onevcat/Kingfisher/blob/master/Package%40swift-5.9.swift

[nicolasjuarezn]

@zarghol would you take a look to the following PR please #23 ?

[zarghol]

these changes seems okay to me 👍
However I checked the content of the privacy file, and the structure is not okay:
please check the documentation here : https://developer.apple.com/documentation/bundleresources/privacy_manifest_files
I tried to change your file in order to conform to the structure mentionned in the documentation:
PrivacyInfo.xcprivacy.zip
The tracking domains are still missing this example file

[mattiacantalu]

these changes seems okay to me 👍 However I checked the content of the privacy file, and the structure is not okay: please check the documentation here : https://developer.apple.com/documentation/bundleresources/privacy_manifest_files I tried to change your file in order to conform to the structure mentionned in the documentation: PrivacyInfo.xcprivacy.zip The tracking domains are still missing this example file

yes the manifest is not correct and doesn't follow the Apple documentation for keys and values.

Additionally @nicolasjuarezn check this Package.swift structure as an example:
https://github.com/SDWebImage/SDWebImage/blob/master/Package.swift

EDIT: an example of the manifest available also here https://github.com/SDWebImage/SDWebImage/blob/master/WebImage/PrivacyInfo.xcprivacy

[nicolasjuarezn]

Hey @mattiacantalu and @zarghol thanks for your help, I have a question because a few aspects of this topic remains unclear for me,

@zarghol

The tracking domains are still missing this example file

Base on my understanding, “Tracking” refers to linking data collected from your app about a particular end-user or device, such as a user ID, device ID, or profile, with Third-Party Data for targeted advertising or advertising measurement purposes, or sharing data collected from your app about a particular end-user or device with a data broker.

In theory the SDK would "track" the user within a WebView, but with the purpose of understanding/creating a profile in FitFinder for a logged in (or not -session based-) user. However, this is not for targeted advertising or advertising measurement purposes or "data collection" as if were for analytics.

On top of that we have business metrics that we trigger depending on different states of the widget, however everything runs under the same domain "fitanalytics.com", so it is a little bit unclear how to proceed here because I am afraid that I set the domain under NSPrivacyTrackingDomains as fitanalytics.com, if the user refuses, the widget won't load because the core widget relies on that domain.

Can you help me to clarify this topic?

Side Note: Thanks for the example, I will update the PR accordingly.

[mattiacantalu]

@nicolasjuarezn afaik trackings domains relay on AppTrackingTransparency.. (and yes potentially if the user rejects the ATT, then the widget could not work at all or not work as expected). BUT afaik (again 😄 ) these "domains" are not mandatory for the implementation.
@zarghol do you know anything else about it?

Source: https://developer.apple.com/wwdc23/10060?time=271

[zarghol]

This is how I understand all this things:

• Regarding NSPrivacyTracking:
  It must be YES in the file of the app if we track it ourselves. however, if a dependency, such as your library, track the user too, it must be YES in the privacy manifest of this dependency. The question in your case is, do you track the app user inside the webview ? maybe with cookies for example. it might be for good reason, this is not the point. the point is just if you do it.

• Regarding NSPrivacyTrackingDomains:
  It is explained that we must share at least one domain if the NSPrivacyTracking is set to YES. This might be the domain used for the tracking. In case of ATT rejected by the user, this domain will not work. In the WWDC video, they advise to separate tracking and business domains, to ensure this is okay.

• Regarding NSPrivacyCollectedDataTypes:
  This allows us as app developer to see a report based on all the dependencies privacy manifest, and better understand what's going on with the dependencies, and how we should update the app page. This could be really helpful

• Regarding NSPrivacyAccessedAPITypes:
  It seems it is the only part mandatory of the file ! it specifies if some APIs are used such as UserDefault storage, or System boot time.
  If none of these APIs are called, I think you should keep the key, with an empty array.

everything runs under the same domain "fitanalytics.com"

I think, it should be changed for clarity in you end, in order to have a better comprehension of how all the data fits together (no pun intended), and allows to be deactivated on a per user base if needed. Before this change, maybe just don't add NSPrivacyTracking and NSPrivacyTrackingDomains in the file, as only NSPrivacyAccessedAPITypes seems mandatory

[nicolasjuarezn]

According to the AppTrackingTransparency framework our app is not collecting data about the end users and share it with other companies for the purpose of tracking across apps and web sites.

We are processing data on behalf of our clients in order to provide our services and thus we will set NSPrivacyTracking to No.

You must use the AppTrackingTransparency framework if your app collects data about end users and shares it with other companies for purposes of tracking across apps and web sites.
Ref link

Based on my comment before:

Third-Party Data for targeted advertising (1) or advertising measurement purposes(2), or sharing data collected from your app about a particular end-user(3) or device with a data broker(4)

After a deep review, even with out internal teams, we are not doing any of the four topics mentioned above. We are exclusively using the collected data to provide our functionally, we are not data brokers.

So, I am going to update the manifest with NSPrivacyTracking to NO.
I've also did a last update to the PrivacyTracking definitions

<dict>
	<key>NSPrivacyTracking</key>
	<false/>
	<key>NSPrivacyTrackingDomains</key>
	<array/>
	<key>NSPrivacyCollectedDataTypes</key>
	<array>
		<dict>
			<key>NSPrivacyCollectedDataType</key>
			<string>NSPrivacyCollectedDataTypeUserID</string>
			<key>NSPrivacyCollectedDataTypeLinked</key>
			<true/>
			<key>NSPrivacyCollectedDataTypeTracking</key>
			<false/>
			<key>NSPrivacyCollectedDataTypePurposes</key>
			<array>
				<string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string>
			</array>
		</dict>
	</array>
	<key>NSPrivacyAccessedAPITypes</key>
	<array/>
</dict>

[mattiacantalu]

@nicolasjuarezn @ZahraMammadli i've left a comment here #23. Could you please take a look?