Privacy Concerns calling systemUptime API about alamofire HOT 17 CLOSED

That is not equivalent. Date is still subject to time correction on device, such as when an NTP update comes in, and is therefore not recommended for anything needing precise timing, or guarantees that time will always increase. Alamofire needs both.

from alamofire.

Date can also change when the user changes the time on device, so it can veer backward and forward arbitrarily. Timing information is useful as debugging info, but we also use it to track retry timing over requests, which must be accurate, otherwise retries won't occur when expected. This could be especially important for auth systems, which rely on precise expirations to avoid extra reauth calls.

from alamofire.

Ah, you're right, they just changed the requirement from all to "newly added" SDKs. In any case, Alamofire has the manifest in place, we'll see if Apple's tools actually work.

from alamofire.

Alamofire does declare these usages in the privacy manifest, Apple just doesn't detect it properly, especially when you use SPM, as they don't check for manifests for statically linked code. You can add the declarations to your own manifest for the scanner to pick up.

Alamofire uses systemUptime as a monotonically increasing clock to track time elapsed for certain metrics. Any equivalent replacement would also require a privacy declaration (morally, if not literally), so there's no real way around it here. But if there is an equivalent, I'd be happy to hear about it.

from alamofire.

Also, note that this requirement isn't yet blocking, just a warning from ASC, and Apple has recently removed the deadline from the privacy manifest page, so it may not be required at all.

from alamofire.

Thanks Jon, didn't know they pushed it back. Could probably just use a separate timestamp and they would never care. Would be an easy implementation too. Is the team 100% set on keeping calls to this API in the codebase?

from alamofire.

Timestamps are subject to change when the user's clock updates, so they are not a replacement for a monotonic clock like systemUptime. I'm perfectly willing to change to another API given it has the same capabilities. However, any such API is likely to be subject to Apple's privacy policy, given it can likely be abused in the same way.

from alamofire.

What's the architectural requirement for this? I was surprised to see this in all of DataRequests, downloads, websocket calls, and authentication. Without knowing any better, this seems like overkill and totally unnecessary.

from alamofire.

It's simple timing information, used to provide information to Alamofire's users, as well as power certain retry implementations that need exact timing. It's clear you're unfamiliar with systemUptime and Alamofire's use of it, so what exactly is your issue here? This is one of Apple's accepted uses of the API, so there should be no impact on privacy in the first place. If their tools worked correctly you'd never even know the API was in use.

from alamofire.

Gotcha, why not just use epoch time instead?

from alamofire.

What API, exactly, do you mean? AFAIK, all equivalent APIs to systemUptime require a privacy note.

from alamofire.

NSDate().timeIntervalSince1970 will give you current epoch time as a double value, not subject to timezone specific clock changes.

systemUptime will be an equivalent value across apps on a specific device, whereas epoch is shared globally, so if somehow the raw value of systemUptime were to appear server-side or were scraped in any way, it would not be traceable to a particular user's device. This is an industry standard way for measuring timezone agnostic timestamps and time changes and would arguably work just as well.

from alamofire.

Gotcha, even though its an awfully rare edge case - a device has been off or disconnected from the internet so long its had some time-drift and fixes the time mid-cycle or between api calls... The systemUptime would be unaffected. So that makes sense. But its not like Alamofire is using this for anything critical its just timing calls. What if one timing is off by a bit? Will it fail network calls?

from alamofire.

Nevermind I'll screw off now. Thanks for the good discussion. Have a good rest of your Monday :)

from alamofire.

Yeah I'm a bit peeved that this is calling out APIs that I don't even call in the dependent SDKs. I hadn't heard they delayed this past May 1 though, but glad they did. Thanks again.

from alamofire.

If Apple's tools worked correctly, Alamofire's manifest would cover the usage and that tool you linked would just ignore Alamofire's source. However, Apple's tools still have issues with statically (and sometimes dynamically) linked product with their own manifests, so it actually makes a bit of sense. It's unclear to me whether Apple will actually surface these approved API usages in some report to the user, but since the deadline has been removed, I don't know what Apple's planning.

from alamofire.

when did Apple remove the deadline and from where?

from alamofire.