User changing clock

[russellquinn]

I'm trying to stop the user from setting their clock forward to gain access to content ahead of time. But, when I manually set my device time, ios-ntp returns the false time. It looks like the offset from the timeservers is too great, so they're all marked as untrustworthy?

[tiborgrose]

It's hardwired to reject offsets of more than 3600 seconds. You can change that value in the NetAssociation evaluatePacket method.

[tiborgrose]

There is another issue you'll run into if you're trying to prevent tampering with time. This code keep track of the last 8 good responses from each server in the hosts file. Each array of 8 is averaged to present the best guess of that server's time. If the user changes the time while the app is running, old results will be mixed with the new results, giving a bad average and therefore the incorrect time will be reported. The time will correct itself as new server responses push out the old ones in the array, but for several minutes, you'll have the wrong time.

One solution would be to only keep one value instead of 8. Another would be to not use the singleton form of NetworkClock, but rather just create it as you need it and make sure you destroy it if your app goes into the background, since that's when the user will have an opportunity to change the time from under you.

[danielsefton]

Did anyone come up with a real solution to this? I tried tiborgrose's suggestions, but the time is still incorrectly reported right after you change the time. Releasing NetworkClock and re-allocating on background enter/exit didn't work at all. Keeping one value made the time correct itself faster, but only after calling finish/enable associations two or three times. The rejection value is totally useless if you consider the user can forward the clock to any day of the year. I guess the apps that manage to keep time regardless of user clock changes simply query their own NTP-synced server.

[tyork]

What about listening for UIApplicationSignificantTimeChangeNotification and using that to flush the array of previous responses?

[gavineadie]

This is fixed.

[danielsefton]

Thanks, but I tested it and it didn't fix it, assuming it was this line in NetAssociation.m:

(ntpDiffSeconds(&ntpServerBaseTime, &ntpServerSendTime) < 3600.0)) {

Changing the clock forward still causes time to jump ahead even with the above line.

Really this issue can only be solved if what is described by tiborgrose is addressed.

[gavineadie]

The weakness exposed by tiborgrose does contribute to causing the wrong time to be reported when the device clock is advanced, either the fifo should be invalidated on a device clock jump, or the fifo should carry absolute, not relative, time. The code also cannot be relied on for an early clock check for similar reasons. I'll address both problems shortly .. I'd like to summarize my planned approach here for your review, but my personal time is limited for a few days. At least the code isn't worse than it was last week!

[rursache]

i can confirm this is a issue even now!

[warpling]

Thanks for the update @gavineadie and for putting your library on cocoapods!

I'm unable to rely on ios-ntp because of the user clock issues. The addition of reacting to UIApplicationSignificantTimeChangeNotification helps but there's a significant period after where the reported time is wrong and I don't know when to start trusting the ios-ntp clock again. Before I try to bandage together my own solution associating network times with mach_absolute_time I was wondering how you were planning to approach the problem?