n3t_admin:

wall of text that tells nothing.

What a nasty, dismissive thing to type to another human being.

You expected a device that relies SOLELY on software (not like your light bulb example) to function without updates.

Wrong. If you cannot refrain from making claims about another person's inner state, then I do not anticipate much fruit from our discussion. I do appreciate that you have spent some effort because it leaves open the possibility that you have tried to contribute value, but I'm concerned. Why not attempt to "steel-man" my position, in order to ensure that you understand it, instead of arguing against a "straw-man?"

You didn't update because you cared more about UI/UX than stability and security.

"Care" is not the word I would choose to use. I wouldn't tell a person in a wheel-chair that they cared more about remaining in their wheel-chair than taking the steps to get into the rampless library. This is one of my complaints: I continue to perceive few indicators that modern software developers will strive for high UI consistency and instead I perceive many indicators that modern software developers seem to think that UI changes are rather trivial: a matter of the user caring about them or not. These days, it's pretty much guaranteed that a person who has severe struggles with UI changes will be screwed over by updates.

I enjoy the terminology described here:

Somehow, that company has had enough resources to be able to keep new features and UI changes available separately from bug-fixes and security-fixes, for years. Yes, they also offer "bundling" them together, but they do offer them separately:

One possible argument for bundling UI changes and security- and privacy-related changes together is, "We don't have the resources to keep them separate." (Including resources to scrutinize and/or reëngineer an "upstream" source.) Another argument is, "We don't have that discipline." I suspect that there are other arguments, too. As I typed in my third paragraph at the top of this discussion:

(A case of "beggars trying to be choosers," one could argue.)

(If only that was understood by readers as trying to temper complaint with appreciation.)

I've mentioned how GrapheneOS in October of 2022 had circles for the unlock character-entry and that GrapheneOS in September of 2024 (I've erroneously typed "October" of 2024, in at least one earlier message; even less than 2 years!) had pointy shapes. I wasn't the only person who noticed it:

That person expressed the opinion:

[...] but it's just weird.
[...]

Maybe for that person, it's just a matter of caring about it or not.

I wonder if there was some e-mail thread involving peer-review, somewhere near here:

If so, I wonder if in that peer-review, someone suggested that the UI difference should be explicitly opted into by users, instead of becoming the default. I wonder if the default in upstream Android is the same as the default in GrapheneOS, or if one or more GrapheneOS folks perceived this to be better for privacy, so it should be the new default for new GrapheneOS.

Which also coincides with my statement that you "didn't care about updates". At least not enough to understand their value?

What an uncharitable expression of an estimation of the intelligence of a participant in a discussion-forum for an operating system having an appeal to users who are interested in security. Thank you for using a question-mark, there.

You also pretty much literally said that developers pushing updates (for VERY good reason!) are, more or less, promoting planned obsolescence by doing so.

No, I did no such thing. Literacy is important. I had typed:

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 believe that there is a difference between promotion and compatibility. For example, given this premise:

There are no laws regulating the production of smog.

We can have a neutral result for smog:

Nobody produces smog because nobody likes smog.

Or we can have a promoted result for smog:

"What we all need is more smog! Let's get to it!"

The lack of law doesn't promote smog, but is conducive for the promoter. Consider this alternative:

There is a law which penalizes the production of smog.

This law is neither conducive to smog nor does it promote smog. Perhaps the distinction in my mind is akin to:

It might very well be the case that many software developers are engaged with planned obsolescence. It might very well be the case that few software developers are engaged with planned obsolescence. The reason I'm not making a claim is because I haven't met all software developers and because even if I had, I do not know what's inside the minds of all software developers. I refrain from making a claim about their inner state.

A side-note regarding literacy and making claims about others' minds: in another discussion, I've typed:

[...] software developers seem mostly ignorant of how UI changes are not universally desirable.

The word "seem" is important, there. It means I could be wrong about that ignorance, but have little indication to the contrary, so far. The word "mostly" is important, there. I am personally aware of software developers who care about a consistent user interface and I suspect there are more than I'm personally aware of. Most of my observations are inconsistent with "consistent UI" and those observations appear to be ramping up, over the years.

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.

Did you read this part?:

non-Internet-dependent apps are installed, [...] 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.

Which certificates are you imagining being used by a static set of apps and without a relationship to the Internet? Are the apps themselves signed with expiring certificates and cannot be launched after a certain date without adjusting one's clock? If apps are signed with expiring certificates, is that conducive to planned obsolescence or an impediment to planned obsolescence? 🤔

    @sha0 ,
    While I appreciate the time you've taken to respond to folks, there is a reason the general consensus around the responses is what it is.

    The current understanding of your position is:

    • The “update or bust” approach fosters planned obsolescence.

    • The assumption that if you never update your system or your apps, “what worked once should always work,” so long as you do not rely on new server features.

    • The idea that security updates and UI changes are always bundled together.

    • You want an old TWRP-like dd approach for image backups.

    The problems with these are as such:

    • Modern phone apps/services change rapidly on the server side. An old OS release inevitably breaks or cannot fetch new Google apps. No project, especially a security-focused OS, can keep older Android versions patched forever. Once the official upstream stops delivering monthly patches for the OS or firmware, or once a release is years out of date, it is unsupported. That is not malicious, or “planned”, or fostering obsolescence; it is simply how open-source projects operate within practical resource constraints.
    • The AOSP monthly security bulletins land on top of new releases that typically also tweak or rework parts of the UI. GrapheneOS can patch or strip certain parts, but it cannot easily “freeze” every single UI aspect while merging everything else. It is an infeasible expectation. Additionally, as @yore said:

    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)

    • The methods and tools like TWRP and dd backups are inherently at odds with a mobile OS and device with locked-down firmware, verified boot, a hardware-backed keystore, etc. It would undermine secure/verified boot and hardware-bound encryption keys. It is simply a different (better) design from a security perspective.

    None of this includes any comments on your "inner-state", what your requirements are with UI changes, etc. These are just the reality of each of the individual situations.

      Skorp: Thank you for your obviously kind and intelligent response. It is most refreshing. It is clear that you have attempted to "steel-man" my position.

      The “update or bust” approach fosters planned obsolescence.

      Not quite. My position is that I do not (yet) perceive measures to actively combat planned obsolescence, nor do I perceive October 2022 through September 2024 to be particularly welcoming timeline for dropping compatibility for the GrapheneOS-server-hosted Google-feature-fetching service that worked in October 2022. I would use the word "permits," as opposed to "fosters."

      For the former: I believe that we can all agree that there is at least one company who is both interested in making profits and a contributor to Android. (I have worked for one such company as I'm sure others have, but I do not represent that company at any time nor in any manner; expressed opinions are entirely my own.) I believe we can all agree that there are at least some incentives for such a company to engage with planned obsolescence; whether or not such engagement is true is not a claim I'm making, here. I believe we can all agree that GrapheneOS derives from Android. Thus, if we contemplate whether or not GrapheneOS might be less likely to have any planned obsolescence than that upstream itself has, my answer is, "No, not without particular efforts on the part of GrapheneOS to undo any inherited planned obsolescence."

      For the latter, if we contemplate whether or not GrapheneOS itself has incentives towards planned obsolescence, I have speculated that "dropping support for an old thing is a method to force users into updating, which is in their best interests, anyway" is a possible incentive. I do not know why the Google-feature-fetching service of October 2022 didn't work in September 2024, nor am I entitled to demand to know, but there is certainly an invitation for explanation, including a rejection of that possible incentive. (I shared an alternative explanation, too, instead of accusing.)

      A month less than 2 years to drop the aforementioned service probably seems like an eternity to many readers, but it doesn't seem like very long, to me. This is one of the shortest compatibility time-windows that I've encountered. I'm simply expressing, "that was surprising and unfortunate to discover, in September 2024."

      Why, it might even be nice if the Google-feature-fetching feature was capable of fetching the Google features online, then making a file from those that could be backed up and restored, entirely offline, after a factory-reset. Since I have not yet fully explored newer GrapheneOS, I have no idea if such a feature has already been implemented, after October 2022.

      The assumption that if you never update your system or your apps, “what worked once should always work,” so long as you do not rely on new server features.

      This is almost my position. My position is that it's a pleasant affair when everything that works on an "airgapped" computer today works on that same "airgapped" computer in many years. (So far, I have some computers at 24 years, which are actually faster than 24 years ago, due to modern hardware.) Before I updated GrapheneOS in September 2024, I wasn't able to take a "snapshot" of my older GrapheneOS, for roll-back purposes. This was disappointing. When I tried to reässemble to approximate my previous state, I discovered the October 2022 Google-feature-fetching service had been dropped. This was also disappointing. Perhaps an alternative would have been to've had 2 Google Pixel 6a cellular telephones and use one of them for testing, but I was unfortunately not in that position.

      Backing up, restoring, rolling back have all been standard parts of my professional experiences. If GrapheneOS has such conveniences today, then it's simply unfortunate that they weren't available in the October 2022 iteration.

      The idea that security updates and UI changes are always bundled together.

      This seems true, relative to Android-based devices and the operating systems available for them.

      You want an old TWRP-like dd approach for image backups.

      Yes. I'm a user and I'd like to decide upon my different levels of security-concern. I'd like to be able to take a snapshot of the state of my device and be able to restore that state. DD is less expensive to me than getting a laboratory to physically remove my storage and make it accessible elsewhere, use electron tunneling microscopes (or whatever) to invade a Titan M2 chip for its keys. DD is less expensive to me than setting a broken phone down for a few years and then paying Cellebrite to invade and recover data from. Neither the lab nor Cellebrite will complain about my inability to use DD.

      Modern phone apps/services change rapidly on the server side.

      Yes, I know.

      An old OS release inevitably breaks or cannot fetch new Google apps.

      Being able to save one's state for restoring later on is helpful.

      No project, especially a security-focused OS, can keep older Android versions patched forever. Once the official upstream stops delivering monthly patches for the OS or firmware, or once a release is years out of date, it is unsupported. That is not malicious, or “planned”, or fostering obsolescence; it is simply how open-source projects operate within practical resource constraints.

      Nor should they, given the reality of limited resources. This isn't one of my hopes.

      GrapheneOS servers in September of 2024 did not continue to support the Google-feature-fetching from October 2022. GrapheneOS of October 2022 did not permit storing fetched Google features in such a way that they could be restored. GrapheneOS of October 2022 did not permit a device-snapshot that could be restored. If any of these had been different, I would have no feedback to offer about my surprise regarding fetching Google features, in September 2024. I won't claim a conspiracy, but these certainly have the same effect as a ratchet that only moves in one direction.

      The AOSP monthly security bulletins land on top of new releases that typically also tweak or rework parts of the UI. GrapheneOS can patch or strip certain parts, but it cannot easily “freeze” every single UI aspect while merging everything else. It is an infeasible expectation.

      I do not hold such an expectation. I'm trying to apply pressure and raise more awareness about a subset of users. I'll type a third time:

      (A case of "beggars trying to be choosers," one could argue.)

      Moving on:

      The methods and tools like TWRP and dd backups are inherently at odds with a mobile OS and device with locked-down firmware, verified boot, a hardware-backed keystore, etc. It would undermine secure/verified boot and hardware-bound encryption keys. It is simply a different (better) design from a security perspective.

      I disagree. It's always possible that my understanding could improve, based on discussion. I have read nothing persuasive, so far.

      There is a time after I purchase the device in which the device trusts that I am the owner of the device. As I've mentioned in an earlier message, I should be able to examine the chain of trust for firmware, booting, kernel, and other software, then replace any of these components with my own chain of trust and with my own verifiable counterparts. This is "better security" than leaving things as is (from my perspective) because assuming that I trust the hardware to do its job, then removing keys other than my own impedes interference from the original key-holders: the "supply chain."

      "But you surely don't have the resources to sign and deploy all important security-updates, so you'll quickly fall behind," one might argue. I'd rather have the choice and be the judge.

      I wish I was able to sign my own boot-loader, then boot if from firmware that only trusts my key(s), then sign my own TWRP-alike, then boot it from that boot-loader that only trusts my key(s), then use DD to make a copy of the disk. That's with respect to:

      [...] locked-down firmware, verified boot, [...] It would undermine secure/verified boot [...]

      Now regarding:

      [...] a hardware-backed keystore, [...] hardware-bound encryption keys. [...]

      I agree that it is true that these security-contexts exist:

      1. A case in which it is better for particular data to be permanently lost than risk ever being recovered by an unauthorized party. Time might be of the essence to eliminate that data, too. Some such cases might involve "duress."
      2. A case in which it is useful to make unauthorized data-recovery very expensive. With a dd copy of data encrypted by a few numeric digits' worth of entropy, that copy can be brute-forced very quickly. If that data is encrypted with much more sensible entropy, then it can't. Storing such a sensible key in "secure element" hardware & software can help to balloon the expense, including the retry-timer feature.

      I'd argue that "(better) design from a security perspective" can be debated.

      I believe that having different security-levels for different data is part of good design. I believe that a singular "all or nothing" level ("one size fits all") is not particularly good design. I have stored and recently lost access to family pictures. (Once again, it's my own fault for not backing up more frequently.) I'd've been happy to've encrypted these with a few numeric digits' worth of entropy and to've been able to brute-force eventual access, along with everyone else in the world who might gain physical access to the device or to a dd copy. (Please see earlier "SuperSecret" message, regarding different levels.)

      I believe that "air-gapped" is a better security position than "connected to the Internet and/or to cellular telephony providers." I would consider it unwise to work with the most sensitive data in the latter contexts. The frequency of security-patches "says it all," to me: a "game of cat and mouse" is not really a game worth playing. I believe that "losing all of one's data or paying Huge... Sums of Money to get it" and "0-day exploits in which an unauthorized party gains all of one's data" is not ideal for all "security-levels." Again, no recovery-lab would complain about the former. No hacker-thief will complain about the latter.

      None of this includes any comments on your "inner-state"

      Your civility is very much appreciated and demonstrative of leading by example. Thank you, @Skorp. 👍

      • de0u replied to this.

          A "happy ending":

          • 5 days
          • 220 tries
          • 7,680 seconds in-between the most recent tries
          • 110 different codes
          • A note of all the codes that were tried, along with timestamps and other observations

          A code I'd tried much earlier on worked, as the 220th try. The quirk here was that one of the following was true:

          1. After some failed attempt of a different code, during the resulting retry count-down, I rebooted the phone prior to the count-down's completion, then was permitted to try to enter a code without the remaining count-down timer from the previous attempt appearing, so the try incremented the number of tries, but wasn't actually tried with the secure element because the previous attempt hadn't truly expired; was just hidden.
          2. After some failed attempt of a different code, after the resulting retry count-down completed, I rebooted the phone. Upon trying the correct code, it was reported as a failure and a count-down began. The reboot had actually restarted the previous attempt's count-down timer, without notice. This try incremented the number of tries, but wasn't actually tried with the secure element because the previous attempt's timer had been restarted by the reboot; was just hidden.

          I know not which of these was the case, or both, since it was the third try of the correct code. For all I know, either or both of them are bugs that were fixed in newer versions of GrapheneOS than I was using. This is not a complaint.

          First world problems.

          Have a nice day.

            sha0 I believe that we can all agree that there is at least one company who is both interested in making profits and a contributor to Android. [...] I believe we can all agree that there are at least some incentives for such a company to engage with planned obsolescence; whether or not such engagement is true is not a claim I'm making, here.

            Google used to provide firmware support for three years, then five, now seven. And for the newer devices it's not only firmware support but also OS upgrades. It is true that OS upgrades retire old user interface look and feel, but it seems more as if Google is trying to reduce planned obsolescence of hardware than as if planned obsolescence of hardware is part of their game plan. At least at present Google gets money from selling hardware, not selling firmware updates or OS updates, so it's not clear what incentive they would have for UI obsolescence.

            Meanwhile, other Android manufacturers, seemingly encouraged by Google's reduction in planned obsolescence of hardware, are also extending support lifetimes for hardware. Overall, fewer phones are being retired early due to planned obsolescence of hardware.

            With respect to UI changes, honestly I suspect the situation is that 75% or 80% or 90% of users find most of the changes to be fun and/or helpful. Google coukd in theory indefinitely backport non-UI changes to a UI that is largely frozen, but it would be a lot of work, and, I suspect, would not attract more than a tiny number of customers. That balance between users who like UI changes and users who don't is, I suspect, the incentive for making UI changes.

            All of that said, if a significant community of users really dislikes UI changes in GrapheneOS and wants to maintain a frozen-UI fork, and can pay a team of three to five developers to do backporting work, technically it could be done. I suspect It's not something that could be done in "spare time" by the GrapheneOS developers, because I don't think they really have "spare time" while keeping up with Google plus adding security and privacy features.

            Please note that I don't speak for the GrapheneOS project.

                sha0 There is a time after I purchase the device in which the device trusts that I am the owner of the device. As I've mentioned in an earlier message, I should be able to examine the chain of trust for firmware, booting, kernel, and other software, then replace any of these components with my own chain of trust and with my own verifiable counterparts.

                That would be great, but I am unaware of situations where that exists. Some devices support arbitrary bootloader and BIOS replacement, but open firmware for Wi-Fi, Bluetooth, cellular modems, GPUs, and secure elements is pretty bleak. I am unaware of processors that support user-specified microcode signing keys.

                As long as hardware that is open and featureful isn't available, it is necessary to choose some imperfect mixture, at least as an interim measure.

                • sha0 replied to this.

                    sha0 A code I'd tried much earlier on worked, as the 220th try.

                    Great news!

                    • sha0 replied to this.

                        @de0u: Thank you for your kind, intelligent responses.

                        [...] so it's not clear what incentive they would have for UI obsolescence.
                        [...]

                        de0u: It seems that I accidentally permitted an interpretation of a direct connection between UI changes and my mentions of planned obsolescence. I didn't intend to. I've tried a couple of times to clarify, but have probably failed, so far. I'll try again.

                        When I release software and users start using it, I have a few expectations, including (but not limited to):

                        • Users might have feedback about it and might want to share that feedback.
                        • Some users will want a stable experience.

                        Please consider this scenario:

                        It is challenging to provide a stable experience.

                        A trivial example is if I no longer provide a particular version that a user once enjoyed and if the version(s) I do provide yield an experience that isn't consistent with the version the user enjoyed. Because I'm aware of this example, I try including some "hosting many versions" into my budget. That budget might be challenging, which leads to the scenario above. Suppose that I cannot afford to provide a stable experience. I might inform my users, "Sorry, but it's best to stay up to date, anyway; lots of reasons."

                        How about an alternative Universe in which I'm a light-bulb salesperson. I sell enough bulbs to buy a house, but that's it. Well it turns out that I have property taxes and wear & tear to deal with, so one way I can try to deal with these is to sell more light-bulbs. "But I already have a working light-bulb," the door-answerers tell me. I might try to tell them, "Sorry, but it's best to stay up to date, anyway; lots of reasons." That might not be persuasive, however. If I am clever enough to anticipate all of this from the beginning, perhaps I might sell light-bulbs that stop working at a rate that permits me to make ongoing sales at a rate that permits me to pay my property taxes and deal with my house's wear & tear. If customers complain, I might try to tell them, "Sorry, but it's best to stay up to date, anyway; lots of reasons."

                        Given that it's the same statement in both cases, the recipient of the statement cannot know from that statement alone which Universe they're in. The recipient can try to probe the party making the statement for further explanation and/or for better distinction between the 2 (or 3) Universes.

                        In short, I find that "just keep updating" as a response doesn't give me confidence that I am minimizing my exposure to planned obsolescence, but I'm not fond of planned obsolescence. I wasn't making a claim about GrapheneOS and planned obsolescence, nor Android and planned obsolescence, nor UI changes and planned obsolescence. I was essentially feeding back about the all-too-common-so-seemingly-knee-jerk "just keep updating" sentiments. I probably wasn't clear enough.

                        But...

                        [...] so it's not clear what incentive they would have for UI obsolescence.
                        [...]

                        Having typed that, if I'm a software vendor and I have a positive relationship with a hardware vendor, I can certainly introduce UI changes which perform better on the latter's newer hardware than on their older hardware. All the bells and whistles and flashing lights certainly seem to accompany spending in casinos. I've laughed multiple times about fresh, side-by-side comparisons of the performance of an OS versus that same OS plus all updates. This isn't an accusation, but offered in response to the above quotation.

                        Also having typed that, your notes about increases in the expected lifetime of Android devices is refreshing to read, @de0u.

                        [...] to maintain a frozen-UI fork, [...]

                        Indeed! It's quite admirable when effort-makers permit others to easily derive from their efforts, to pursue other directions.

                        That would be great, but [...]

                        de0u: Yes, I was responding to:

                        [...] It is simply a different (better) design from a security perspective.
                        [...]

                        and another mention that laptop, desktop and data-centre computers were inferior, security-wise. I have used multiple (U)EFI "setups" which permit the management of keys. I haven't yet encountered early key management for an Android device. I see that early-stage efforts have been made, before, with at least EFIDroid and lk2nd:

                        🤷‍♂️

                        Great news!

                        de0u: Indeed! Although excuse me, I meant 7 days. 😬