PIN Ordeal

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.

[...] 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:

• https://yourlogicalfallacyis.com/ad-hominem

[...] 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:

• https://yourlogicalfallacyis.com/strawman

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:

• https://yourlogicalfallacyis.com/strawman

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.

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

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

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:

• https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/standard-terminology-software-updates

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:

• https://www.catalog.update.microsoft.com/Search.aspx?q=security

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:

• https://www.reddit.com/r/GooglePixel/comments/17yufkn/any_way_to_disable_pinentry_shapes/

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:

• https://android.googlesource.com/platform/frameworks/base.git/+/beeabf4b129056da25c25d3b82ff79bc6883c123

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:

• https://en.wikipedia.org/wiki/Necessity_and_sufficiency

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? 🤔

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. 👍