I looked into this a bit yesterday, and think there are a few ways we might be able to handle this (none of them ideal).
For background, Apple is requiring apps to include a xcprivacy plist file that has declarations about what privacy-impacting APIs they use (i.e., APIs that could be used for fingerprinting) and what data sharing and tracking they do. For apps that consume 3rd party SDKs, Apple is making it possible for the SDK providers to embed their xcprivacy plist as part of a framework bundle. Apps that use the framework will inherit the privacy declarations of their SDK frameworks in addition to their own declarations. Separately, but at the same time, Apple is introducing code signing to framework bundles to help app developers better trust that their frameworks came from trusted/consistent sources. What does this mean for Cordova? -------------------------------- If we take the simplest interpretation: nothing. Cordova is not distributed as a framework or SDK bundle, it is source code that's included in the app (both CordovaLib and any installed plugins). Therefore, Cordova itself technically doesn't need to provide any privacy plists and it's up to the app developer to handle all the declarations based on how they're using Cordova. However, that kinda sucks for app developers, who might not know if a particular plugin uses privacy-impacting APIs (such as NSUserDefaults, or file system access). The problem for us is that because plugins are not distributed as framework bundles, we cannot provide xcprivacy plist files for each plugin and rely on Apple automatically merging them. Suggestions for now ------------------- 1. Add a blank PrivacyInfo.xcprivacy plist file to the Cordova iOS template as a resource. 2. Add a (mostly blank, but accurate) PrivacyInfo.xcprivacy plist file to CordovaLib as a resource, so that it's available for anyone consuming CordovaLib from Swift Package Manager or as a framework (unclear to me how this impacts Cocoapods...) 3. I guess our best option right now is to have plugins that need to make declarations do so via <edit-config> into the xcprivacy plist, which is going to be super prone to conflicts if multiple plugins need to add the same declarations :( I really don't like the idea of relying on edit-config/config-file injection behaviour to manage this plist, because it's almost guaranteed to cause conflict issues when adding/removing plugins, but I don't have better ideas at the moment. It doesn't seem feasible to change things such that each plugin ends up as a framework bundle, since that would be a major architectural change (although perhaps one that needs to happen?) If we have specific questions for Apple where we need clarification or recommendations, I can reach out to someone there and see if we can get any help. ~Darryl On Fri, Oct 27, 2023 at 8:28 AM Jesse <purplecabb...@gmail.com> wrote: > Has anyone looked at privacy manifests for iOS apps? > … > > > As you may know, in June, Apple announced new features to help users > understand developers’ privacy and data collection and sharing practices. > These new features include privacy manifests and signatures, which we > encourage all third-party SDKs to adopt to provide transparency to users > and help secure the software supply chain. Third-party SDKs that impact > user privacy will be expected to include a privacy manifest and signature, > and starting in Spring 2024, new and updated apps that include these > third-party SDKs will need to include their manifest and signature to > submit to the App Store > >
