I would expect this info to come from plugin.xml and config.xml. I haven’t looked at Android innards in a long time, but doesn’t this just mirror their intents? Play store tells users the capabilities of each app, and this is all pulled together from the plugins ..
> On Oct 28, 2023, at 4:00 AM, Norman Breau <nor...@breautek.com> wrote: > > Based on > https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api?language=objc > > I don't think there is localization involved. It looks like you supply two > pre-defined constants, > and whichs refers to an API or a set of APIs and a reason. So you don't > describe the reason > yourself. > > This will probably make it really easy to manage and merge manually tbh but I > do agree > that we should avoid using edit/config-file directives to do this. The app's > xcprivacy can > probably be easy to built up on prepare. > > I like Erisu's idea but I do find it a bit odd to put in in package.json when > plugin and app configurations still for the most part lives in > plugin.xml/config.xml. > >> On 2023-10-28 4:44 a.m., Niklas Merz wrote: >> 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
