XPost: misc.phone.mobile.iphone   
   From: mariasophia@comprehension.com   
      
   Chris wrote:   
   > NB: this thread is massively off-topic as this is about your ipads not any   
   > iphone.   
      
   Hi Chris,   
      
   Thanks for taking the time to respond. Since this thread is about how   
   iOS authentication actually works, but I must disagree on whether trying to   
   understand how iOS really works is "massively off-topic" for an iOS ng.   
      
   In my opinion, this thread is massively on topic as it's about how iOS   
   actually works. It's not about what the average user experience is.   
      
   It's about how iOS is designed, and as such, it's massively on topic.   
   Only Apple does this. Nobody else. Just Apple. Keep that in mind Chris.   
    Jan 7/8 2026    
      
   It's critical for people to understand iOS/iPadOS is unique in doing this.   
      
   Once you are already logged in, no mainstream operating system locks the   
   device later simply because you refuse to re-enter your account password.   
    Not Windows.   
    Not macOS.   
    Not Linux.   
    Not Android.   
    Not ChromeOS.   
      
   None of them behave like iOS/iPadOS in this regard.   
      
   In the interest of the goal being to understand how iOS really works, I   
   thank you for not refuting the technical claims I posted as to how iOS   
   works. It seems, to me, perhaps that you're  rejecting my conclusions   
   because you do not understand the architecture.   
      
   If you, or anyone else, has a spare iOS device (I have plenty as I mainly   
   use them for testing how iOS works) you too would find out that the entire   
   cascade Apple documents as inevitable is inevitable if the user refuses   
   authentication for long enough. I have provided many explanations in this   
   thread which describe how the process works, and nobody can refute that.   
      
   Since you haven't tested iOS like I have, I will invest the energy to   
   thoughtfully respond by going through each of your related points in detail   
   so we can see where we agree, where we differ, and where the technical   
   model is being misunderstood.   
      
   > Again none of this changes the fact that only you see this. Everyone,   
   > and I mean everyone, who's responded to this thread doesn't see this   
   > across multiple devices.   
      
   This is an appeal to popularity, not a technical argument.   
      
   The scenario I described requires refusing to authenticate for   
   months or years. I'd doing that to test how iOS really works.   
      
   I agree with all of you, Tyrone included, that almost nobody on this   
   newsgroup tests how iOS works in years'long testing like I do.   
      
   So almost nobody sees the long term failure cascade that I see.   
   Rarity does not disprove the mechanism.   
      
   The test shows how the mechanism works, all the way to Activation Lock.   
      
   > I dare you to post this on Reddit and see how many respond positively.   
      
   Again, that is appealing to popularity, not architecture.   
      
   The token based design does not depend on how many people have seen the   
   test sequence that I've employed as it takes a spare iOS device to test.   
      
   The test results depend only on how Apple implemented authentication.   
      
   >> 1. The system design is deterministic   
   >>    iOS uses a fixed set of authentication tokens with fixed expiration   
   >>    schedules. These schedules do not depend on user opinion. They depend on   
   >>    server side rules. When the user refuses to re authenticate, the same   
   >>    sequence of failures will occur on any device tied to the same Apple ID   
   >>    architecture.   
      
   You did not refute this, Chris, which is good because it's how iOS works.   
      
   You simply opined that others do not see the end state, although Tom Elam,   
   to his credit, saw the beginnings of the final Activation Lock end state.   
      
   He simply provided his password when asked so he never got as far as I did.   
   Which is understandable, as he was using iOS, not testing iOS like I am.   
      
   Tom's experience is consistent with my point that most users re-enter the   
   password (even though they never logged out) usually well before long-lived   
   tokens expire. I am not disputing that most people re-enter the password.   
      
   I do raise my eyes when people claim they don't ever re-enter their   
   password, because if people don't re-authenticate, they will end up in   
   Activation Lock within about two years of refusing to re-enter their   
   password, based on my testing on multiple devices.   
      
   The documentation supports this where my tests record the timeline.   
      
   >> 2. Each service fails independently   
   >>    Apple ID, iCloud, App Store, iMessage, FaceTime, Find My, and iCloud   
   >>    Keychain all maintain separate authentication states.   
   >>    These states expire on predictable schedules. When the user refuses   
   >>    to refresh them, they fail in the same order on every device.   
      
   I break out this section of my prior response as you do not refute this.   
      
   That's good because this is how Apple documents the services, as separate   
   systems with separate authentication.   
      
   To your credit, you did not try to claim any Apple source that says there   
   is a single unified token. You simply asserted that you do not see the   
   failures. That is not a rebuttal of the architecture.   
      
   Your user experience is different than mine because I am testing how iOS   
   really works, and you're just using iOS in normal day-to-day activities.   
      
   >> 3. Token expiration is enforced by Apple servers   
   >>    Token expiration is not random. It is enforced by Apple servers.   
   >>    When a token reaches its lifetime limit, the server rejects it.   
   >>    This behavior is consistent across all devices and all regions.   
      
   Again to your credit, you did not dispute that Apple servers enforce token   
   validity. In fact you indirectly agreed when you said the system cannot   
   bypass its own trust model. That is the same point, which we agree upon.   
      
   It's how iOS is designed to work.   
   The iOS device cannot override server side expiration.   
      
   That's why I ended up having to go to the Apple Store to get the Activation   
   Lock overridden manually (by producing government ID) to prove who I am.   
      
   Only Apple does this Chris. Nobody else. Just Apple. Why?   
      
   >> 4. Activation Lock escalation is rule based   
   >>    Activation Lock escalation is triggered when long lived ownership tokens   
   >>    expire and cannot be refreshed. This is a server side rule. Any device   
   >>    that reaches this state will be classified as unverified.   
   >>   
   >>    Activation Lock documentation:   
   >>        
      
   > Activation lock is an important feature of Apple devices. No mention of   
   > tokens in link noted.   
      
   Correct, the consumer doc does not use the word token. Apple rarely   
   exposes internal mechanisms in user facing docs. The fact that the doc   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)