XPost: misc.phone.mobile.iphone   
   From: mariasophia@comprehension.com   
      
   Those who don't test how iOS works will never understand how it works.   
      
   This describes the tentative full sequence as far as I can figure out on my   
   own as to what happens when a user has no pin, no face id, no fingerprint   
   gimmicks, but is fully signed in to an Apple ID on an iPad and then refuses   
   every Apple ID password prompt thereafter (so as to test how iOS really   
   works).   
      
   1. Initial state   
      The device works normally. The user is signed in to Apple ID. All iCloud   
      services function. App Store updates work. Messages uses iMessage. The   
      device has no local lock because there is no passcode.   
      
   2. First token expiration   
      Apple ID tokens expire on a schedule.   
      When the first major token expires, the system asks for the   
      Apple ID password. The user refuses. The device continues working,   
      but the expired token cannot be renewed.   
      
   3. Service degradation   
      As more tokens expire, iCloud syncing pauses, iMessage falls back   
      to SMS, the App Store refuses updates, and iCloud Keychain disables   
      itself. The device keeps prompting for the password. The user keeps   
      refusing. The device continues to function as a local tablet.   
      
   4. Long term expiration   
      Over months, then years, every Apple ID token on the device ages out.   
      None can be refreshed because the user never enters the password.   
      The device remains signed in, but only in a stale state.   
      Apple servers eventually treat the account session as invalid.   
      
   5. Server side enforcement   
      After roughly two years of continuous refusal, my testing shows   
      that Apple servers stop accepting the stale session entirely.   
      
      When the device checks in after an update or a security event,   
      the servers require full re authentication. The device cannot supply it.   
      
   6. Activation Lock   
      Because the device is still associated with the Apple ID, and   
      because the servers now require authentication before allowing the   
      device to continue, the device enters Activation Lock.   
      
      The screen reports Apple ID disabled.   
      The device cannot finish startup or reach the home screen.   
      Local use does not prevent this because the lock is enforced by   
      Apple servers, not by the device.   
      
   7. Final state   
      The device is effectively unusable until the correct Apple ID   
      password is entered. No amount of daily use, uptime, or local   
      activity avoids this outcome. The only recovery is to enter the   
      Apple ID password online which Apple may refuse due to, I   
      suspect, VPN (but I don't know why Apple online refused it).   
      
   8. At that point, the account is locked semi permanently.   
      You have to visit the Apple store to unlock your own device.   
      And then Apple requires government ID (ask me how I know this).   
      
   Note that this is tentatively how it works.   
   But this doesn't answer the question of WHY it works this way.   
      
   Especially when no other consumer OS works this way (not even macOS).   
      
   The reason iOS behaves this way is that Apple treats iPads and iPhones as   
   cloud managed devices, not as independent computers. The operating system   
   is designed so that the Apple ID is the controlling authority for   
   ownership, activation, and long term authorization. This is different from   
   macOS, which treats the Apple ID as optional and secondary.   
      
   1. Device identity is tied to Apple servers   
      When an iPad is signed in to an Apple ID, the device identity   
      is stored on Apple servers. The device is considered part of the   
      account. Activation Lock is a server side feature, not a local feature.   
      The device must check in with Apple servers to confirm that the account   
      is still valid.   
      
   2. Tokens are the only proof of authorization   
      Apple ID tokens are time limited. They prove that the person using the   
      device authenticated recently. When the tokens expire, the device cannot   
      prove that the current user is still authorized. Apple does not allow   
      indefinite use of stale tokens because that would defeat the purpose of   
      tying the device to the account.   
      
   3. iOS is designed to fail closed, not fail open   
      When the device cannot refresh tokens, Apple does not allow the   
      device to continue as if nothing happened. Instead, the system degrades   
      services, then eventually requires full re authentication.   
      
      If the user refuses, the system does not assume the user is legitimate.   
      It assumes the opposite.   
      
   4. Long term refusal looks like account compromise   
      From Apple servers, a device that refuses authentication for years looks   
      like a stolen device or a hijacked account. The servers eventually stop   
      accepting the stale session. When the device checks in after an update   
   or   
      a security event, the servers demand fresh credentials. If the device   
      cannot supply them, the servers block activation.   
      
   5. Activation Lock is the enforcement mechanism   
      Activation Lock is triggered because the device is still associated with   
      the Apple ID, but the servers no longer accept the stale session. The   
      device cannot complete startup without server approval. This is why the   
      device becomes Activation Locked even though it was never erased or   
      reset.   
      
   6. Why macOS does not behave this way   
      macOS does not tie device activation to Apple ID.   
      Macs can run without any Apple ID at all. Macs do not use Activation   
      Lock as a mandatory part of the startup process. iOS and iPadOS do.   
      This is why the same long term refusal does not brick a Mac.   
      
      iOS devices can run with no Apple ID at all, just like macOS.   
      But the moment you sign in to an Apple ID, the rules change.   
      The iOS device becomes tied to the cloud account, and the cloud account   
      becomes the authority for ownership and activation.   
      
      iOS and iPadOS have Activation Lock built into the startup path.   
      macOS does   
    not. If an iOS device was ever signed in to an Apple ID,   
      Activation Lock   
    can still apply even after signing out.   
      
      A Mac never blocks startup based on   
    Apple ID status.   
      iOS does.   
      
   7. Why other consumer OSes do not behave this way   
      Windows, Linux, and Android do not use server side activation tied to a   
      cloud account in the same way. They do not treat cloud identity as the   
      controlling authority for device ownership. Apple does. This is why the   
      behavior is unique to iOS and iPadOS.   
      
   In summary, the reason this happens is that iOS and iPadOS are designed so   
   that Apple ID is the root of trust for the device. If the user refuses to   
   refresh that trust for long enough, the system eventually locks the device   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)