Add Privacy Manifest file on Kronos

[didix21]

Description

In the WWDC23, Apple announced new changes regarding privacy. Now, apps and third parties will have to include a file called a Privacy Manifest file.

After digging into the Kronos project, I've just observed that it's using UserDefaults API here. According to Apple documentation, if the SDK uses the UserDefaults API, then it must include a PrivacyInfo.xcprivacy file mentioning any approved reason for why it's used. I think in this case, the reason would be: CA92.1.

[yasiraliraj]

Hello Kronos Team,

I hope this message finds you well. I would like to draw your attention to an important update required by the App Store. Starting May 1, 2024, a privacy manifest will be mandatory for all apps. Given the ongoing development and support for your SDK, integrating this feature would be highly beneficial for ensuring compliance with the new App Store guidelines. This addition would greatly help developers like us in continuing to provide seamless services through our applications. We appreciate your attention to this matter and look forward to any updates you can provide.

Thank you for your continued support.

[keith]

track the PR here #112

[gabriellupu]

Looks like TimeFreeze is implementing systemUptime() method that according to Apple Docs needs to be reflected in the privacy manifest file as NSPrivacyAccessedAPICategorySystemBootTime

Proposed solution

<key>NSPrivacyAccessedAPITypes</key>
<array>
  <dict>
    <key>NSPrivacyAccessedAPIType</key>
    <string>NSPrivacyAccessedAPICategorySystemBootTime</string>
    <key>NSPrivacyAccessedAPITypeReasons</key>
    <array>
      <string>35F9.1</string>
    </array>
  </dict>
</array>

[marcosgriselli]

@gabriellupu Apple docs mention the usage of ProcessInfo.systemUptime which a Foundation API. Kronos doesn't use any of the restricted APIs on it's systemUptime implementation so there's no reason to include the NSPrivacyAccessedAPICategorySystemBootTime key.

[gabriellupu]

@marcosgriselli thanks for your feedback! Adding for reference this comment since it's related to this issue: kstenerud/KSCrash#457 (comment)
Also, I suspected this one to be causing NSPrivacyAccessedAPICategorySystemBootTime policy warning for my app since no other library has any reference to BootTime-related aspects.
Maybe Apple checks for KERN_BOOTTIME usage when running the policy validator?

[marcosgriselli]

I'd say the KSCrash issue is different since the library is the one sending the data off-device while Kronos doesn't.
I'd be interested to learn more about your scenario, are you sure there's no other dependency (and their dependency tree) that calls either systemUptime or mach_absolute_time?. What Apple does behind the scenes is unknown to us but my understanding is that since KERN_BOOTTIME is not a a symbol or function it won't be visible if the binary is inspected.

Having said this, the library does use a system boot time API and since the usage is within the valid reasons (35F9.1) we could add it even though is not explicitly requested.

[leslieolivier]

Hi! Could the NSPrivacyAccessedAPICategorySystemBootTime be caused by the use of sysctl in TimeFreeze.systemUptime(). I get the policy warning for both the main target and the widget target. Kronos (and Alamofire) are the only dependencies off the widget target.

[didix21]

@leslieolivier, you have a point. I've been checking again with this script: https://github.com/Wooder/ios_17_required_reason_api_scanner. Apparently, the binary only contains the NSUserDefault symbols:

Used symbols in binary ./Kronos.xcframework/ios-arm64_x86_64-simulator/Kronos.framework/Kronos: NSUserDefaults
Used symbols in binary ./Kronos.xcframework/ios-arm64/Kronos.framework/Kronos: NSUserDefaults

But if I use the other script and I check on the Kronos source code, then I get:

Found potentially required reason API usage 'systemUptime' in './Sources/TimeFreeze.swift'
Line numbers: 18 20 25 31 41 73
Found potentially required reason API usage 'UserDefaults' in './Sources/TimeStorage.swift'
Line numbers: 5 12 25 28 29 52 58 59

[marcosgriselli]

@leslieolivier Alamofire uses system boot time APIs as defined in their privacy manifest

Kronos defines it's own systemUptime function which doesn't use one of the reason required APIs

[didix21]

@keith: Do you have a date when the next Kronos release will be performed?

[keith]

I pushed 4.3.0 with an updated podspec. if you find any new problems please open an issue! thanks all!