Facts:

October 1st, 2022: I purchased a Google Pixel 6a, after researching GrapheneOS and then choosing that device. At some point very shortly after that purchase, I installed GrapheneOS "TP1A.220905.004.A2"; probably the "2022092800" iteration:

I set up a lock-screen code that was different than my previous cellular telephone. I set up the "instant lock" so that this code would be required immediately after I press the multi-purpose top button to lock the device.

I disabled all automatic updates that I could identify. It is simply the case that in the industry, the vast majority of software development does not make efforts to keep UI changes separate from security-related changes, so I do sometimes forfeit security in favour of a stable UI. (A case of "beggars trying to be choosers," one could argue.)

All was well until Google decision-makers ruined one of my favourite features in Google Maps, for my GrapheneOS scenario:

September 9th, 2024: After updating to the latest GrapheneOS and finding that (predictably) the UI had changed and that there was no Maps improvement, I reverted to "TP1A.220905.004.A2". At that time, I probably chose the same lock-screen code as before, but perhaps I chose a different one.

It seems that the GrapheneOS feature for installing Google-related features was no longer supported by GrapheneOS infrastructure, by this point, for this older version of GrapheneOS. I was forced to seek a "less reputable" source for the Google-related features. After reviewing many of them, I found a source which seemed to be the least offensive to my distrust and I installed it. All seemed well.

At some point in November or December, YouTube UI changes and the broken Maps feature yielded enough frustration that I disabled all Google apps and features that I could identify, including the Play Services and another related "background" app. After that, all was well...

March 19th, 2025: I unlocked my phone many times, but at some point in the afternoon, I tried to unlock my phone and my code was not accepted. I tried several times, then rebooted the phone. I have tried many times, since then, but without success. I believe the last note I saw reported that I've tried 192 times.

After reaching 9XX seconds for the retry-timer that appears after a failure, very rarely I see that the retry-timer indicates a very low number that I'd seen when my count of attempts was much lower, such as 120 seconds. Most of the time, the number that appears is 9XX seconds. If I then reboot the phone and try to enter a code, it seems that the retry-timer that appears is something like a continuation of the time remaining from the previous attempt: sometimes in the 8XX range.

Sometimes I see that the final digit of the retry-timer appears to switch back and forth a couple of times very quickly, as it counts down. For example, "3 2 3 2, 2 1 2 1, 1 0 1 0, 0 9 0 9, 9 8 9 8," etc. This isn't consistently observable, however; apparently random. This could be a simple UI flaw, although I can't quite imagine how that flawed logic might be.

Imagined possibilities for what has happened:

Perhaps because I use an older GrapheneOS, a specially-crafted image at a popular "free online sound meter" web-page (visited shortly before the problem) introduced bad software onto my phone and changed the lock-code software so that the phone accepts no code and logs all codes that I try and submits those codes to a malicious collector of codes. I've seen at least 2 other discussions in which a person having a comparable experience shares that "after a [few hours / few days], the code was suddenly accepted!" If the "bad software" includes such a timer and then releases the phone back to the relieved owner, then it seems likely to be imagined to be an owner error, all along, but having collected code-attempts from that owner.

Perhaps because I unlocked another phone (having a different code) shortly before the problem, this scrambled up my memory of my usual code, but somehow this scrambling-up persists beyond 72 different codes that I've tried. (All of them "phone muscle-memory bells ringing" and not PIN codes for anything else I might have PIN codes for.) I've unlocked both phones multiple times within the same day before without becoming scrambled up, however.

Perhaps a blood-vessel in my brain broke and neurons responsible for the "muscle-memory" of unlocking my phone were destroyed.

Perhaps GrapheneOS decision-makers became aware of a security-concern so severe that they issued an unconditional software update through an emergency band, but this has broken my code-entry process.

Perhaps one or more cosmic rays reached the innards of the Titan M2 chip and ruined the bits of certain keys, so even if my unlock code is correct, it'll never work.

Thoughts about this ordeal, so far:

Write down your unlock-code. (Some readers might respond, "Well, duh," but some readers might respond, "Oh, I'm going to do that, right now.") Maybe not literally, in case you're worried about an unauthorized person obtaining it from a search of your papers, but maybe in a password management system that isn't on your phone, or with a trusted party, or requiring multiple trusted parties to reveal it. Having certainty about the correct code permits this bisection of the problem-space:

  • Yes, I know the code is correct, so the problem is that the phone is broken or hacked.
  • No, I don't know the code is correct, so I could be the problem, or the phone could be broken or hacked.

All of this modern security is a double-edged sword: it's great at keeping people out of your data. Sometimes you are one of those people.

The Google Pixel 6a does not appear to support booting an alternative kernel. Normally in a case of potentially catastrophic data-loss, I'd take a DD copy of the storage block-device and deal with it later. For example, with other, older phones, I could boot TWRP, make a DD copy, install a new operating system on the phone (erasing data), then if the new OS seems unsuitable, I could once again use DD to restore the phone to the previous state, with all data intact. Not only does the Pixel 6a not appear to support 'fastboot boot <kernel>', but TWRP doesn't support the Pixel 6a, anyway. Having no DD, I can have no "snapshots" of known-good states, for this phone. Not only that, but the fancy chips (like Titan M2) imply that storage-keys might not even be stored on the disk: having the disk is not enough to represent the state of the device.

During the October Maps ordeal, because I could not use DD, I used SeedVault to try to back up my data, before I upgraded the GrapheneOS version. Since I do not have 2 Pixel 6a devices, I was unable to fully test a restoration and I had to cross my fingers. I was disappointed by the results: most of the apps (including Google apps) did not correctly restore to an installed state. Some apps were restored, but their data wasn't restored. The content of a SeedVault backup is not at all easy to work with from a computer: an unofficial extraction-tool exists, but one doesn't get a directory of files as they appeared in the FS on the phone. I would score SeedVault at a notch above useless, since I believe it did restore some pictures. For contrast, when I restore a DD backup of an old phone to that phone, that phone is as it was on the day I took the backup. Fortunately, at least one popular, privacy-oriented messaging app has decent backup and restore features, although not for their computer-based variant. I was also surprised to learn that Vanadium history isn't something that can be backed up nor restored, by design.

Back up your data at least once per week. Also during that October ordeal, I decided to back up my data more frequently than I had been. That frequency wasn't great enough, since I now have no access to recent data that I wish I had access to.

Maybe the "unlock timer" UI isn't representing whatever timing representations the "Titan M2" is keeping track of, so maybe many some of my attempts have failed because the UI did not indicate a distinction between "retry-timer is still in effect" versus "the attempt has been tried and rejected by Titan M2."

I've read about the retry-timer, here:

It's not clear to me why the UI isn't indicating "Retry in 1 day" to me, after my 192 attempts, but is indicating 9XX seconds, at the most. Either I've misunderstood something or that article isn't applicable to my device or the UI isn't accurate or the phone has been hacked and the code-entry is malicious software. Assuming that there is a flaw with the UI which is misleading me, I will ensure that I wait a full 24 hours, in-between my next attempts.

Despite 2 nights of sleep so far, I haven't woken up with the unlock-code muscle-memory suddenly restored with great certainty. Assuming that I've forgotten for now, maybe it'll come to me some day in the future, but it seems that if I want to preserve this data, I'll have to set this phone aside and use another phone, for productivity. I must have unlocked this phone at least 40 times per day since I bought it, so it's very surprising to suddenly "lose" this.

Maybe if I had "fingerprint unlock," I'd have some alternative. Why would anyone ever want to submit their fingerprint to any software that they hadn't written themselves, though, or lack imagination regarding finger-choppers breaking down the door?

I appreciate many features of GrapheneOS.

Here is another, similar discussion:

    sha0

    I disabled all automatic updates that I could identify. It is simply the case that in the industry, the vast majority of software development does not make efforts to keep UI changes separate from security-related changes, so I do sometimes forfeit security in favour of a stable UI. (A case of "beggars trying to be choosers," one could argue.)

    You chose to have a device missing essential privacy, security and other patches. We cannot provide support for people on multiple year old OS releases.

    It seems that the GrapheneOS feature for installing Google-related features was no longer supported by GrapheneOS infrastructure, by this point, for this older version of GrapheneOS. I was forced to seek a "less reputable" source for the Google-related features. After reviewing many of them, I found a source which seemed to be the least offensive to my distrust and I installed it. All seemed well.

    Not something compatible with requesting support either. You're using some weird third party sourced Google Play apps on an old GrapheneOS version. Google doesn't support using their services without updating the apps.

    March 19th, 2025: I unlocked my phone many times, but at some point in the afternoon, I tried to unlock my phone and my code was not accepted. I tried several times, then rebooted the phone. I have tried many times, since then, but without success. I believe the last note I saw reported that I've tried 192 times.

    Sounds like you did something unintended as part of disabling the apps like disabling an OS component required for the OS to function. No way for us to know what you did.

    Sometimes I see that the final digit of the retry-timer appears to switch back and forth a couple of times very quickly, as it counts down. For example, "3 2 3 2, 2 1 2 1, 1 0 1 0, 0 9 0 9, 9 8 9 8," etc. This isn't consistently observable, however; apparently random. This could be a simple UI flaw, although I can't quite imagine how that flawed logic might be.

    You're on some multiple year old OS release. We don't need reports of old Android UI issues.

    Perhaps because I use an older GrapheneOS, a specially-crafted image at a popular "free online sound meter" web-page (visited shortly before the problem) introduced bad software onto my phone and changed the lock-code software so that the phone accepts no code and logs all codes that I try and submits those codes to a malicious collector of codes. I've seen at least 2 other discussions in which a person having a comparable experience shares that "after a [few hours / few days], the code was suddenly accepted!" If the "bad software" includes such a timer and then releases the phone back to the relieved owner, then it seems likely to be imagined to be an owner error, all along, but having collected code-attempts from that owner.

    Highly unlikely.

    Perhaps because I unlocked another phone (having a different code) shortly before the problem, this scrambled up my memory of my usual code, but somehow this scrambling-up persists beyond 72 different codes that I've tried. (All of them "phone muscle-memory bells ringing" and not PIN codes for anything else I might have PIN codes for.) I've unlocked both phones multiple times within the same day before without becoming scrambled up, however.

    That's possible. People often forget their PIN right after recently changing it or after not using the phone for a long time if either of those is relevant. Sometimes people don't recall changing it if they did it while very tired or otherwise impaired such as alcohol or other drugs.

    Perhaps GrapheneOS decision-makers became aware of a security-concern so severe that they issued an unconditional software update through an emergency band, but this has broken my code-entry process.

    There's no such thing.

    Perhaps one or more cosmic rays reached the innards of the Titan M2 chip and ruined the bits of certain keys, so even if my unlock code is correct, it'll never work.

    It would not boot anymore but rather would show the corruption screen asking you to wipe. It's near impossible for this concept to have happened.

    All of this modern security is a double-edged sword: it's great at keeping people out of your data. Sometimes you are one of those people.

    There's backup support, which works far better in the current GrapheneOS releases you refuse to use.

    The Google Pixel 6a does not appear to support booting an alternative kernel. Normally in a case of potentially catastrophic data-loss, I'd take a DD copy of the storage block-device and deal with it later. For example, with other, older phones, I could boot TWRP, make a DD copy, install a new operating system on the phone (erasing data), then if the new OS seems unsuitable, I could once again use DD to restore the phone to the previous state, with all data intact. Not only does the Pixel 6a not appear to support 'fastboot boot <kernel>', but TWRP doesn't support the Pixel 6a, anyway. Having no DD, I can have no "snapshots" of known-good states, for this phone. Not only that, but the fancy chips (like Titan M2) imply that storage-keys might not even be stored on the disk: having the disk is not enough to represent the state of the device.

    No, you're just used to having an insecure OS without the standard security model, unlocked device, a third party recovery image, no verified boot, non-working disk encryption which doesn't actually work without using a long passphrase, etc.

    During the October Maps ordeal, because I could not use DD, I used SeedVault to try to back up my data, before I upgraded the GrapheneOS version. Since I do not have 2 Pixel 6a devices, I was unable to fully test a restoration and I had to cross my fingers. I was disappointed by the results: most of the apps (including Google apps) did not correctly restore to an installed state. Some apps were restored, but their data wasn't restored. The content of a SeedVault backup is not at all easy to work with from a computer: an unofficial extraction-tool exists, but one doesn't get a directory of files as they appeared in the FS on the phone. I would score SeedVault at a notch above useless, since I believe it did restore some pictures. For contrast, when I restore a DD backup of an old phone to that phone, that phone is as it was on the day I took the backup. Fortunately, at least one popular, privacy-oriented messaging app has decent backup and restore features, although not for their computer-based variant. I was also surprised to learn that Vanadium history isn't something that can be backed up nor restored, by design.

    You're using an old OS release from before Seedvault worked far better than it did back then. What do you expect? You're choosing not to use most of the OS improvements but are complaining about what you're not using. GrapheneOS is dramatically better today than in 2022. If you want to use GrapheneOS from 2022, you are not having an experience which applies to people who use the current OS.

    Maybe the "unlock timer" UI isn't representing whatever timing representations the "Titan M2" is keeping track of, so maybe many some of my attempts have failed because the UI did not indicate a distinction between "retry-timer is still in effect" versus "the attempt has been tried and rejected by Titan M2."

    No, it is a UI showing the timer from the secure element as reported by it to the OS.

    Maybe if I had "fingerprint unlock," I'd have some alternative. Why would anyone ever want to submit their fingerprint to any software that they hadn't written themselves, though, or lack imagination regarding finger-choppers breaking down the door?

    You leave your fingerprints on everything you touch including the phone. It is not much of a secret. It is also not available to the software, just the secure element which does not store it but rather makes a fuzzy hash model it updates with each usage to gradually adapt to fingerprints changing over time along with covering a wider area of the finger. It is a secondary unlock mechanism for After First Unlock state, within 48 hours of last primary unlock and with 5 attempts total (20 for stock OS). It can be used with our 2-factor unlock feature with a random 4 digit PIN (failure to enter the PIN counts towards the fingerprint unlock attempt limit).

    I appreciate many features of GrapheneOS.

    Yet you don't actually use current GrapheneOS, you use some old version and some of your complaints are things which got massively improved over time. It is far better now than it used to be and we aren't really interested in hearing how an OS release from years ago isn't up to your standards yet you won't use the current GrapheneOS.

    If you want to ask for help and give feedback here, you can use current GrapheneOS.

      Thank you for your response, GrapheneOS.

      I must admit that given that my 2 other forum discussions have just been locked, perhaps what I've typed has offended one or more GrapheneOS folks. What can I type and/or do to try to repair the relationship? The "obvious" answer is "use the latest GrapheneOS," it seems, but that has challenges, which I'll explain later on.

      In one of the now-locked topics, I was simply asking a question, then shared a self-answer, which someone else in the community liked, then a response from today seems to be that if I don't use the latest GrapheneOS version, I should not participate in the forum.

      In another of the now-locked topics, I explained that I had indeed updated my GrapheneOS version to the latest one available for my device, which then involved obtaining the Google features via that latest GrapheneOS' Google-fetching features, but that Google Maps' Timeline feature still didn't work. Perhaps that was somehow unclear from my message.

      Later in that same topic, I'm accused of going on an ignorant rant and attacking GrapheneOS and software developers without understanding how it works. Perhaps that response might be viewed in a different light, given the clarification of my previous paragraph, just above. I don't think that's a fair characterization.

      I haven't intended to "attack" anyone. I'm unsure if some of the imagined possibilities I shared in the top message from today might have been offensive, but they weren't meant to be. I'm sure that many GrapheneOS users are distrustful of other parties: that's probably why they appreciate the efforts, time, and money spent by GrapheneOS folks towards extra privacy and security. The imaginary scenarios were intended to be aligned with other scenarios that I've read in other discussions. They weren't accusations, which is why I used the word "imagined." I appreciate your kind response ("no such thing") to one of them, which provides clarity for the community and for the curious.

      I am a software developer, since roughly 1991. I am also a person who has major struggles with UI changes. I'm sure that there are many reasons for why much software these days mashes UI changes with security changes, but that causes me no end of grief. Please forgive me for occasionally voicing this concern to other software developers, at relevant times. Some day, maybe they'll be received well. I'd be delighted to enjoy the latest fruits of GrapheneOS, relative to security. Unfortunately, these do not appear to come separately from UI changes. (As an example, the unlock-code entry-dots are circles on my old GrapheneOS, but changed to pointy shapes in the latest Pixel 6a GrapheneOS in October.)

      In response to "third party sourced Google Play apps": I've tried to clarify the situation, above: I did try the latest GrapheneOS and thus the latest Google Play software, in October. It didn't help Maps, so I reverted GrapheneOS.

      I shared the timeline in today's first message. I disabled all Google items in either November or December. I do not perceive a relationship between that activity and my sudden grief 2 days ago, unless there was a ticking time-bomb or an exploit caused by those disabled apps.

      I thought someone in the community here might respond with something like, "Ah yes, the old PIN screen with the weird count-down numbers. This is a known malware by celebrated hacker-group X and you've surely fallen victim to it, doubtless due to your old GrapheneOS version," or with something like, "Ah yes, looking carefully, I see that this fluctuating count-down timer is still the case, today. Neat! What a minor UI quirk, though." I'm sorry if this was perceived as a gripe about GrapheneOS: it wasn't.

      In response to "Highly unlikely", as you doubtless known image-processing vulnerabilities come along, from time to time, and not even all that long ago. CVE-2023-41064 is a recent example for a different platform:

      So that imagined scenario was just a whimsical example. These imagined scenarios were just that: imagined and not projected as reality, nor accusatory of GrapheneOS incompetence.

      In response to "used to having an insecure OS," what I'm used to is laptop and desktop and data-centre computers: having trust-keys on a chip, adjusted through a password-protected interface, where those keys are used to verify boot pay-loads, which then boot an OS which requests another password for LUKS-protected data. This is a clean separation between the data and the machine and so yes, the data can be placed into any other machine and accessed, if the data-password is known. If the "standard security model" (in the context of GrapheneOS and/or Android) is that the device should be a single point of failure for the accessibility of the data, then yes, I guess I'm not used to that.

      Given some of the responses, it seems that I jumped into GrapheneOS too early: that is, I got used to the UI before backup/restore features were ironed out and now that they have been, I can't access those features without also confronting all the UI changes that will have come along for the ride.

      Why are Androids and cellular telephones appearing to depart further and further from the laptop and desktop computer ecosystem, despite these former devices also being computers? I want my data to be conveniently accessible in a non-Android Linux. SeedVault only appears to have unofficial relatives for plain Linux. Why doesn't it produce a .tar.gz.gpg file, or some other format that standard Linux tools can manipulate with ease? Why does it require an already distrustful user to download unofficial software, in order to get at their precious data? Please note that I'm not actually asking this paragraph's questions with the hope of a response to them: they probably belong in a different topic after I am positioned to satisfy the "I'm using the latest GrapheneOS" condition. What I'm trying to do is to share context about the harsh score that I gave to SeedVault. I'm sure that SeedVault developers worked and continue to work very hard, and that their efforts are enjoyed by many or even most users. That's admirable. I wish it had worked well for my goals in its 2022 iteration.

      About the secure element's retry-timer, after waiting more than 24 hours since my last attempt and trying again, the count of failed attempts has changed from 192 to 162 and the count-down message indicated that I ought to try again in "653 seconds." I took a picture. After waiting for that count-down to complete and after trying again, the message again noted "162 times" and to try again after 9XX seconds, but I didn't catch it with a picture. If it's true that the UI is reporting what the secure element reports, then perhaps this discrepancy can be explained by malware or perhaps it can be explained as unworthy of any attention because it's from a 2022 GrapheneOS version. I was expecting to be hindered by 1 attempt per day. Surely all of the newer GrapheneOS users having more than 140 attempts will be hindered at such a rate with clarity about that rate.

      In an effort to foster a shared understanding of the recent responses to my attempts for discussion, would this be a fair notice for someone considering using GrapheneOS?:

      Please note that it should be clear that GrapheneOS project participants (such as developers) have a focus on security and privacy, above all else; we're quite good at it and we certainly strive for it. Without infinite resources available to the project, the fact of the matter is that some considerations rank less than others, in priority. It's also unlikely that everyone can be satisfied by any project, so we make decisions about trade-offs and attention using our best judgment, which should go without saying.

      For example, it's convenient for us to make releases in which security enhancements, privacy enhancements, feature enhancements, and user interface changes are all bundled together. The alternative strategy to release these subjects separately would be extremely cumbersome and complicated; you wouldn't enjoy it and we wouldn't enjoy it. We're always hoping to work for your best interests.

      With this strategy, we expect, for example, that a tiny majority of GrapheneOS users might object to a seemingly trivial UI change, but still benefit from the overwhelming majority of the rest of the release. Some of our decisions are informed by considering the majority of users, as opposed to a tiny minority. Some UI changes are inherited by other parts of the Android ecosystem; outside of GrapheneOS efforts. If you are a person who suffers greatly from UI changes, GrapheneOS might not be the best choice for you. We know that some elderly folks and some folks having disabilities and even some other folks might be in such a situation. (You are unlikely to find a better alternative, though, elsewhere!)

      Also, please keep in mind that sometimes updates don't always work as planned. Sometimes a bug might strike in even the largest crowd of software users. This possibility for GrapheneOS updates is no different than for any other software updates, although we don't find it likely.

      If you do not keep up to date with GrapheneOS, not only do you expose yourself to historical risks that we address in our updates, but we're not interested in diverting resources to attend to the fall-out from your out-dated position. GrapheneOS participants want to maximize value.

      NOTE: The above is not a quotation from any GrapheneOS project participant. It is imagined by me as the type of notice that might be fair to share with people who are interested in GrapheneOS.

      Please try to read what I type with openness to charitable interpretations. I might not be an expert at writing frankly and leading to positive interpretations, such as light-hearted responses. I always hope for those, however. I apologize if what I typed included not-well-received criticism.

        sha0 Why are Androids and cellular telephones appearing to depart further and further from the laptop and desktop computer ecosystem, despite these former devices also being computers?

        The short answer is that "desktop" hardware and software security are far behind mobile-device security. The infrastructure is lacking, and what exists is riddled with serious bugs. Here is just one example: "Secure Boot is completely broken on 200+ models from 5 big device makers". At present arguably the best "desktop" device+OS security comes from Apple.

        Mobile-device operating systems do have issues, but expecting them to lower their security to match desktops is not a goal that will be widely shared by device manufacturers.

            sha0 Dude this is madness nobody can realistically support your old 2022 build. It's like going to Sony about a crt TV you bought decades ago and expecting them to fix it. In this case the answer is simple go to the latest Graphine version then ask the question or flash back to stock pixels os which at this point will be more secure and better for you than what your using

              sha0 I think you might have a misunderstanding of what GrapheneOS (or any mobile device) releases offer, hence the reason your posts aren't being entertained the way you'd like them to be. Any outdated device, especially by 3 years, will not only be missing out on security improvements but also bug fixes and it will eventually cause incompatibilities with apps. Considering this, it's not possible for anyone to cater to your device other than advising you to update the OS.

              sha0 Given some of the responses, it seems that I jumped into GrapheneOS too early

              I don't fully agree. There are many (including elderly) users who don't know all the ins and outs of GrapheneOS and don't have the issues you faced as they use their device OS as intended. While the user is indeed free to use their device any way they want, disabling updates and being on a highly outdated release is on part of the user and they bear any responsibility of issues.

              sha0 I am also a person who has major struggles with UI changes. I'm sure that there are many reasons for why much software these days mashes UI changes with security changes, but that causes me no end of grief.

              That's understandable.

              Personally, I feel that GrapheneOS has one of the most stable UIs considering it's based on AOSP and not Google or any vendor's additions to the UI (those tend to change their UIs far more often). So I think it's fair to adapt to minor UI changes every now and then on an otherwise stable UI. It beats the struggle of issues created by not keeping the device up-to-date in my opinion.

              sha0 Please try to read what I type with openness to charitable interpretations. I might not be an expert at writing frankly and leading to positive interpretations, such as light-hearted responses. I always hope for those, however. I apologize if what I typed included not-well-received criticism.

              If you're referring to some earlier responses, keep in mind that not everyone on the forum speaks English as their first language (myself included) and there is a chance of misunderstandings due to word choice, etc. Personally, I try to overlook these things for the sake of maintaining diplomacy in the forum.

                      Cam: Where is my request for support, please?

                      yore: Thank you for your kind response.

                      In October, I took a SeedVault backup of my 2022-09 GrapheneOS, then updated GrapheneOS to the latest version, then attempted to restore that SeedVault backup. I've shared my disappointment about the results. My conclusion from this is that I started using GrapheneOS before its SeedVault backup was mature. ("Too early.") I also conclude from this that a "path" which might have "worked" would have been to have been updating, all along. If that path would have worked, I would conclude that GrapheneOS developers (along with many others) assume that this is the only legitimate path for everyone, but I'm personally aware of counter-examples and challenges to "always keeping all software up to date," including professionally. If only I had a nickel for every "2 steps forward, 1 step backward" update I've encountered, I'd be delighted.

                      I've seen the trend of "backwards compatibility is not important or too difficult; just keep updating" increase over the years. From my perspective, that attitude is conducive to planned obsolescence. I do not appreciate planned obsolescence. I recognize that there are economic incentives for planned obsolescence. I'm often challenged by those incentives.

                      My expectation for a well-designed OS is that with the exception of vulnerabilities (which are not relevant for a device which is not communicating with the rest of the world), once the OS and non-Internet-dependent apps are installed, what works at that point will work forever. (Until the hardware degrades or the electricity system changes.) Concern about incompatibility is not relevant for someone who does not update anything and who does not depend upon an external party, such as a party on the Internet. I'm not claiming to be in this position, but this is my expectation for good design.

                      [...] as they use their device OS as intended. [...]

                      It seems so automatic an assumption that "as intended" includes "keeping up to date." This wasn't always true.

                      I do not recall asking any developer to cater to my choices, in this topic. I tried to share a useful story involving GrapheneOS from my "user" perspective. I'm hopeful for compassion from developers with respect to some of the challenges. We often incorporate ramps for people who use wheelchairs, these days; seems like societal progress. Not all challenges are quite as obvious.

                        probably too off topic for the thread, but as someone whos posted a similar rant in the psvita subreddit before (where the only possible way of doing a thing really strongly clashed with my obsessiveness about doing something a certain way), i totally sympathize, its really tough. luckily what i was dealing with was an optional storage expansion and not what is basically unavoidable in the long term, upgrading your software

                        • sha0 replied to this.

                          sha0 In October, I took a SeedVault backup of my 2022-09 GrapheneOS […] then attempted to restore that SeedVault backup. I've shared my disappointment about the results. My conclusion from this is that I started using GrapheneOS before its SeedVault backup was mature.

                          Seedvault isn't considered very reliable and has its own issues (i.e. restored apps cannot be updated as the install source doesn't match the updating source). The project did say they plan to replace it with a better backup system in the future.

                          sha0 once the OS and non-Internet-dependent apps are installed, what works at that point will work forever. (Until the hardware degrades or the electricity system changes.)

                          If it's an airgapped device, or one where security is not a priority, everything should work as the system would be "frozen in time." That is, if the app itself isn't reliant on a service over the internet like Google Maps to fetch data. If you have been updating apps but not the OS then incompatibilities will show up at some point.

                          But there's really no way an airgapped app would stop working only due to having an out-of-date OS.

                          My guess is whatever went wrong is either a result of an incredibly rare bug or human error. You can decide which one is more likely but I'm more inclined towards the latter.

                              sha0 From my perspective, that attitude is conducive to planned obsolescence.

                              It seems you have very twisted views on planned obsolescence.
                              Not being able to update your software is planned obsolescence.
                              Buying a $1000 flagship phone and receiving 2 years of updates is planned obsolescence.
                              Getting free software updates with security fixes and feature improvements is none of that.

                              It seems so automatic an assumption that "as intended" includes "keeping up to date." This wasn't always true.

                              It was always true; you just never knew or cared about it. I personally avoided updating some software I used as well, but I accepted the inherent risks that would come with doing so. It also was never for operating systems, I keep these up to date no matter what.

                                  sha0 It seems so automatic an assumption that "as intended" includes "keeping up to date." This wasn't always true.

                                  Originally there were no automobiles. Then there were no automobiles with software. Then there were no automobiles with upgradeable software. Then some automobiles got software upgrades in shops. Now some automobiles get software updates via wireless networks.

                                  Originally there were no airplanes. Then there were no airplanes with software. Then there were no airplanes with upgradeable software. Then some airplanes got software upgrades in shops. Now perhaps some airplanes get software updates via wireless networks? If not, maybe soon.

                                  These days software upgrades are a part of the picture for many pieces of technology. Perhaps someday that will settle down, or perhaps not. But at present software upgrades are common for phones.

                                      [...] you just never knew or cared about it. [...]

                                      n3t_admin: Please refrain from making claims about someone else's inner state because you do not have access to it. I'm not aware of us being engaged in a formal debate, but avoiding discussing the innards of other people as a habit seems conducive to avoiding falling into:

                                      [...] Getting free software updates with security fixes and feature improvements is [not planned obsolescence]. [...]

                                      Please follow the plot. I didn't claim any relationship between GrapheneOS and planned obsolescence. If you perceived such a claim and that is why you consider me to have "twisted views," then I'll suggest that you might be engaging with a:

                                      Having typed that, please consider these 2 scenarios:

                                      I plugged in a light-bulb, I turned on the light-switch, the light-bulb lit up.
                                      [...50 years later...]
                                      I plugged in the same light-bulb, I turned on the light-switch, the light-bulb lit up.

                                      versus:

                                      I plugged in a light-bulb, I turned on the light-switch, the light-bulb lit up.
                                      [...50 years later...]
                                      I plugged in the same light-bulb, I turned on the light-switch, the light-bulb did not light up.

                                      Now please consider this real scenario:

                                      October, 2022: I installed GrapheneOS, I used the Google-fetching feature to fetch Google features.
                                      October, 2024: I installed the same GrapheneOS, I tried to use the same Google-fetching feature to fetch Google features, but I was unable to fetch those Google features.

                                      Now please consider these possible, imaginary, mutually exclusive explanations:

                                      The GrapheneOS service that responded to 2022 requests was found to have bugs, or to have security problems, or was found to be too expensive to maintain, or the original developers were no longer available, or it was found to have other shortcomings, so an alternative service was set up. The new service requires a newer GrapheneOS, which everyone should be using because it is granted that 2 years is "ancient history" in the fast-moving, fluid world of cellular telephones.

                                      versus:

                                      The GrapheneOS service that responded to 2022 requests could have been maintained. A better GrapheneOS service was developed and it could have continued to support the older GrapheneOS requests. Supporting older requests is conducive to people not updating, which is deemed to be against their own interests, so support for those old requests was intentionally removed in order to incentivize updating. It is granted that 2 years is "ancient history" in the fast-moving, fluid world of cellular telephones.

                                      I'm not claiming that these 2 explanations exhaust the space of possible explanations. I'm not claiming that one of these must reflect reality.

                                      Please consider this alternative, imaginary scenario:

                                      October, 2022: I installed GrapheneOS, I used the Google-fetching feature to fetch Google features.
                                      October, 2024: I installed the same GrapheneOS, I used the same Google-fetching feature to fetch Google features.

                                      This is superficially similar to the 50-year light-bulb. The explanations above anticipate an argument about differences and are intended to demonstrate agreement that "there are differences from a light-bulb." I also know that a GrapheneOS release is not expected to include Google features.

                                      Here are some more examples:

                                      2003: I install an OS from a CD, I install some word processing software from a CD, I can make documents.
                                      2025: I have a virtual machine. Inside, I install the same OS from its CD, I install the same word processing software from its CD, I can make documents. Because processors (etc.) are faster than in 2003, my experience of making documents is blazingly fast.

                                      versus:

                                      202X: I buy a computer that has an OS. I buy a license for word processing software. I can make documents. I always keep everything up to date, as far as patches go.
                                      2025: I can mysteriously no longer make documents. I could, yesterday. My word processing software indicates that a newer version of the word processing software is recommended. It will require purchasing a newer license. I examine the system requirements for that newer word processor version. It indicates that I will need to purchase a newer OS. I examine the system requirements for that newer OS. It indicates that I will need to purchase a newer computer. I call a trusted party who explains to me that it's possible to use alternatives which avoid "the sales funnel" and "the subscription model of consumption."

                                      (I'm not personally the victim of that most recent example.)

                                      I've already shared about the old cellular telephone and the DD strategy and how great it is.

                                      de0u: It's not clear to me why the "Secure Boot" example you've shared is any less applicable for mobile devices. If the Google Pixel 6a secure element's firmware's key is published online, then someone skilled in the art can sign a malicious variant of the firmware and it can eventually reach the secure element. Have I misunderstood some fundamental difference? "But a user has to approve the firmware upgrade!" Yes, and "a user" had to expose one of those "Secure Boot" computers to the root-kit, unless it arrived by wind-current. Is this an argument for "security through obscurity?" Something like, "most people use such-and-such OS, so most hackers target that OS, so most hacks are found for that OS, so that OS is less secure than another OS."

                                      How about this?: You adjust your equipment to trust your own keys and you avoid "supply-chain" failures, such as that "Secure Boot" example.

                                      For example, a firmware developer publishes their source-code. You scrutinize it. You trust it. You adjust it to trust payloads signed by your own key. You compile it. You use the existing firmware to authorize the installation of your firmware. A boot payload developer publishes their source-code. You scrutinize it. You trust it. You compile it. You sign it with your own key. One day, an exploit is found. You're paying attention to exploits, so you become aware of it. You decide this exploit is worthy of attention. You apply a patch.

                                      [...] expecting them to lower their security to match desktops [...]

                                      You might be arguing against one of these:

                                      I might not have been clear, earlier. My hope is to avoid a single point of failure, in data-accessibility scenarios. One way to achieve this is to have multiple copies of the data. I'm not currently aware of any cellular telephone software (other than DD, in yesteryears) which can take all data and securely synchronize it to another location, such that it can be accessed without the original and restored to a counterpart of the original. This has been possible with laptop and desktop and data-centre computers for a very long time, and it was possible with older cellular telephones.

                                      Perhaps our disagreement is fundamentally about what "good security" means: if "good security" includes "I'd rather lose all my data during an incident than ever regain access to it," then that's not matched with my cellular telephone needs, in which "good security" includes that "I have different security-levels for different data. For some of those levels, it doesn't matter where my data is physically located, as long as I can access it, and nobody can access it without knowing what's in my mind." These are still both compatible with other security-concerns, such as "I don't want anyone to suspect that I have private data" and "I don't want to give any clues about my data's content" and "I want to blend in with everyone else" and even "I want a particular single point of failure for particular data, such that during an incident, I can forfeit that data, forever." I have lost family pictures during this ordeal; not state secrets. It's my fault for not backing up more frequently.

                                      Maybe a "Venn Diagram" (in text form 😅) would help: if "Owner" profile has family pictures, if "SuperSecret" profile has state secrets, then when "Owner" profile access is lost, both family pictures and state secrets are lost. If only "SuperSecret" profile access is lost, then family pictures are preserved and state secrets are lost.

                                      de0u: Please imagine this scenario:

                                      Monday: You are driving an automobile. When you signal to make a turn, the signal flashes at an interval of twice per second.
                                      The automobile manufacturer had a focus-group study. In that focus-group study, psychological studies showed that participants were happier about a once-per-second signal-flashing rate.
                                      An automobile association report also showed that higher-frequency signal-flashing rates were involved in more automobile collisions than lower-frequency signal-flashing rates.
                                      Given the results of both the study and the report, the automobile manufacturer decided that it's in the best interests of society and for that automobile manufacturer's consumers to reduce the frequency of the signal-flashing rate. The manufacturer sent out the adjustment in a software update.
                                      Tuesday: You are driving the same automobile. It has received a software update. When you signal to make a turn, the signal flashes at a rate of once per second. Concerned, you take time off work and visit a mechanic. The mechanic charges you $50 for a diagnosis. Mystified, the mechanic then searches the Internet for the symptom, just as you could have done. The mechanic's explanation is that the automobile most likely received a software update.
                                      You have gained: a day of worry and a lesson learned. You have lost: time from work and $50. The automobile no longer behaves the same way as the day you test-drove it, prior to its purchase. The automobile has become "fluid" and appears to require that you adapt to changes from its manufacturer, after its purchase. If you do not enjoy those changes, you can purchase another automobile and no automobile manufacturer will complain about that activity. In fact, since all automobile manufacturers issue software updates, you will most likely need to adapt to any automobile manufacturer's lively changes. If you opt to purchase an ancient automobile that has no software updates, a day eventually arrives that mechanics indicate that they haven't learned how to diagnose old automobiles like that and they have come to rely upon software for diagnosis; that you should buy a new automobile; that doing so is also safer and better for everyone.
                                      Wednesday: You complain about the state of automobiles and software updates.
                                      Friday: You are driving an automobile. The automobile receives a software update. The automobile is involved in an accident. You are unable to express further complaints about the state of automobiles and software updates.

                                      Hooray for imagination.

                                              sha0 The crux of your device's issue is that you are not maintaining your system. Almost all modern apps are maintained with the assumption that the system isn't too out-of-date.

                                              That being said,

                                              sha0
                                              October, 2022: I installed GrapheneOS, I used the Google-fetching feature to fetch Google features.
                                              October, 2024: I installed the same GrapheneOS, I tried to use the same Google-fetching feature to fetch Google features, but I was unable to fetch those Google features.

                                              I will say this one more time: if the app relies on a service over the internet, then things will eventually break if neither the app nor the OS is maintained as they will fall behind while the service the app relies on will evolve over time. There is no way around this other than keeping things updated.

                                              The same analogy could be made for desktop systems. Let's say you choose to leave your browser at the version it's currently at and avoid updating it at all. After a number of years go by, would things still work as expected? If you had a Windows 98 system and continued to use it to this day, would most websites still work?

                                              You're free to avoid all updates but expect things to break with such apps.

                                              That's all I can help you with I'm afraid.

                                              I'm out.

                                                    Lucario1829: Thank you for your sympathy. I hope the 2 recommendations are useful to readers:

                                                    1. Write down your PIN, in order to bisect between a "you problem" and an "it problem."
                                                    2. Back up your data frequently.

                                                      yore: How did you know my computer's OS?! 🔮🤯 (Just kidding.)

                                                      I respect your conversation-related decision. Good fortune to you!

                                                        sha0 It's not clear to me why the "Secure Boot" example you've shared is any less applicable for mobile devices.

                                                        As the old saying goes:

                                                        In theory there is no difference between theory and practice, while in practice there is.
                                                        --Benjamin Brewster, Yale Literary Magazine, February 1882
                                                        (QuoteInvestigator.com)

                                                        My claim was not that it's fundamentally impossible for "desktop" machines to do verified boot correctly, and in fact I indicated that I believe Apple is ahead of other vendors. I used that one article (there are others) to point out that in practice, in the actual world we live in, firmware security for "desktop" machines is really not great.

                                                        sha0 If the Google Pixel 6a secure element's firmware's key is published online, then someone skilled in the art can sign a malicious variant of the firmware and it can eventually reach the secure element.

                                                        True. However, the actual event that I provided a link to involves multiple completely unrelated device types using the same leaked key. That is an unforced error well beyond the leaking of a single key. Note, for example, that the GrapheneOS project uses a distinct signing key for each device type.

                                                        I believe that a review of the evidence will support the proposition that multiple mobile devices have better hardware/firmware security than Apple's "desktop" devices, that in turn have better hardware/firmware security than a good majority of other "desktop" devices. There is no law of physics that makes that true, but I believe it is true.

                                                        sha0 How about this?: You adjust your equipment to trust your own keys and you avoid "supply-chain" failures, such as that "Secure Boot" example.

                                                        I am not aware of hardware that supports changing the lowest-level assurance keys. What I mean by this is, for example, Intel issues microcode updates for their processors, and the microcode updates are signed, and I believe the public half of the keypair is part of the processor. I believe that in general platform keys are not subject to "adjustment".

                                                              sha0 Please imagine this scenario: [...] The automobile no longer behaves the same way as the day you test-drove it, prior to its purchase.

                                                              It sounds as if you are opposed to UI changes in both phone software and automobile software, which is fine. Perhaps the current trends of phone software evolution and automobile software evolution will both return to stasis, or perhaps they will diverge and one will continue evolving wildly while the other will become static. Personally my hunch is that automobiles UIs will, on average, change more than they do at present, as old static-UI cars retire, but that the pace of automobile UI evolution will continue to lag far behind phone UI evolution, which I suspect will remain brisk for at least five more years (but, I suspect, longer).

                                                              I also suspect we're in for at least five years of brisk malware evolution, and thus any endpoint using network services (e.g., Google Maps) that isn't updated for long periods of time will be at risk. Please note that I'm not in favor of firmware vulnerabilities or OS vulnerabilities or app vulnerabilities or malware! But I suspect that people will need to deal with that mess for a good while, and I suspect that during that period of time UI changes will ride along with security patches.

                                                                sha0 wall of text that tells nothing.
                                                                You expected a device that relies SOLELY on software (not like your light bulb example) to function without updates.
                                                                You didn't update because you cared more about UI/UX than stability and security. Which also coincides with my statement that you "didn't care about updates". At least not enough to understand their value?
                                                                You also pretty much literally said that developers pushing updates (for VERY good reason!) are, more or less, promoting planned obsolescence by doing so.
                                                                Your "expectation" of a well designed OS also doesn't make any sense. Sooner or later the bundled certificates will expire and you will have similar problems if you don't update the OS. The utopian scenario you're describing doesn't exist in the real world.

                                                                • sha0 replied to this.