eylenburg
(AOS comparison) Add PostmarketOS and also add a sustainability attribute
The AOS comparison neglects pmOS and also overlooks the sustainabilty factor. pmOS appears to be the best for sustainability as it supports phones for a long time. Compared to Graphene which is quick to shed support for phones it deems obsolete.
This thread may be worth a look.
also overlooks the sustainabilty factor
That's not correct. It has a row for "Partial security updates (ASB) after EoL date" to cover support for end-of-life devices with partial security updates after there are no longer any firmware updates, etc. We currently extend support for devices with under 5 years of support to around 5 years. The past 2 generations of devices have 7 years of support from launch and the previous 2 generations have 5 years so the current extended support approach is fully obsolete. We could provide extra extended support for the ones with 5 years from launch in which case the entry would need to be changed.
For other operating systems supporting a wide range of devices, there's usually no guarantee that everything keeps working on each device or that support continues. It can break and stop working for long periods of time or forever. We make production quality releases and test them on each supported device, followed by going through Alpha, then Beta and finally reaching Stable. Not really the same thing as it maybe working and devices can be dropped if maintainers stop working on it or can't get it working in their free time.
pmOS appears to be the best for sustainability as it supports phones for a long time.
If you're fine with a highly insecure device with a dramatically less secure OS and consider it more sustainable to use that than buying a new device every 7 years. 7 years is a very long time for a phone and there are drastic improvements to hardware and firmware security over that kind of time period. A device in 7 years is going to have far better defenses against both forensic data extraction and remote attacks. There's only the start of writing firmware in memory safe languages today and the start of hardware-based features like memory tagging and reset attack mitigation being added. There's a long way to go.
A bit over 7 years ago was the launch of the Pixel 2, which had the first secure element in a Pixel providing disk encryption key derivation throttling but not yet the other secure element features. It still used TrustZone for the hardware keystore and was the first generation using the Replay Protected Memory Block for verified boot which was replaced with the secure element in the next generation. It didn't have authenticated encryption between the SoC and secure element which was added with the next generation, although it didn't use it for much yet and it didn't really make a difference for what it did use. The year before, the initial Pixel 1 didn't have a secure element and only had indirect enforcement of downgrade protection and the key matching for verified boot through tying it into encryption key derivation. The previous generation was the first with verified boot for the OS at all (Nexus 5X and 6P). There were many other hardware security improvements since then. Going from 3 years of support for firmware, drivers, etc. to 7 also happened.
Compared to Graphene which is quick to shed support for phones it deems obsolete.
GrapheneOS doesn't deem that devices are obsolete. It marks devices which no longer receive proper security support as being extended support, then legacy extended support and finally ends support for them once we see the drawbacks as outweighing the benefits. The devices we have marked extended support or phased out are objectively no longer reasonably secure devices due to lack of patches. Putting another OS on it doesn't fix this. Encouraging people to keep using an insecure device causes harm to them. These devices are insecure and users cannot be properly protected from attacks. GrapheneOS pushes people to move to secure devices and strongly recommends only buying ones with 7 years of full support from launch in our FAQ and elsewhere. It would go against the values of the project to put users in harms way to increase the usage share of the project. Getting people to use secure devices is part of what we're responsible for doing.
The current generation list of hardware requirements for GrapheneOS is available at https://grapheneos.org/faq#future-devices. This lists both hardware and firmware security features along with covering firmware and software support. It also lists hardware-based security features such as hardware memory tagging and hardware-based disabling of USB-C connections/data which are used by the OS to defend the device from attacks. The only devices providing everything on this list are the Pixel 8 and later. The Pixel 6 and later provide everything other than the newer generation ARMv9 CPU features (hardware memory tagging, pointer authentication and branch target identification). All of them are moving to new kernel branches so that's not exclusive to newer devices.
Hi @bruceleerabbit I would find it interesting to see how postmarketOS compares, but at the moment I see two problems:
- It would be hard to compare it with Android distros as it's a completely different system (besides using the Linux kernel). For example, the number of available apps would be much more important for a user than some details about what connections to Google it makes by default. I think just keeping the current rows and adding a column for PostmarketOS would not work well. (Counterargument: On the "Desktop Environment comparison", it's all Linux/Unix desktops and then it also compares Windows and macOS at the end. Some rows don't really work for them, but most do.)
- If postmarketOS is included, then SailfishOS and Ubuntu Touch and "generic" Linux distros with mobile versions (e.g. Manjaro, Fedora, OpenSUSE, OpenMandriva) should probably be included as well. At that point it begins to be a "mobile OS comparison" and you might as well include iOS too.
So for me it's out of scope and too much work but I'm not completely opposed to contributions.
@eylenburg As someone who is trapped on AOS due to hardware that has been abandoned and ignored, your comments here are in fact interesting to any forced-obsolescence refugee looking for a freedom-respecting sustainable option. I think what you’ve said here should be exposed to anyone landing on your comparison page. Not necessarily as a detailed comparison but the Android comparison would notably benefit visitors if there were a simple mention of Android alternatives.
Visitors need to know what is being compared and what criteria is used for inclusion and exclusion. You could give a fair amount of transparency and clarity in just a couple lines. Your opening statement does not give that clarity because it assumes people have that nuance in mind. E.g. you could say something like:
“This comparison excludes operating systems that replace Android OS but are not AOSP based. These excluded mobile platforms include: postmarketOS⯌SailfishOS⯌Ubuntu Touch⯌Manjaro⯌Fedora⯌OpenSUSE⯌OpenMandriva⯌Maemo.”
Neglecting that, it’s not really clear to visitors why they are looking at a reduced selection.
I’ll respond to @thestinger’s comments briefly to correct the record and advocate for more useful attributes, particularly in case this moves forward as a separate comparison table.
also overlooks the sustainabilty factor
That's not correct. It has a row for "Partial security updates (ASB) after EoL date" to cover support for end-of-life devices with partial security updates after there are no longer any firmware updates, etc.
It was correct but my use of “sustainabilty” refers broadly to the environment and ecocide avoidance. Your interpretation is in the narrow context of security. Security updates are just one component of environmental sustainability, and it’s not an essential one (which I will elaborate on further below). The essential component of environmental sustainability is API updates. It’s API version that makes or breaks sustainability, and it has been neglected from the comparison table.
For other operating systems supporting a wide range of devices,
Not the user’s problem. An OS project has limited resources, which (as you say) can be invested in breadth, or depth. Whether someone favors one resource allocation over another is for each user to decide. The job of the comparison table is ideally to leave users informed as to what extent depth of support is achieved. But that’s hard to do. In any case, it’s not relevant in this bug report.
If you're fine with a highly insecure device with a dramatically less secure OS and consider it more sustainable to use that than buying a new device every 7 years.
It’s not about me. Different people will value extent of security to different degrees in competition with many other variables. Even the same person will have different needs for different use cases and possibly different devices. If I am repurposing a phone to serve as an air-gapped TV remote controller using an IR LED, I don’t give the slightest shit about security. But I care whether the app runs on the phone.
7 years is a very long time for a phone and there are drastic improvements to hardware and firmware security over that kind of time period.
It depends on the application but 7 years is a terrible injustice for the environment. A user might use their phone for banking for 7 years, but because they refuse to partake in ecocide they opt to repurpose the phone as an offline bluetooth receiver for a sound system, run something like Haven for offline local security, or as a TV remote. They should have that option.
GrapheneOS doesn't deem that devices are obsolete. It marks devices which no longer receive proper security support as being extended support, then legacy extended support and finally ends support for them once we see the drawbacks as outweighing the benefits.
You seem to have an obscure idea of what it means to tag something as obsolete. What you describe is obsoleting devices. IIUC, the OS upstream of Graphene decides a device is too old to support. Upstream regards it as obsolete and GrapheneOS mirrors that decision. Perhaps understandably so. You might decide it’s not worth the resources to port security updates to older hardware. Regardless, the device is being obsoleted.
The devices we have marked extended support or phased out are objectively no longer reasonably secure devices due to lack of patches. Putting another OS on it doesn't fix this.
That makes no sense. The vulns are rarely in the hardware. Another OS has a different set of vulns, different bugs, different patches. All programs have defects but they are different. Switching from one OS to another makes a trade of one set of vulns for another.
Encouraging people to keep using an insecure device causes harm to them.
It’s not the hardware that’s “insecure”. There is also a problem with this idea of labelling a whole device as “insecure”. There are known vulns and unknown vulns. A bleeding edge new software installation is rich in unknown vulns. An old s/w installation is rich in known vulns.
An advanced security-wise user is better off with old software because they know what vulns they are exposed to and they know how to control for them. They also know whether a vuln even affects them. And they are not exposed to the new vulns. So they have more control over their security posture by staying well behind the curve.
A normie or novice user is better off with a new device because they have no hope of being aware of the vulns anyway, so their best move is the roll the dice and hope their adversary doesn’t find a zero day and use it against them.
It would go against the values of the project to put users in harms way to increase the usage share of the project. Getting people to use secure devices is part of what we're responsible for doing.
If you mean the GrapheneOS project, sure, fair enough. GrapheneOS can sell itself as security-centric at the cost of longevity. And the comparison table should express that so readers can be informed. Another platform project might be environmentally focused and achive more longevity at the cost of security. Another platform has different vulns anyway so it might even achieve more longevity for the same level of security. Regardless, it is for each user to decide whether a platform satisfies their use-case and security needs.
It’s important to realize that your threat model is not my threat model. Users have different threat models & different missions. I am looking to repurpose old phones while controlling for known vulns (e.g. by disabling relevent parts of the attack surface, installing firewalls [ingress and egress], etc). I might make an old phone into an offline GPS server with the sole task of tracking satellites and broadcasting position over bluetooth. It would be a disservice to me to cancel or conceal platforms that make that possible on the basis that vulns that are irrelevant to bluetooth broadcasting are present.
@eylenburg
It was correct but my use of “sustainabilty” refers broadly to the environment and ecocide avoidance. Your interpretation is in the narrow context of security. Security updates are just one component of environmental sustainability, and it’s not an essential one (which I will elaborate on further below). The essential component of environmental sustainability is API updates. It’s API version that makes or breaks sustainability, and it has been neglected from the comparison table.
A device which does not provide proper long term security support also lacks environmental sustainability since it has to be replaced to continue having a decent level of privacy and security. Not providing proper long term security support is in fact an environmental issue.
Not the user’s problem. An OS project has limited resources, which (as you say) can be invested in breadth, or depth. Whether someone favors one resource allocation over another is for each user to decide. The job of the comparison table is ideally to leave users informed as to what extent depth of support is achieved. But that’s hard to do. In any case, it’s not relevant in this bug report.
GrapheneOS supports every device meeting the hardware requirements at https://grapheneos.org/faq#future-devices. The current table doesn't adequately communicate the massive downsides to supporting hardware lacking proper alternate OS support and basic security properties. It portrays supporting more devices as strictly positive and that's certainly not how we see it. We see our extended support for insecure end-of-life devices as useful for harm reduction for users unable to get a new device but also harmful due to encouraging people to keep using insecure devices. Therefore, the approach to things like that have to be balanced between different priorities. We aren't interested in supporting devices without the basic security properties needed to successfully defend against things like remote compromise and forensic data extraction via common commercial exploit tools, so we don't put ourselves in the situation where we can defend our users. See https://grapheneos.social/@GrapheneOS/112826067364945164 for an example of what we're talking about. Only iPhones and Pixels successfully provide regular users with working disk encryption due to the secure element making lock methods other than a very strong passphrase actually work in practice. It's one of example of why a single one of the requirements is in our future devices requirements list which is based on what the past several generations of supported devices provide.
It’s not about me. Different people will value extent of security to different degrees in competition with many other variables. Even the same person will have different needs for different use cases and possibly different devices. If I am repurposing a phone to serve as an air-gapped TV remote controller using an IR LED, I don’t give the slightest shit about security. But I care whether the app runs on the phone.
Security is quite relevant if the device is in fact not as air gapped as you believe it is considering that it has radios, microphones and cameras unless you've removed them. It also wasn't always air gapped in what you're describing but rather repurposed into it.
It depends on the application but 7 years is a terrible injustice for the environment. A user might use their phone for banking for 7 years, but because they refuse to partake in ecocide they opt to repurpose the phone as an offline bluetooth receiver for a sound system, run something like Haven for offline local security, or as a TV remote. They should have that option.
In practice, the battery which is a major part of the environment cost will need to be replaced a couple times for people using a device for 7 years as a daily driver phone they heavily use. Older hardware is much less efficient and uses far more power to achieve the same things. It's not dissimilar from how it works with vehicles.
You seem to have an obscure idea of what it means to tag something as obsolete. What you describe is obsoleting devices. IIUC, the OS upstream of Graphene decides a device is too old to support. Upstream regards it as obsolete and GrapheneOS mirrors that decision. Perhaps understandably so.
No, that's not how it works. GrapheneOS marks a device extended support once there are no longer firmware and driver updates available and strongly discourages using it while providing continued updates for it alongside other devices. Once it's no longer supported with a newer major OS version, it's moved to legacy extended support rather than porting it to the new version with hacks and encouraging people to keep using a device without proper security patches.
You might decide it’s not worth the resources to port security updates to older hardware. Regardless, the device is being obsoleted.
No, this is not how it works. We provide extended support with all the AOSP and GrapheneOS updates, then legacy extended support based on the AOSP security backports for older OS versions. Android provides full security support for the latest LTS branch (Android 15 QPR1 at the moment) and backports of High/Critical severity patches to several older branches (12, 12L, 13, 14, 15) going back to around the previous 3 years of OS versions in theory but they tend to go further. The AOSP backports do not include firmware patches or patches for components outside of AOSP such as most device-specific code. That has to come from somewhere else. If the drivers and firmware are no longer developed, where are these patches meant to be ported from? Most aftermarket operating systems mislead users about what's provided and make it seem as if they continue providing full security support when really they're just providing the partial AOSP security backports to older versions of the OS in most cases, or the full AOSP security patches via the latest releases in some cases, but not all of the other patches that are needed. GrapheneOS sets an accurate patch level taking into account both the Android Security Bulletins (partial AOSP security backports + specific driver/firmware patches) and the full device-specific patches. We don't mislead users about what our extended and legacy extended support provides. We recently added a once per boot notification informing users these extended support / legacy extended support devices are insecure to go beyond what we were already doing and make it clearer to people it's not safe regardless of the fact that we continue providing updates with AOSP security backports.
That makes no sense. The vulns are rarely in the hardware. Another OS has a different set of vulns, different bugs, different patches. All programs have defects but they are different. Switching from one OS to another makes a trade of one set of vulns for another.
A large portion of the patches are for firmware vulnerabilities and device-specific code reused between different operating systems. Most operating systems don't do a good job providing patches for their non-platform-specific parts in the first place, let alone those. Many don't ship those firmware and driver patches properly or at all even when they are available. Hardware and firmware security also matters quite a lot aside from firmware security patches, contrary to what you're saying. Hardware security defects aren't uncommon and hardware security features have a huge impact including on OS security which is significantly based on hardware-based security features such as CPU provided exploit protections.
It’s not the hardware that’s “insecure”. There is also a problem with this idea of labelling a whole device as “insecure”. There are known vulns and unknown vulns. A bleeding edge new software installation is rich in unknown vulns. An old s/w installation is rich in known vulns.
Both are rich in unknown vulnerabilities and only a small fraction of bug fixes deemed to be security relevant get backported despite a far higher proportion having security relevance. Projects which are taking security seriously and moving to safer tools and languages with memory safety, type safety and other security properties. Similarly, deploying protections which eliminate whole classes of vulnerabilities, make most of the remaining ones far harder to exploit, etc. The privacy and security architecture of software, quality of implementation and the languages/tools that are used along with protections that are deployed are immensely important. It is not just about finding/patching vulnerabilities and avoiding mistakes, but the efforts in finding/patching vulnerabilities via tooling like HWASan, fuzzing, etc. vary quite a lot between software projects too.
Hardware and firmware security matters nearly as much as OS security. OS security heavily depends on hardware-based security features. Suggest reading through the hardware requirements for GrapheneOS listed at https://grapheneos.org/faq#future-devices. It includes features like hardware memory tagging which can be integrated to provide a very basic approximation of memory safety protection for memory unsafe code along with a fallback for memory safe code. Memory tagging has a huge security impact, especially since replacing all the C and C++ code with memory safe languages will take an enormous amount of resources / time.
An advanced security-wise user is better off with old software because they know what vulns they are exposed to and they know how to control for them. They also know whether a vuln even affects them. And they are not exposed to the new vulns. So they have more control over their security posture by staying well behind the curve.
No, it really doesn't work this way. Using old software absolutely doesn't mean you know the vulnerabilities you're exposed to and most security relevant patches do not actually get backported for most projects in practice. Even the ones deemed security relevant are often not backported. Newer versions of software can make massive systemic privacy and security improvements rather than only fixing vulnerabilities. They can move to safer languages, tools, libraries, etc. which result in much safer software. It is a choice to focus on endlessly expanding features/functionality/performance over security as many projects like the Linux kernel do. That Linux kernel example is also a case where most security relevant patches are in fact not backported, only a subset. Also, just take a look at how many CVEs are being assigned for the Linux kernel now that they started assigning them to anything they backport with likely security relevance. They are quite open about the fact that the backports of those are very incomplete to older versions, although far less open about the fact that they are ignoring the security patches they aren't backporting to even the most recent LTS/stable branches. Systemic security measures protecting against both known and unknown vulnerabilities are crucial, and that is something which involves cooperation across an ecosystem of software and hardware. Most operating systems are barely deploying early 2000s era protections, not much more modern and powerful exploit protections. Most are also not trying to heavily move to safer languages, tools, etc. or putting tons of resources into finding/fixing vulnerabilities either.
A normie or novice user is better off with a new device because they have no hope of being aware of the vulns anyway, so their best move is the roll the dice and hope their adversary doesn’t find a zero day and use it against them.
That's really not how exploitation works. Finding a vulnerability doesn't imply being able to exploit it, particularly if strong systemic security measures are deployed.
If you mean the GrapheneOS project, sure, fair enough. GrapheneOS can sell itself as security-centric at the cost of longevity. And the comparison table should express that so readers can be informed. Another platform project might be environmentally focused and achive more longevity at the cost of security. Another platform has different vulns anyway so it might even achieve more longevity for the same level of security. Regardless, it is for each user to decide whether a platform satisfies their use-case and security needs.
GrapheneOS has hardware requirements including requiring far longer proper updates than most devices have available for their firmware, drivers, etc. It is much more focused on actual longevity where proper support can be provided and it is one of the biggest hardware requirements listed at https://grapheneos.org/faq#future-devices. The reason we don't require 7 years of proper updates for phones yet even though all the ones we support for the past 2 years provide 7 years is because we want to keep open the possibility of supporting a non-Pixel device using an SoC like Snapdragon where even 5 years would be a stretch for most phone companies.
It’s important to realize that your threat model is not my threat model. Users have different threat models & different missions. I am looking to repurpose old phones while controlling for known vulns (e.g. by disabling relevent parts of the attack surface, installing firewalls [ingress and egress], etc). I might make an old phone into an offline GPS server with the sole task of tracking satellites and broadcasting position over bluetooth. It would be a disservice to me to cancel or conceal platforms that make that possible on the basis that vulns that are irrelevant to bluetooth broadcasting are present.
Reasoning about a threat model depends on how much you know about how security works such as the fact that there are critical severity security patches for firmware on radios, for drivers, etc. along with the importance of systemic approaches to security including isolation, memory safety, verified boot / minimization of trusted persistent state or any persistent state, memory corruption exploit mitigations, attack surface reduction and much more. Android heavily focuses on doing all of these things, and GrapheneOS builds far better protections on top of it. There's an overview of the exploit protections GrapheneOS provides at https://grapheneos.org/features#exploit-protections compared to the latest stable release of Android, meaning it lists how we improve it and doesn't list the standard features.
How will you protect against a serious Bluetooth firmware vulnerability on a device where the Bluetooth firmware doesn't have an update fixing it available and the radio lacks proper isolation and you're using Bluetooth? Alternatively, where the radio is properly isolated, but the OS driver hasn't been actively developed/maintained and has unfixed known vulnerabilities. The security of the firmware and driver isn't only about vulnerabilities but also how they were written and which protections are in place. Bluetooth firmware written in a memory safe language based around a microkernel with internal isolation and with proper IOMMU isolation for the radio itself is quite a different situation from it having a legacy C codebase which was never security aware and where basic exploit mitigations weren't deployed along with not properly isolating it from the OS, such as giving it full access to the OS USB functionality.
This is a fascinating debate, highlighting the fundamental tension between maximum security (GrapheneOS's stance) and maximum sustainability/user freedom (postmarketOS's stance). It seems both sides have valid points depending on the user's threat model.
This raises a high-level architectural question: Instead of forcing users to choose between a highly secure but 'disposable' device and a sustainable but potentially insecure one, could we design a "third way"?
What if we had a "Dynamic Security Posture" layer? A software layer on top of a sustainable OS like pmOS that could:
- Assess the device's hardware limitations (e.g., "This device lacks firmware updates for the Bluetooth module").
- Understand the user's declared use-case (e.g., "I will only use this as an air-gapped GPS broadcaster").
- Automatically generate and enforce a hyper-specific security policy based on those two inputs.
For instance, it could completely disable the networking stack except for the specific Bluetooth protocols needed, effectively creating a software-enforced "air-gap" to mitigate the very risks @thestinger mentioned.
This approach would allow device longevity while providing tailored, context-aware security. It shifts the focus from a binary "secure/insecure" label to a more granular, "secure-for-purpose" model.
Just a conceptual thought from a systems architect's perspective.
This is a fascinating debate, highlighting the fundamental tension between maximum security (GrapheneOS's stance) and maximum sustainability/user freedom (postmarketOS's stance).
That's not an accurate summary of the differences. GrapheneOS provides substantially better privacy and requires devices to have proper support for a long period of time. Proper long term support is a major part of our hardware requirements:
https://grapheneos.org/faq#future-devices
Users do not have less freedom on the hardware we support.
This raises a high-level architectural question: Instead of forcing users to choose between a highly secure but 'disposable' device and a sustainable but potentially insecure one, could we design a "third way"?
They're the ones supporting primarily disposable devices while all of the devices we support have had incomparable support for 7 years from launch for all the firmware, drivers, etc.
What if we had a "Dynamic Security Posture" layer? A software layer on top of a sustainable OS like pmOS that could:
Supporting insecure, end-of-life devices without providing crucial privacy/security patches is not proper long term support and is not sustainability. Devices without important privacy and security patches being connected to the internet is a problem for the overall internet, not only the users choosing to use insecure devices. It's a problem whether it's routers, internet of things devices or phones.
Assess the device's hardware limitations (e.g., "This device lacks firmware updates for the Bluetooth module"). Understand the user's declared use-case (e.g., "I will only use this as an air-gapped GPS broadcaster").
In general, the radios don't have updates on the devices they support. It applies to cellular, Wi-Fi, Bluetooth, GNSS, UWB and NFC. Avoiding all of those is not very practical and at that point why even use the smartphone hardware?
Automatically generate and enforce a hyper-specific security policy based on those two inputs.
It doesn't offer secure disk encryption for the majority of users who aren't going to set a strong passphrase. It doesn't protect against data extraction while a device is in the After First Unlock state. In most use cases, the overall lack of security matters. You're treating it as if it's only an issue of end-of-life devices, but that's just one aspect. Their focus is on end-of-life devices which can't be reasonably secured for most use cases, but the OS itself is a major downgrade from the privacy and security of an AOSP-based OS. It's entirely possible to support that hardware via an AOSP-based OS and retain better privacy and security. It's entirely possible to use mainline drivers, etc. with AOSP. Throwing away the better privacy and security for a user-facing OS is not required to support end-of-life devices. It was entirely possible to take a different path. The path they chose is based on wanting to bring the desktop Linux software stack to mobile, not practicality, privacy or security which it's at odds with.
It's a tiny part of why postmarketOS does not provide the basics of modern privacy and security for a user-facing general purpose OS. The desktop Linux software stack does not provide proper application privacy / security. It does not provide modern exploit protections. It's nearly entirely written in memory unsafe languages. Many of the projects are quite anti-security in their approach and views. That's not to say that the Linux kernel itself is a good base for a secure OS but it's what's supported by hardware in practice. Moving away from the Linux kernel to a far more secure microkernel is a very long term endeavor. Not massively regressing existing privacy and security throughout the OS is something which doesn't take any time.
Thank you for this incredibly detailed and insightful response. I truly appreciate you taking the time to explain GrapheneOS's philosophy and the deep technical realities of hardware and firmware security.
You are absolutely right. My initial framing of the debate was too simplistic. I now have a much deeper understanding that true, robust security is a full-stack problem and a secure OS on an insecure hardware/firmware foundation is fundamentally flawed for general-purpose use. Your point is well taken.
This actually makes my original high-level question even more interesting, but perhaps from a different angle.
Let's accept the premise that these older devices are "objectively insecure" for banking or daily driving. The question then becomes: Is there an architectural approach that allows for their "graceful degradation" into useful, low-risk, single-purpose devices, rather than becoming e-waste?
This is where my idea of a "Dynamic Security Posture" comes in. Not as a replacement for GrapheneOS's security, but as a software layer on top of a project like pmOS. Its only job would be to understand the device's hardware limitations and the user's declared low-risk use case (e.g., "offline music player"), and then enforce a hyper-specific policy that ruthlessly disables all other attack surfaces (like networking stacks, USB data, etc.).
It's a shift from a binary "secure/insecure" device to a "risk-managed-for-purpose" device.
I agree this doesn't solve the core security problem for general use, but it does seem to address the sustainability problem that @bruceleerabbit raised, from a systems architecture point of view.
Thank you again for the education, it has helped me refine my thinking
The resources to build the devices were already used. You don't undo it by finding a niche purpose for it and continuing to it instead of simply using your daily driver phone for all of those things. What's most efficient is not running a whole bunch of devices unnecessarily. Having a bunch of old desktops, laptops, phones, servers, etc. running is not good for the environment and is worse than just having as much of the materials reused as possible. If you don't truly have a purpose for it, why continue using it? That isn't helping the environment or reducing resource consumption.
Having the internet filled with insecure devices which are possible to mass compromise via known vulnerabilities is a serious problem that's heavily contributing to centralization of the internet due to DDoS attacks. It's a growing problem and should be taken more serious. Unpatched Wi-Fi, Bluetooth and cellular radio firmware is a real problem. That includes Bluetooth accessories without firmware patches, etc.
Being careful about what you buy and making sure to get products supported for a long time which are durable and high enough performance/quality to last as far into the future as possible is how you can truly reduce resource consumption for these things. Avoiding getting rid of something which you don't have a use for isn't helpful. There ARE people who have a use for it. You can often trade it in when buying a new one so at least some of the materials get reused. Google still accepts trade-ins for the Pixel 1 from 2016 when buying a new Pixel. That's one way people can use the devices they bought to use GrapheneOS when replacing them.
Buy devices with 7 years of support from launch either new or used. Use it until near end-of-life, then trade it in when getting a new one. Certainly better than buying low-end, disposable devices every couple years.
People buying expensive iPhones out of their budget as used devices and using them for ages are in fact doing the environmentally responsible thing AND are using devices with very long term support so they'll be getting security support for a long time, although still not as long as many people use them. Pixels get 7 years of support from launch now, which for a daily driver phone is a lot of time.
Stop buying disposable, low-end phones. Buy used devices with years of support remaining. Use them until end-of-life, trade them in for a new one or get another used one. Don't keep a bunch of old stuff running unnecessarily if you care about waste. Don't buy battery replacements you don't really need either, those use a huge amount of rare earth minerals often mined in a very environmentally damaging way. Keeping alive stuff you don't really have a use for is not helping the environment. You probably don't need more than 1 phone, so focus on not buying as many if you care about that. A low end phone uses almost as many resources to make as a high end one.
Thank you for the detailed response. I understand the GrapheneOS philosophy and the importance you place on hardware/firmware integrity and long-term vendor support.
I agree that a robust 'trade-in' program for recycling materials is a critical component of true environmental sustainability. It's a valuable perspective that complements the software-level discussions.
That said, my conceptual question was aimed at a different problem space: to mitigate risks for users who, for various reasons, still choose to repurpose older devices. My idea of a 'Dynamic Security Posture' isn't meant to replace GrapheneOS's mission for daily driver security, but to address the unpatched security risks of these devices when they are used for simple, low-risk, single-purpose tasks.
It's an attempt to turn a growing liability (unsecured, repurposed IoT devices) into a managed asset from a systems architecture perspective.
Again, I appreciate the detailed discussion; it helps refine my thinking on these complex issues.
Most useful tasks involve internet access. It's needed to obtain and update software in practice. Most people aren't truly going to use devices as offline only and manually put software and data onto them over a USB connection, USB drive or some other method. If the alternate OS was not providing networking then few people would use one providing it instead. People will use the OS giving them that functionality and telling them everything is fine. That is what happens today.
I understand your pragmatic view on general user adoption and the necessity of internet access for most tasks. You're absolutely right that the average user prioritizes convenience and connectivity, and wouldn't opt for an offline-only or manually updated device.
However, my conceptual question isn't targeting the 'average user' or typical daily drivers aiming for mass market adoption. Instead, it's aimed at power users, privacy enthusiasts, or even small organizations with specific, well-defined threat models who do understand and accept the trade-offs of highly restricted usage.
For instance, consider repurposing an older phone into a dedicated, single-purpose device like an offline music player, a local smart home controller (isolated from the internet), or a sensor hub for personal projects. In these cases, where the device should only perform one or two very limited functions, the ability to ruthlessly disable all but the absolutely essential attack surfaces on existing hardware (even if sub-optimally secure at the firmware level) could provide a valuable layer of defense. It could even serve as a 'graceful degradation' option for devices moving out of daily-driver status into a specific, controlled, low-risk role.
It's about designing for resilience and managed risk in imperfect hardware for very specific use cases, not for general consumer adoption