Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Privacy manifest file #1479

Closed
danielepantaleone opened this issue Jan 9, 2024 · 11 comments
Closed

Privacy manifest file #1479

danielepantaleone opened this issue Jan 9, 2024 · 11 comments
Labels
enhancement needs revisiting This issue was closed but it has unfinished business

Comments

@danielepantaleone
Copy link
Contributor

Starting from Spring 2024 Apple requires apps and third party SDKs to include a Privacy manifest file. Would it be possible to include it in the next release of GRDB?

https://developer.apple.com/documentation/bundleresources/privacy_manifest_files

@groue
Copy link
Owner

groue commented Jan 9, 2024

Hello @danielepantaleone,

This is a good idea. I'm not sure it is required, strictly speaking. I'm not sure GRDB even uses any of the restricted APIs. But shipping such a manifest would solve the reasonable doubts that library users could have. 👍

Would you consider submitting a pull request? I haven't looked precisely at the Apple documentation, but it would be nice to do the right thing for all GRDB users (SPM, CocoaPods, manual installation), whatever it is. The right thing is the thing that 1. makes GRDB a good citizen and 2. does not force users to do some work when it could have been done by the library. Treat others as you would like to be treated.

@danielepantaleone
Copy link
Contributor Author

See #1480

@groue
Copy link
Owner

groue commented Jan 24, 2024

Closing due to lack of relevant feedback, both in public and in private emails.

@groue groue closed this as completed Jan 24, 2024
@groue groue added the needs revisiting This issue was closed but it has unfinished business label Jan 24, 2024
@danielepantaleone
Copy link
Contributor Author

Hi, I'm sorry about the "lack of relevant feedback, both in public and in private emails", but I have been on holidays for past 2 weeks and I didn't had time to have a deeper look into the issue. I honestly didn't think I would have to provide an answer in such a short time, given that GRDB is an open source project, where people usually contribute in their spare time.

Also, I didn't think we had to change something in #1480 since you initially stated: "I close the pull request and I am not asking for a better one", so we genuinely thought that the PR did not respect the template and thus had been closed, but the solution to the issue would have been implemented anyway, also because without the Privacy manifest file app apps using GRDB SDK will be automatically rejected when being submitted for Apple review on the App Store.

@groue
Copy link
Owner

groue commented Jan 29, 2024

Yes, @danielepantaleone, you're totally right: contributions are open and there are no obligations. Once a conversation/issue/pull request is started, though, the original poster is expected to be available to requests. That's courtesy.

I outlined in an email to @giobass some necessary fixes to the original PR, and a possible way forward. I copy them below:

Hello giobass,

Thanks for your kind message. Yes I'll happily welcome a new, enhanced, pull request. :-)

You'll find the PR template displayed in the pull request creation form. See #1466 for an example of a PR that was created by a user who have read the template. Take care of the target branch, and fork from the development branch. I think you can ignore documentation and tests here.

I have also looked for restricted APIs usage, and found none.

I think your initial PR did things correctly for CocoaPods, although I haven't checked yet.

I think your initial PR did things correctly for GRDB.xcodeproj, although I haven't checked yet.

Please also add the privacy manifest to GRDBCustom.xcodeproj as well (you'll discover about this project in CONTRIBUTING, mentioned in the pull request template).

Please amend your PR for SPM: fix the resource path, and remove the manifest from the test target.

I also apologize for my initial answer, which was harder than necessary. Let's say that a rushed PR has a rushed response!

Welcome to GRDB contributors, giobass :-)

Regarding this sentence of yours:

without the Privacy manifest file app apps using GRDB SDK will be automatically rejected when being submitted for Apple review on the App Store.

This is not what I understood reading the Apple documentation, but I may have forgotten something. Do you have any link that supports the fact that privacy manifests are a hard requirement for libraries, especially libraries that do not cross any of the privacy limits such as this one?

@danielepantaleone
Copy link
Contributor Author

https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api

This is what I could find. In the first yellow box is specified:

From Fall 2023 you’ll receive an email from Apple if you upload an app to App Store Connect that uses required reason API without describing the reason in its privacy manifest file. From Spring 2024, apps that don’t describe their use of required reason API in their privacy manifest file won’t be accepted by App Store Connect.

So I believe that a Privacy manifest file must be provided even if no privacy sensitive API is being used. I guess a privacy manifest file with NSPrivacyTracking set to false, and other required keys set to an empty array would do the job.

@groue
Copy link
Owner

groue commented Jan 30, 2024

Apple puts the burden on apps, not libraries. I see nothing that supports your claim that "without the Privacy manifest file app apps using GRDB SDK will be automatically rejected", which sounds hyperbolic and factually inaccurate.

We're back to my original comment, which describes the presence of a privacy manifest in the library as a delicate touch, nothing more.

The way forward, if you are looking forward for it, was outlined above in my reply to @giobass.

@danielepantaleone
Copy link
Contributor Author

In this other page it's specified that APPs and Third Party SDKs have to include the Privacy manifest: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files. I agree that it's not very clear.... 😁

@groue
Copy link
Owner

groue commented Jan 30, 2024

In this linked page, I read:

Apps and third-party SDKs — distributed as XCFrameworks, Swift packages, or framework bundles — can contain a privacy manifest file, named PrivacyInfo.xcprivacy.

The verb is can, not must.

I agree Apple doc is not very clear, but let me remind you that YOU are the person who makes bold claims about this library, which are not firmly grounded, and try to draw me into a conversation whose purpose isn't very clear either.

Again:

The way forward, if you are looking forward for it, was outlined above in my reply to @giobass.

That's the best I can do for you. Have a nice day!

@danielepantaleone
Copy link
Contributor Author

I'm not making any bold claim about this library; I'm trying to point out a possible problem that this library may have, together with many other ones, due to new Apple policies:

I guess you have issues with chat/board communications since here nobody is arguing with anyone about this library, which is also very good and well maintained. Probably you are the only one who is using a tone of speech which is a bit harsh, see your reply here #1480.

Anyway, I guess we'll figure it out very soon.
Have a good day.

@groue
Copy link
Owner

groue commented Jan 30, 2024

My apologies to anyone who has doubts after reading this conversation.

The repository will welcome a pull request which adds a privacy manifest to GRDB. An outline of the necessary changes is described in this comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement needs revisiting This issue was closed but it has unfinished business
Projects
None yet
Development

No branches or pull requests

2 participants