Adhere to Apple's Data Collection / App Privacy details

[bpoplauschi]

New Issue Checklist

• I have read and understood the CONTRIBUTING guide
• I have read the Documentation or CocoaDocs
• I have searched for a similar issue in the project and found none

Issue Info

Info	Value
Platform Name	all
Platform Version	-
CocoaLumberjack Version	latest

Apple's Data Collection / App Privacy details

Apple is changing the submission process by requiring app developers to describe their data collection and privacy practices in App Store Connect.
For this process to run smoothly, they have asked SDK developers to provide the same details so that app developers can compile a list from all their dependencies and their explicit ones.
See details:

• https://developer.apple.com/app-store/app-privacy-details/
• https://developer.apple.com/app-store/user-privacy-and-data-use/
• similar thread on the Firebase SDK GH proj: Firebase Analytics: New Apple Privacy Guidelines (Fall 2020) firebase/firebase-ios-sdk#5928
• similar thread on the SDWebImage proj: Adhere to Apple's Data Collection / App Privacy details SDWebImage/SDWebImage#3126

Todo

What's required of us at this point is to gather that data and make it available on our documentation.

• compile list of CocoaLumberjack's privacy practices
• make it available and explicit within our docs and repo (as links)
• regenerate the doc pages to include the updated Readme

Prototype

I have started working on a prototype which I added as static web pages to our github.io docs:
https://cocoalumberjack.github.io/DataCollection/index.html.

At my first review round, I couldn't find any private data we are collecting from the users, but I may have missed something.
@CocoaLumberjack/collaborators please go through this list https://cocoalumberjack.github.io/DataCollection/index.html and let's discuss if there is any data there that you think we may be collecting in some place of our SDK.

[ffried]

Wow, totally read this earlier this year but also totally forgot about it again! Thanks for bringing it up!

I think we're in a tricky spot here. While I agree, that we don't collect anything ourselves right now, we're shipping a framework that allows to track basically all of it. DDLogInfo("User: \(myUser)") and we might have names, addresses, phone numbers, ..., ... (depending on what myUser contains) inside a log file on disk (if DDFileLogger is used).
I'm not saying, that we need to take this upon us. You can just as well also do DDLogError("something went wrong") and no critical information is contained in the logs.
My point is, that we probably need to give users of our SDK a clear distinction between what we collect (as above: AFAIK nothing) and what they could collect.
I'm not sure what's the right approach here. We could make it easy for ourselves and simply declare what we collect and add a statement saying "the rest is your responsibility". Or we could make it a bit easier for our users and give a lot of examples on what they might log and what this would mean for that data collection list.

[sushichop]

Thanks for letting us know this.
While we need to carefully check the code again, CocoaLumberjack does not get any unique information AFAIK.

My point is, that we probably need to give users of our SDK a clear distinction between what we collect (as above: AFAIK nothing) and what they could collect.

So I agree with the above.

[bpoplauschi]

@ffried Great point of view for how we might be collecting data, which I never thought about. Let's discuss further.

Apple's definition is the following:

“Collect” refers to transmitting data off the device in a way that allows you to access it for a period longer than necessary to service the transmitted request in real time.

Based off that, I think even if we pass that data through the DDFileLogger or the DDOSLogger, it ends up on the device, we or nobody else gets a copy and it's not accessible from outside the app code (considering how the sandbox works on iOS). It is a different conversation if this happens on the MacOS where one can access log files from other apps.

Also, I would like to mention any custom loggers built on top of DDLogger (for example I always use a DDLogger class to pass logs to Fabric so they are collected with crashlogs and available in their web interface). I think in this case or similar, user data is indeed being collected according to the definition, but we (CocoaLumberjack) are not responsible for it.

I like the idea of having our docs explicit about what we collect (nothing) and what they could collect.
But we need to have the list I compiled somewhere so it's clear.
I suggest we expand our explanations in a section of our Readme and on the doc pages http://cocoalumberjack.github.io/

[ffried]

Based off that, I think even if we pass that data through the DDFileLogger or the DDOSLogger, it ends up on the device, we or nobody else gets a copy and it's not accessible from outside the app code (considering how the sandbox works on iOS). It is a different conversation if this happens on the MacOS where one can access log files from other apps.

It's not as trivial on iOS either. In basically all of our apps, we're using a DDFileLogger and have a feature where the user can send us a support mail where the log files are attached. So even on iOS, the app might match Apple's definition of "collecting".

Also, I would like to mention any custom loggers built on top of DDLogger

Yes of course, custom loggers also fall into this category. Like I said, we provide a framework that in theory allows to track data in all of the listed categories.

I like the idea of having our docs explicit about what we collect (nothing) and what they could collect.
But we need to have the list I compiled somewhere so it's clear.
I suggest we expand our explanations in a section of our Readme and on the doc pages http://cocoalumberjack.github.io/

I'm totally fine with the list you compiled! Thanks again for putting it together!
This would be the part "what we collect".

I think we should have another list or at least a template statement for what fits most applications that log some data e.g. to files (or with custom loggers to anywhere). This way, it's very easy for users of CocoaLumberjack to just copy that statement (as long as they do not log anything that isn't covered by that statement). If the statement is well thought-through, this also provides a consistency between apps using CocoaLumberjack.
I wonder if the swift-log team would also provide something like that. Given that we're not the only logging framework out there, we're certainly not the only ones with this issue. And I'd totally welcome consistency between all apps that use logging frameworks. And I think that would be in the best interest of app users as well.

[piobyz]

Hi guys, I'm analysing Apple Privacy Details myself, not in context of CocoaLumberJack, and thought that maybe you could take advantage of optional-disclosure?
Although, last point "The data is provided by the user in your app’s interface" is a bummer here, CLJ cannot guarantee that, the opposite, majority of data will be behind the scenes, outside of any UI.

[piobyz]

additional-guidance section, "Your app includes free-form text fields..." may be also interesting to you.

[ffried]

@piobyz Thanks for those links! However, I think these don't apply to CocoaLumberjack, since we're an SDK not an app. It all heavily depends on how our SDK is used. If you build an app and only ever log one "Hello, World" message, you're tracking nothing. If you log a user model object, you might be tracking a whole lot more.
So the actual decision needs to be made on a per-app basis. However, I think these links could totally make it into a section where we try to help users of our SDK to put together what they collect!

[bpoplauschi]

@ffried I agree, we can be helpful to the app developers that use our framework.
Please take a look at #1191 as I tried to split the 2 categories of info, the one that is required by Apple (our own data collecting) and the indirect one that can happen via our framework.
Let's discuss on the PR if you or anyone else have suggestions there.

[sushichop]

Example: DDLogInfo("User: (myUser)") will add the myUser info to the logs, so if those are forwarded to a 3rd party or sent via email, that may qualify as data collection.

I also think this is a good example that is easy for people to understand😉

[bpoplauschi]

I just merged #1191. Before closing this issue, I just want to regenerate our doc (github.io) so it includes the updates from README.md

[bpoplauschi]

The doc on github.io is up to date now, closing this issue.