GrapheneOS' approach is to focus more on security than privacy, because they believe increased security leads to increased privacy. Unfortunately, that means their hardware requirements pretty much limit the hardware that you can run it on (currently only the Pixel phone range). Worse, it also means they stop supporting a device when it reaches End-Of-Life as software security updates stop for it (see How long can GrapheneOS support my device for? - https://grapheneos.org/faq#device-lifetime ). Sad though - GrapheneOS on Sony Open Devices ( https://developer.sony.com/open-source/aosp-on-xperia-open-d... ) would have been nice.
The whole reason why GrapheneOS is superior to its alternative is because they do all that.
I also with they could support non-Google phones, but that's a problem coming from the manufacturers, not from GrapheneOS.
My understanding is that there are close to half a million GrapheneOS users. And many potential users don't want to buy a Google phone. So it feels like it is starting to become worth considering for manufacturers...
I don't get why Fairphone doesn't look into that. Is it because they are not aware, or is it too hard for them to make hardware that is compliant with what GrapheneOS requires? Hundreds of thousands of devices may not count so much for Samsung, but they must definitely count for Fairphone.
I meant alternativeS, sorry. Well, anything AOSP-based that is not Android.
> The manufacturers aren't blocking the installing of GrapheneOS...
Of course they are not. But they produce hardware that is not secure enough for GrapheneOS to consider. I wish they saw value in GrapheneOS and produced hardware that met their requirements.
It's actually weird, because I'm convinced that it's completely worth it: just add those requirements to the design of one new model, and a potential of hundreds of thousands of people may buy it just for GrapheneOS.
This is a contradiction. There is nothing "minimal" about a requirement that excludes every device but one. Also some people (me) value independence from Google more than the highest degree of security (which relies on Google hardware).
> Also some people (me) value independence from Google more than the highest degree of security (which relies on Google hardware).
The requirements are indeed minimal. I have no problem with your valuing independence from Google, but please don't misrepresent GrapheneOS' requirements as the highest degree of security because not even they have said that. They have actually mentioned wanting to be more involved in the hardware/firmware side to implement more pro-user changes.
They are mostly basic requirements that Android OEMs should be embarrassed not to meet in 2026.
I disagree that such requirements are minimal. Nothing prevents running GrapheneOS on a device with lower requirements. It's a questionable choice by the developers restricting the choice for users.
(I agree with you in spirit, namely that GrapheneOS' standards are clearly beyond what most vendors are willing or able to do and a compromise or support of users who want to port the OS might be fitting for the current situation, but notice that the person you replied to never said "minimal", they said "minimum". I'm not a native english speaker but I believe your reading is a value judgement along the lines of "not much work" (in this context) whereas they probably intended it like a statement of fact regarding what the requirements are.)
Aren't requirements defined as the set of minimal constraints that are needed for something to be deemed acceptable by those who define that set?
Again, requirements are not laws of physics. As the author of a project, I am free to make up my own requirements, and when something doesn't meet them, then I am free to reject it because it does not meet my requirements...
If you go to a bank and they refuse to lend you money because you don't meet their requirement, you will have a hard time convincing them that their requirement are wrong and that they should instead replace it with yours :-).
It is not the job of GrapheneOS to lower their standards and deplete their resources supporting every phone under the sun. We already have LineageOS for that. I would rather not be snarky but I don't understand why people keep blaming GrapheneOS instead of the OEMs. Almost every single time.
GrapheneOS has requirements that result in only the Pixels being supported. LineageOS has other requirements that result in most phones being supported.
I may wish that more devices met the requirements of GrapheneOS, because I like GrapheneOS and their requirements, but I find it very weird to with GrapheneOS changed their core vision. What makes GrapheneOS is those requirements.
You are not independent from Google if you purchase an android device from another manufacturer. You're then having your data sent to both Google and that manufacturer, resulting in far worse privacy overall than with just Google, not to mention worse security at hardware level. If you don't want to "support" Google, just buy any used Pixel 6 to 10 series.
That's like saying Tulip blocked the installation of Vista because they didn't install enough RAM to run it
The OS makers don't have to go out of their way to support a device they don't want to (that's the beauty of open source passion projects), but it's also not like any manufacturer (that allows bootloader unlocking or ships an unlocked bootloader) is blocking GrapheneOS or anyone else from doing it, which the quote implies in my reading (maybe other people read it differently)
You called it a problem coming from the manufacturers. That implies they actively thwart it (woa, another new word! It's crazy how language works). But they don't actually have a problem with it; some of them are actively publishing the info needed for alternative OSes to work on their hardware and GrapheneOS needs only take it if they want to, but they don't. Who has a problem with whom here?
Again, not saying GrapheneOS is doing something wrong. Nobody's under an obligation. Just that, if someone wants to argue that one party is making a problem out of the situation, I don't find it fair to assign that label to every manufacturer on the planet besides google
They are dependent on the AOSP releases (which Google develops) and on the manufacturer updates (and because GrapheneOS runs on Pixels, then it goes back to Google again).
I can understand relying on an OEM to provide hardware support for a given model - but I'm finding it hard to understand why they're unable to continue supporting a release just because the upstream removes support for something.
I'm not even really sure what you mean by "manufacturer updates".
The more I hear about this project, the less is sounds like an alternative OS and more it sounds like a thin skin around whatever shit Google throws out, to be honest.
Debian surely doesn't depend on Lenovo or Asus to release OS updates for my laptop. Apparently it's not "everyone else" that needs this but it's some sort of dependency for mobile (qualcomm?) devices
I have trouble understanding why this is different on mobile devices. People keep speaking of blobs but that doesn't seem to be a thing in laptop/desktop hardware, unless they mean something like the firmware running on your wifi card and uefi chip? But those can be interfaced with from any kernel version, afaik, so I don't get it
Debian does not write the whole software stack running everywhere on your system. So if you want your system to be "supported", as in, "if a security flaw is discovered in a firmware, I want it patched and I want my firmware to be updated", then you need whoever writes that firmware to do it.
That's a dependency: if you want your system to be secure, you depend on the software running on your system to be patched when a security flaw is published.
Interesting, so any security patches to kernel level and above (AOSP code, browsers, other apps) can still be fully up-to-date when the manufacturer says a device is out of support. Not sure I understand the fuss then that Fairphone had about selecting a SoC with long support. Really thought it was some sort of problem updating the kernel or other AOSP components when using manufacturer blobs
The attack vectors against this firmware are virtually always physical right? As in, hardware access in one way or another (including radio waves reaching the device), not something that can be routed over a (cell) network
> why they're unable to continue supporting a release just because the upstream removes support for something.
If you have an EOL Pixel and a new major version of Android is released, Google will not port this new version of Android (and therefore AOSP) to it. So GrapheneOS would have to do it. GrapheneOS just say they don't have the resources to do that, so they follow the Google releases. Could you keep an EOL Pixel without receiving updates? Sure. But then it's not supported anymore, it's just outdated, insecure software.
> I'm not even really sure what you mean by "manufacturer updates".
There are the AOSP updates (which bring new features, but importantly in our case bring security fixes) that come from Google, but your phone is more than that. There is a bunch of hardware running in your phone and a bunch of firmwares exposing it. Say your camera, or your wifi module, etc. If there is a security issue in the firmware of the camera, then it won't be fixed in the AOSP codebase. You need the camera manufacturer to fix it and release a firmware, pass it to the phone manufacturer who will then deploy it on your phone.
Google split both of those concepts years ago in order to deploy Android updates faster and make everybody more secure, because manufacturers had a tendency to lag a lot. Some still do but the situation generally improved, I think. Anyway, you need to receive those security updates from your manufacturer because they are independent from Google.
> the less is sounds like an alternative OS and more it sounds like a thin skin around whatever shit Google throws out, to be honest.
If you think that AOSP is shit, then sure. I mean, if you think that the Linux kernel is shit, maybe you don't want to run a Linux distribution.
I personally think that AOSP is pretty great, and vastly superior to Linux on mobile (among other because it has a much better security model). I am not a big fan of Google being root on my phone (with Android and system apps like Play Services), which is something that GrapheneOS fixes (by making Play Services run like any other, unprivileged app). GrapheneOS is also adding privacy features, be it by proxying your location requests (so that they go through the GrapheneOS servers instead of directly to Google) or by adding features like "scopes", where you can choose exactly which contact you share with an app, for instance, or refuse Internet access to an app without breaking it (GrapheneOS will just make the app believe that it has the permission to access the internet but there is just no connection right now). And of course GrapheneOS hardens the system in terms of security (e.g. with a hardened malloc or memory tagging stuff that Apple recently introduced as well).
So yeah, it is relatively thin, because AOSP is a huge codebase. But it doesn't mean that it's worthless: this skin makes it more secure, more private, and for me more enjoyable than Android.
I think they mean breaking free from Google Analytics, Google Play Services, Google Play, Google Location Services, etc. Play Services and Play are not installed on GrapheneOS by default, so it is possible to run your phone with just GrapheneOS with your choice of open/closed source apps on top.
I think breaking away from open source Google code is not really meaningful. It's kinda like saying "I don't want to run Linux because it contains code from IBM/Google/Meta". AOSP is a great and useful project. If the day that Google stops releasing AOSP ever comes, a consortium of interested organizations can fork it. But it does not make a whole lot of sense to start a new mobile ecosystem completely from scratch, if one that is great and open source already exists and buys you compatibility with millions of apps.
> They take entire tech orgs over, then only hire each other.
No. It is stupid politics to blame Indians or other Asians for this when they are just following company policy to hire cheaper labour. Like it or not, H1B Asians (in IT) are hired because they can be exploited - they work cheaper and longer hours than their American counterpart ( US companies save nearly $100,000 per H-1B hire as workers earn 16% less: Here’s why demand stays high - https://timesofindia.indiatimes.com/education/news/us-compan... ). Blaming immigrant Asians for this kind of exploitative politics that exists because American businesses lobby for it is irrational. (Also, do not forget that America is a country of immigrants. The H1Bs also act as a "vetted" immigrant pool from which American citizenship can be given). By demanding $100,000 to hire an H1B, the Trump administration has now tweaked this policy to make it costlier for businesses to hire them (and force them to seriously consider AI). But immigrant workers are still cheaper and can be made to work longer hours.
You missed the obvious - foreign workers can be exploited by paying them less. Are there Americans with an engineering degrees that are also willing to work for 10+ hours daily, at $150,000 annually, for a job that usually pays $200,000 to $300,000? That is all the H1B (in IT at least) is about - cheap labour, and a potential immigrant pool. Blaming Indians or other Asians for this (like some others do here) is just stupid politics. "Indians hire Indians" is just Indians following company policy to hire cheaper labour.
This is so much bubble thinking. The average senior developer in America barely make $150K. Most will never see $200K inflation adjusted in their entire career. Hell the way comp has stagnated for software engineers in tier 2 cities - where most work at banks, insurance companies, “the enterprise” - may never see $200K nominally. You can even look and see what most YC companies pay their “founding engineers”.
Yes I know what BigTech an adjacent makes. Been there done that.
Yes, these are probably inflated. I should have clarified these are example figures. Note though the $150k I quoted is a factual figure - there are other jobs in IT besides developer for which H1Bs are hired too. For example, I had system administration or database administration in mind and the $150k I cited is what some H1Bs I know in this field earn in NY today, in telecom or finance. Interestingly, when one of my friend on H1B in Texas became a US citizen, he immediately got an offer with a $50k pay hike from another firm. Another thing to keep in mind is that most H1Bs in IT are contract workers. The outsourcing firm may charge $150K for their work, but the actual salary to the worker will be way less. So there is indeed often a big pay gap when you go through the actual convoluted way this system works.
People always make the huge salary argument. But youre totally right. Your average senior engineer in US is making $130k. These $300k salaries are relatively rare. But people hire H1B to pay them $90k and save on benefits and salary.
The monetary saving is almost never the reason - the inability to push back on whatever crazy half-assed, maybe illegal horse shit that an incompetent manager wants to be done without blowing up their entire lives is the reason they are hired.
Huh? Guess you do learn something new everyday - I've been calling it that for ever too but apparently it is "engine-x" ... (thanks to you, I guess I won't sound like an idiot any more, to some ;).
Do you really believe 16 hours of use daily is not indicative of an addiction? It deserves a headline as it is is a controversial statement that aims to minimise criticism against social media platforms and thus needs to be challenged / debated in society. If social media addiction is not treated as a social problem, the people will not pressure the government to regulate it. That is why social media platforms are claiming that it is only (a personal) problem (of some individual) if some use it for 16 hours while others suggest that it has become a societal problem because its users are now addicts. Social problems needs political solutions to address, and in this case one of the suggested ways is government intervention (through regulations).
Sure, if you want to to be technical and pedantic about it, everything is only a "problem" until clearly diagnosed by an expert! (See Behavioural addictions: What are the signs of addiction? - https://my.clevelandclinic.org/health/diseases/6407-addictio... ).
It is because of the manpower shortage that, credit due, the Ukrainians have come with many innovative ways to use Drones in the ongoing war. But anyone who says Ukraine's military doesn't have a manpower shortage is either ignorant, misinformed or deluded - quite recently Ukraine announced that they would now be recruiting even 60 years old ( https://www.dw.com/en/ukraine-zelenskyy-signs-law-for-over-6... ). You do not hire old people to fight in a war unless you are desperate. Relying on drone warfare for defence however is still a short-term measure because the Russians too are learning from the Ukrainian and adapting accordingly ( https://edition.cnn.com/2025/11/22/europe/russia-rubicon-uni... ).
> The rules mandate that platforms that allow users to create or share such [AI] material must clearly label it. Where possible, they must also add permanent markers to help trace where it came from. Companies will not be allowed to remove these labels once they are added.
This is a good move for political content as deepfake audio and video does have the potential to inflame people and cause violence - politically provoked riots are common in India.
But this is the real concerning part:
> "These impossibly short timelines eliminate any meaningful human review, forcing platforms toward automated over-removal," the group said in a statement.
This can be insidiously used to provide a backdoor to feed AI platform, that data used to profile users and censor them more effectively.
I have experienced this issue some time too - I think if you post some "controversial" comment (judged by many quick upvotes and downvotes) it triggers a "cooling down" period before you can post a reply to your immediate child comments in the thread (or it could be mod-triggered). This ensures you don't dominate the thread, and allows a conversation with other participants to develop. Based on how others react to the comments, I assume it also gives the mods a better idea if they need to intervene. I found it a minor annoyance at first, but have learnt to appreciate it - thoughtful comments (with careful moderation) from a diverse group of people is what makes a community like this valuable.
I've gotten into plenty of flamewars with Dems, Republicans, Anti-Vaxxers, Pro-Vaxxers, AI Luddites, AI Fundamentalists, China bots, China hawks, Apple fanatics, Apple haters, far-right, far-left, pro-WFH, anti-WFH, pro-immigration, anti-immigration, and others on HN.
I just don't care about filtering my opinions and use HN as a way to kvetch and impart some information I may know about.
I also think that the quality declined with the incoming AI crowd but on the other hand I also got older over the last years and increased my own skill level...
They probably meant that Muhammad was on his way to become a prophet and a future leader who would lay the foundation of the Islamic empires that would span around most of the world (while at the same time, Europe's decline had begin).
reply