If they are careful with their implementation, they could protect against it. The naive way is to store the time of last unlock and simply compare that against the current time, but there are other ways:
(1) Once 7 days elapses, set a flag that can only be cleared by unlocking the device, and check that flag in addition to the time.
(2) If there is an internal hardware clock that isn't synced to real time, just count relative to that clock. You don't need to know absolute time to check how long it has been since last unlock.
> (2) If there is an internal hardware clock that isn't synced to real time, just count relative to that clock.
This is known as a montonic clock and it’s been built in to most hardware for exactly this reason. Mach, Linux, etc. have encouraged use for anything where things like leap seconds or time changes aren’t desirable.
Minor point of clarification, but I meant something slightly different than a monotonic clock, hence why I said hardware clock.
For the approach I described, a clock would need to keep ticking while the system is powered off or in various power-saving modes. And it shouldn't get reset at boot time. Not all monotonic clocks have both these properties. (Obviously iPhone isn't Linux, but one example is that Linux's CLOCK_MONOTONIC seems to lack both properties, and its CLOCK_BOOTTIME seems to lack the second one.)
Though if you have a clock that resets at boot, you can work around that by disabling USB data on bootup and not enabling it until first unlock.
On Linux, I believe what you’re looking for is CLOCK_MONOTONIC_RAW but that’ll also depend on your particular hardware and its security.
On iOS, I’m not sure it matters for the reason you mentioned: at least on my devices I don’t see hotplug events until the device has been unlocked once.
> If there is an internal hardware clock that isn't synced to real time, just count relative to that clock.
There is. All modern operating systems, including iOS, have one. Without it, commonly used features like animations and media playback would misbehave during network time synchronization.
If they are careful with their implementation, they could protect against it. The naive way is to store the time of last unlock and simply compare that against the current time, but there are other ways:
(1) Once 7 days elapses, set a flag that can only be cleared by unlocking the device, and check that flag in addition to the time.
(2) If there is an internal hardware clock that isn't synced to real time, just count relative to that clock. You don't need to know absolute time to check how long it has been since last unlock.