I did not dig deep into the documentation and the details about that but I would like to add two things to consider:
1. Internationalization: Are there any strings that are shown to the user like "NSLocationAlwaysAndWhenInUseUsageDescription"? For this we had no simple way to show that in the users language. Looks like there a predefined types [1] so this should be no issue. 2. The app developer should be able to overwrite the plugins values. If a plugin defines APIs and purposes the app developer might want to overwrite the default values because they are using the API for just a specific purpose or they are using only a subset of the APIs the plugin implements. Erisus idea sounds like a good start. edit-config will cause trouble really quickly I suppose. [1] https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_data_use_in_privacy_manifests#4250556 On October 28, 2023, Erisu <er...@apache.org> wrote: > IMO, I think we should store the information in "package.json" and > build up the data before injecting into plist. > > I personally think we should avoid "edit-config" or "config-file" at > all costs. It has always been error prone and a pain-point for us. > > The structure below is just an idea. This structure can be added to > both plugins' and app's "package.json". > > == > { > "cordova": { > "id": "cordova-plugin-statusbar", > "platforms": [ > "android", > "ios" > ], > "ios-privacy": { > "NSPrivacyCollectedDataTypes": ["..."], > "NSPrivacyAccessedAPITypes": ["..."], > "NSPrivacyTracking": true > } > } > } > == > > During the "cordova prepare" step, we would extract all "ios-privacy" > settings. > > We would merge together all data sets. > > Filter the "NSPrivacyCollectedDataTypes" and > "NSPrivacyAccessedAPITypes" to extract out the unique items. > > And if any one plugin or the app has defined "NSPrivacyTracking" as > "true", it remains "true". > > The reason we would allow the same structure to be defined in the > app's "package.json" is so that app developers could manually review > and define these values for the plugins that are unmaintained. > > > > On Oct 28, 2023, at 12:15, Darryl Pogue <dvpdin...@gmail.com> wrote: > > > > 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 > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org
