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
