Add Privacy Manifest file on Kronos about kronos HOT 11 CLOSED

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.

from kronos.

@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?

from kronos.

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.

from kronos.

track the PR here #112

from kronos.

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>

from kronos.

@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.

from kronos.

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.

from kronos.

@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

from kronos.

@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

from kronos.

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

from kronos.

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

from kronos.