Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix privacy manifest issues #314

Merged
merged 2 commits into from Apr 3, 2024

Conversation

Westacular
Copy link
Contributor

Fixes two issues related to the privacy manifest:

  1. The manifest itself is kind of invalid (as discussed in The collection purpose for the "Privacy Nutrition Label Types" is absent in the Privacy Manifests. #313)

Including a NSPrivacyCollectedDataTypes entry but specifying empty strings is incorrect. Instead, you can just specify an empty array for NSPrivacyCollectedDataTypes at the top level. Also, the top level NSPrivacyTracking and NSPrivacyTrackingDomains keys were missing; I've added them with false/empty values as appropriate.

  1. The podspec reference for the privacy manifest was problematic.

When static framework linking is used with Cocoapods, files referenced using resource are just directly copied into the main app bundle, potentially clobbering each other or main app resources in the process. i.e., the PrivacyInfo.xcprivacy from ZIPFoundation can overwrite the one for the app itself.

The correct way to include PrivacyInfo.xcprivacy is by using resource_bundles to create a nested bundle to contain the file. (If dynamic linking is used, this bundle will be nested inside the framework bundle for the pod; if static linking is used, the bundle is nested directly in the main app bundle. In either case, clobbering is avoided.)

(Reference: CocoaPods/CocoaPods#10325)

Including a NSPrivacyCollectedDataTypes entry but specifying empty strings is ... kind of invalid.

Instead, you can just specify an empty array for NSPrivacyCollectedDataTypes at the top level.

Also, the top level NSPrivacyTracking and NSPrivacyTrackingDomains keys were missing; I've added them with empty values.
When static framework linking is used with Cocoapods, files referenced using `resource` are just directly copied into the main app bundle, potentially clobbering each other or main app resources in the process. i.e., the PrivacyInfo.xcprivacy from ZIPFoundation can overwrite the one for the app itself.

The correct way to include PrivacyInfo.xcprivacy is by using `resource_bundles` to create a nested bundle to contain the file.

(If dynamic linking is used, this bundle will be nested inside the framework bundle for the pod; if static linking is used, the bundle is nested directly in the main app bundle. In either case, clobbering is avoided.)
@weichsel
Copy link
Owner

Hi,
Thanks for providing this PR. The fixes for the podspec look great 👍.
I just tested the proposed changes to the privacy manifest itself and ran into a few issues though:

Including a NSPrivacyCollectedDataTypes entry but specifying empty strings is incorrect. Instead, you can just specify an empty array for NSPrivacyCollectedDataTypes at the top level

I just pointed the dependencies of a large project I am involved with to your branch and noticed that the Xcode privacy report no longer contains any entries for ZIP Foundation.
When reverting back to the current release tag, the privacy report properly contains an entry for ZIP Foundation (integrated via Xcode SPM):
Screenshot 2024-03-15 at 09 36 45

@Westacular
Copy link
Contributor Author

I can't find any explicit confirmation of this, but I believe that the purpose of those Xcode privacy reports is specifically to help app developers fill out the "Privacy Nutrition Label" forms, with regard to what data is collected, how, and why.

i.e., it's only surfacing details within NSPrivacyCollectedDataTypes. The otherwise empty line with the dash at the bottom of your screenshot is where the report should list the purposes (from NSPrivacyCollectedDataTypePurposes) for the data collection. ZIPFoundation isn't specifying a valid value there, and Xcode's showing a broken-looking empty string as a result.

The details in NSPrivacyAccessedAPITypes aren't surfaced in the Xcode privacy report at all, and frameworks that don't collect data and don't list anything in NSPrivacyCollectedDataTypes are ignored by the Xcode report, but it's my understanding (although the docs aren't clear) that privacy manifests that only have details in NSPrivacyAccessedAPITypes (and none in NSPrivacyCollectedDataTypes) are not ignored by App Store Connect when analyzing an uploaded app... but I just don't know because Apple's docs and tools aren't clear on this. 🙁

@RobertManeaSST
Copy link

Hi, any chance of this getting merged soon? I currently can't run my app if I create a Privacy file for it as well, as I'm getting the Multiple commands produce error for the PrivacyInfo from ZIPFoundation

@lorenc-tomasz
Copy link

@weichsel Please merge it :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants