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
