Intro

I am not getting paid to say anything that is pointed out here, I do not advertise my article to cash-grab you and this is just my professional opinion towards false promises Graphene developer makes in order to lure people into using „his” product(s).

I do not advocate any privacy smartphone OS directly as the security and promises usually depend on some additional factors - factors that I will elaborate in-depth below. However, I list „usable” alternatives that can come into consideration on my PrivacyTools list, the list is designed to give people a choice which I believe is the overall better way and approach.

The article here was not written to attack the developer in person or to make a quick click on his back, moreover to show that the real-world targets people differently and that promises like most secure OS does not withstand any expert opinion and review.

The case against GrapheneOS

Aka selling AOSP with some modification to the kids under the name of security and privacy.

There is a negative history with privacy and security claims from pseudo-experts, in a nutshell:

Selling security and privacy projects for cash is nothing new, we had it with AVs in the 90s and 2000s which could have ended up with less control. The same thing could be happen with GrapheneOS, as the project leader seems to advocate locking down systems based on software based restrictions on the OS level. The weird part is that if your project is secure, you do not need to advertise it as such. It is mainly a marketing phrase that bores me to death, it is like beating a dead horse. Security and Privacy after all should be the norm and not an extraordinary exception.

Funding

GrapheneOS is heavily depending on deals with others e.g. Nitrokey, in general funding, donations, etc. this is explained on the official website, at the end of the day nothing clearly states - I want to do this for a living - which is what this is about. Selling AOSP to kids in an attempt to make a living out of it such approach is simply questionable, we had this too many times and it often turned out to be a false claim that later got debunked after someone with actual expertise on the subject revealed the truth.

De facto the project would come to a quick end without any support because people that are involved and work for Daniel Micay sure as hell also need to pay their bills and why contribute to him if we have AOSP anyway. While others sponsor projects, you do not hear anything from Graphene developers maybe to avoid competition or to gain all the donations for other unknown stuff that is not really disclosed anywhere on the official page nor seems there any transparency report about what is going to happen with the money from cryptocurrencies such as Bitcoin, and other platforms and support methods.

The funding is also in general questionable because cryptocurrencies are supported, while I personally see this as next step, e.g. I use and support the BAT and Monero system, others see it highly controversial due to the environmental impact and because of the sham factor.

Do not get me wrong, I am all for funding in open source but not under bait and obfuscated reason. I also dislike in general to make cash off other projects with some questionable promises and claims without supporting or funding the original project or at least supporting the coding platform that at the end does the heavy lifting.

Open Source does not equal Security

The typical argumentation logic you hear is that open source is more secure, this is a myth. There are attacks on open source and in general uploading the source is meaningless if there are no reproducible builds and verification such as code reviews by independent an actual security researchers, typical such individuals and organisations work for money because no one likes to spend 100+ hours to research attack vectors, document it, propose patches and release those findings for free. Audits are no absolute measurement but they give a glimpse if the promised standards work as intended by letting someone with expertise check your code that you uploaded into public.

There are popular examples when security entirely failed even for open source project as big as OpenSSL, one of the main factors is that the code is provided but not reviewed, attackers then exploit it without revealing information to the public or providing patches. This then can become really quick a serious problem if other projects depend on it. This is why trust-but-very should come in play, however most projects on coding platforms simply never getting any professional support or look at because as mentioned, experts without interest or money are usually not interested in it to do that for you in their free time.

Today coding platforms adopt to new threats and the game changes entirely to bots, bits that secure or attempting to secure your dependencies automatically, warn you, using machine learning and other stuff but that still gives you no guarantee, same like humans, bots can fail, can propose even less secure commits and overall still need a human touch to verify possible changes and proposals.

GrapheneOS is here no exception or special in this regard, since there is no one able or willingly to do a professional look at the project the security and privacy argumentation is nothing but a claim. Relying on implementation from others, as mentioned, can be fatal under some circumstances. I do not see how Graphene with handful of developers at best beats AOSP that is monitored, inspected by more people because even with a hardened system you still rely on the same fundamentals, such as encryption, verified boot, things that Graphene did not invented, audited, reviewed or improved at all.

Key factors:

• Open source is in general not more secure, however the coding platforms can help and offer guidance, bots and human reviewing. Sadly, in most cases the human review process depends on effort, willingness to audit and other variables.
• Closed source does not equal insecure, some systems that work since decades are secure. You also can still inspect and reverse engineer closed products, however it is more effort and requires usually more skill for RE.
• Providing just the code and upload it does not imply automatically privacy or security. If you publish the same app as closed source it is after all still the same app and code, the game is more about trust and how hard or easy you make it allowing others to inspect it.
• Lots of open source projects to not even provide reproducible builds, as of today such measurements are not the norm and more an exception. Most coding platforms here miserably fail to provide a quick solution for developers to make it the norm. I complain about this since decades.

It is always DNS until it is Money

It is always DNS right, well not always in this case it is about money, security is only the bait. Like with most projects these days. Privacy this, privacy that install and support me because my farts smell better than yours while I provide nothing but my words as evidence, until someone actually does an review.

Commercialization can be tricky because there are some rules that need to fit the requirements, so what developers usually do is to make deals with questionable promises to lure people into some beliefs that are entirely made up, like brainwashing you thinking this is actually reviewed and approved by experts, this is not the case. If you partner up with others your legal project might also change, depends on how the deal looks like which protects - your - works more, legally spoken.

But whatever, the underlying point is that I find it weird that developers sell others people work, in this case AOSP even boldly claiming that its practical another OS just because modifications are made on the OS level part. I call it scam, the difference is that such money begging apparently gets more acceptance if you pretend that everything can be obtained for free, but then again why beg for money, because we all know what is going to happen when the money flow stops, the project would be dead and he developer actually would require a real job to pay his bills.

Maybe the world needs less forks and more actual approaches to solve underlying problems and not something to promote yourself, just think about it. How does solve fundamental problems like e.g. ransomware, it just does not solve it at all. When it comes to real-world problems none of severe issues are addressed, because proving solutions is much harder than tweaking some weak settings and we all know this very well.

I personally would have more acceptance for such forks if the intentions are written down on the website which is not the case, the FAQ does not cover all points and the question remains open why everyone suddenly should buy and trust Google entirely while on the other side you try to provide something entirely for a community that hates Google. Some could argue Googles security is reasonable secure, others would argue that no one audited the chip and how would software protect you against spying chips if the attestation has no low-level access to hidden OS and other controversial implementations, especially not then when the users not even has privileges to inspect the OS itself. Google and other players like Qualcomm at the end also only play the game for money and improve their chips from generation to generation, but there is almost no transparency, except papers that are mildly put so complicated that it requires years to study them, and then there is a major problem that there exist no equipment to actual verify anything at all, you can run software but we saw first hand that software can be manipulated, we had the story with VW Volkswagen and the manipulated emission scandal.

The official Graphene website lists dozens of sub-domains and additional domains, claiming this is a hobby project when you need to pay 100+ dollars alone for useless domain hording shows that the developer has no clear intentions to play with open cards. The project is clearly designed to make profit out from it and as mentioned, the moment no one donates the moment the project will be closed, this is nothing new and in fact understandable, however I judge the developer once again not playing with open cards and advertising his intention for what they really are - again, he wants to make a living out of it, nothing more and nothing less.

The Apple approach to lock down the entire OS takes away freedom

Daniel Micay seems to be a big fan of Microsoft, Apple and Big Tech, how else would someone explain an approach to lock-down the OS so that you barely can do anything without it except breaking it or cripple widely accepted and trusted apps. This is not freedom it is the opposite and what I call the - Apple way - because the user can basically nothing do without crashes, or apps not working as intended under the name of security. You basically limit everything you normally could do because it is cheaper than coding own alternatives that address it. Breaking the web or just reducing the attack surface by entirely removing functions is not security, it is controlling what the user could do.

I think this approach is nonsense because if you take everything away then you cannot use the OS how you want. Starts even with little things like missing customization.

The more you use or abuse AOSP the faster Google will lock everything down, the problem is not only due to security reason also because people with modified ROMs requesting support on Googles end which causes massive headache for them. This usually ends up with more restrictions for everyone. I would predict at this point that one day Google will lock down everything so tight that third-party ROMs, regardless if based on AOSP or not might not be able to survive without explicit approval from Google, which is controversial on its own because some could see it as marketing position abuse, while others argue that it defends against infected malware, infected ROMs etc. However, I like to point out again that I am not a fan of the Apple approach because it entirely shifts reasonability and access from you, the user, to Google which means you need even more depend and trust on Google. Besides privacy implications this might also makes users believe that they are all secure while in truth they are still, or even more vulnerable to other attacks because no one really cares and will start shifting the blame entirely to Google, in case something happens.

GrapheneOS supports directly more e-waste

GrapheneOS depends mainly on Pixel phones, if Google cuts the plug for support you are forced to buy a new one that continues to get official support, such a model supports directly more electronic waste. The device could run perfectly fine for decades with enough update support. This is a behavior I do not like in society, throwing away electronic devices just because the vendor decided to stop the support.

During the chip shortage, which still continues to run as time of writing my article, the electronic waste and recycling factor became more and more important, not only because resources or availability also because recycling Pixel phones, among other brands are still a big issue which also has some health consequences.

Assuming GrapheneOS wants to go away from the Linux Kernel, which he indirectly already indicated n Twitter I see maintaining more devices even harder to impossible because a lot of vendors entirely lock down their hones these days that prohibit unlocking the bootloader entirely. The law must step in and change this, in a best case scenario the vendor should held reliable and must be forced to open his entire source, if not directly after release then at least after the official support has ended so that the community at least gets a fair chance to continue supporting it.

Typically little minded response

This is typically a response from people that have no idea about the environmental impact. Most politicians have multiple phones, one private so they can choose whatever they want and one that they get for their job, often a BlackBerry or special prepared phones, or iPhones because of their closed eco-system.

A typically user ditches, statistical spoken every 2-4 years his phone, or they get a new phone every 2 years, users getting an automatic replacements or a newer model, often part from their contracts with the ISP or they get a new phone when they switch to another contract, in such case you get a welcome present, often a router or can choose between hardware, smartphones and so on. It should be pointed out that lots of people keep their old phones, to collect or sentimental reasons but they typically do not actively use it anymore. The norm is typically that they give it away to other family members, friends or sell it, etc.

This has nothing to do with security, the underlying point here is that no effort was put into consideration that recycling gets even harder and that resources are limited, which means they having an small percentage of impact on the climate.

A 10 years old phone works fine and just because there are new protocols are not not automatically more secure or private. In fact 5G is as vulnerable as 4G. Old networks usually also getting shutdown after some time.

Nutshell

• Environmental impact
• Resources and recycling problems
• New phones often use the same insecure networks, claiming here new is always better is wrong. 5G and the upcoming 6G still suffer from SS7 downgrade attacks.
• Newer networks are not automatically more secure or private
• Govt should enforce better laws
• Developers as well as OEMs should put more effort into recycling, components and support.
• You could keep your old device regardless if you do not use it as smartphone anymore and use it for self-hosting something useful.

Better approaches and models to reduce e-waste

We had projects that stopped because of funding problems, such as Firefox OS that worked on Smartphones and Tablets - or this was the idea anyways -, it used the Linux Kernel and would work perfectly fine on older devices too. Mentioned project mainly depended on the Kernel and if you can workaround device restrictions or not. Today Ubuntu touch and other systems exists, IoT actually has many Linux Distros and Kernels you potential can use, why not on Smartphones, well because people just love to sell AOSP because it is reliable but nothing ever changes if you not start at some point going your way and create branches that benefits smartphones directly. Do not get me wrong, Linux on smartphones has a long road ahead to make it more usable and attractive to app developers but such models are better because you can boot even older devices with considerable secure kernels - assuming your device is supported and you can boot it - and then you have the benefit of getting support, security wise from within the community instead of depending on Google and your Vendors will to support the device for x years.

Another alternative would be to directly create a branch in AOSP for mainstream, hardened, etc so that everyone could choose the branch he wants to fork and then compile the OS. The benefit is more people watching the project and everything gets contributed directly to Google, of course some could argue that it benefits only Google and the other vendors that use their ROMs based on that but since there are practical not real solid alternatives this is better than depending on yet another third-party to get the job done.

Here are two interesting approaches and projects

• Fairphone
• Shiftphones
• Vodafone started a program to reboot old phones

Approaches like this are not perfect, there is the open support question but if you think this trough you realize that a normal Linux Kernel can theoretically be used for more than 4-5 years, assuming you can easily manage to install and boot if without restrictions.

Later GrapehenOS announced to work with a vendor together to sell phones with the hardened OS on it, which benefits him money wise on behalf of the environment. How this is a better approach or better than Google is without any logic, he just want to cash-grab the kids to sell his product, a product that highly depends on Google and their sponsorship and their Team for AOSP. If the would donate or sponsor Google and their Team or some volunteers in return to give something back is not disclosed.

He even suggest to buy an iPhone if you want support for more than 5 - 6 years, at the end no thanks to GrapehenOS thankfully the law might change to support 7 or more years of device support, this demonstrate that you better should vote the correct people that actual influence things on a broader level to benefit everyone and not depend on promises or third-party entities.

Apps

GrapehenOS offers some apps such as PDFViewer, the apps are not special at all. In fact they are not inventing the wheel new but they do not have to, my point is that such apps rely on existing libraries such as PDF.js and here is the problem, by default scripting allows attacker to abuse it the entire security stands and follows if scripting is allowed and enabled or not which dramatically limits the abilities for attackers and malicious app to compromise the security. The reason why I suggested in my Windows times to use SumatraPDF because compared to other big player PDF Viewing apps, it had no script engine, only a small theme engine that could be tweaked and configured, my point here is that if you depend on other projects you heavily rely on factors such as

• Supply chain security
• How often is the lib update
• What modification you did to the lib in order to ensure that it covers potential leaked and public disclosed holes

In other words, other apps that offer similar functionality are not better or worse in this example. The viewer probably only does a handful tweaks such as removing unnecessarily permissions, however other apps offering the same or you can ask the developer, assuming there are some obsolete or not needed permission declared in the manifest, to also change that, most other app developers from existing app solutions typically fulfill your pull request or change it if you argue reasonable enough. The point here is, why offer apps when existing solution used by more people offer the same, or similar approaches. Alternatives are fine but I think the developer is over his head with so many side-projects, which usually ends-up with usability issues or requests that do not get merged fast enough which might end up that the user installs or switched to other apps regardless what the developer claims here - on paper - is more secure.

My overall points are

• Apps typically do not reinvent the wheel, using bigger libs that might be more attachable, or more secure, this is up for an debate. Some argue that known libs that are used by more are more secure because they are inspected by more people, others say it is a bigger risk because attackers typically attack things that is mainstream or has lots user base, simply a mathematically thing. You theoretically have a higher chance to gain something from it, pure statistics.
• Many side-projects might impact other things that some see as important, merge requests, or overall usability and breakages due to additional hardening.
• There might already exist similar apps that do the job perfectly fine, those apps could be improved instead of offering your own. The benefit is that others maintain it, you maybe on need to provide some patches but can focus on more important things.
• Android changed and permission modal based exploits are harder these days, people that use newer systems got more abilities and review options regarding permissions. In short you can review permissions more easily, it is absolute not perfect but I give Google here credit that they try to constantly adjust the system, there still needs to be more work done especially within the store to give us more review options and more clear indicators but I predict we get this one way or another soon enough.
• Sometimes you are forced to work with apps that depend on Google Play Store, Amazon or Samsung Stores, those app might not work or detect that you are on a modified OS Build and then they refuse to work or you need root to bypass checks. On paper the idea of isolated apps and sandboxed play services sounds good but in the real world this approach might not work, hen your assurance company requires apps that just do not work or you need root bypass modules then the best OS is pretty much pointless. The law and not the OS developer must here step in an force such bigger companies to provide foss alternatives that are delivered directly trough coding platforms. GrapehenOS simply cannot workaround this and never will be, so security is worthless if you are forced to work with those apps and then there is the question what those apps collect and transmit, a firewall or data faking or spoofing apps are here pretty much not a workaround because some data just cannot be faked otherwise you might get in trouble.

Missing Qualification

• GrapheneOS Daniel Micay is not an expert, he is self-proclaimed one at best, anyone can call himself security researcher, however actual researcher in a business require by definition an PH.D. in order to get official recognized as security expert, which Daniel Micay does not have. You will not find any actual researcher in security in little nor big tech without such tittle and certificates because otherwise how would you make sure that he is an actual expert without any background qualification, talent (even tho his official website does not list any HN account) alone is not an indicator for qualification because a lot of other people have talent too. Everyone at the end can proclaim whatever he wants, but showing expertise, as he is still pretty young, is entirely a different thing, reading documentation and then apply best practices into the OS that you did not coded yourself is something even a beginner can do with some basic skills.
• No background in the security scene whatsoever. No one heard his name in the scene, he just introduced his OS and that was it, there was nothing before from him in any forum, platform, and I doubt he ever worked for the big players at all which could give him past experience that he can use and utilize. He - only - had some contact on coding platforms, once again everyone can do this and this is not really an user engagement per se as you can submit patches without debates on your own, without any interaction at all - assuming your code or changes are well documented and no one asks about it. I would also not count Reddit posts as real expertise in this point because we all know that Reddit users are typically - mostly, not always of course - beginners and not experts.
• AOSP has more researchers looking over the code. Which makes it preferable over any other mod, or approaches. Same goes with the Linux Kernel.
• Daniel Micay often acts childish if you does not give him as much credit as he wants from you, which is unprofessional and shows he is not a team-player or someone who has a lot of experience in working hand-in-hand. This also displays with his ex-partnership with CopperheadOS and the rant against it instead of letting it go, Daniel Micay tries to undermine the project to promote his own. The statement about outrages business model is also unclear, both ways, selling AOSP on per-update basis and selling it to third-party vendors is nonsense argumentation because both systems have pros and cons and the goal is the same, to make money. The update and funding argumentation is also a bit unclear, how would someone know the financial status of the competition of they do not disclose it and how would faster updates lead to more security, this last point is up for an debate but supply chain based attacks showed that outdated but proven software might be more secure than quickly adopting every new change. This is marketing phrase without anything behind except respelling what the mass things might be more secure without even mentioning potential drawbacks that actually exists. I do not defend or want to debate this but I find this part weird, not only because no proof is given but why would you fire back and make things look worse and deescalate?!
• Mental problems with Daniel Micay who makes things up and begging for money results in basically no trust. He also seems to have no clue how Kasperskys AV really works and such people dare to talk about security.
• While on one side freedom is advertised, the freedom is not so much given in public forums such as the official subreddit, as removal reason you typically get that you should take it to the forum or Matrix chat, but why should I re-post the same on forums and instant messaging services that I might not want to use because various reasons. I think public forums are a good place, it is also harder to hide evidence because a chat is quickly deleted while as you can easily archive a Sub-Reddit submission via Wayback machine. The main reason might be to hide any criticism and feedback that the team or developer not like to get exposed open in the public. The overall point here is that criticism, feedback and ideas are suppressed and shifted away a bit from the public, after all Reddit is a public place especially designed to make people aware and share legitimate feedback.

But Mr. Snowden said GrapheneOS...

First of all Snowden does not use the OS himself, in fact he said in some interviews he takes out the SIM card or even the camera module, which is the best you can do. No hardware that can be attacked results in ultimate security, this is best practice and not even new or a special advise, this is security 101.

However, in September 21, 2019 Snowden said he would use GrapheneOS as basis, his motivation why he said that or if Daniel Micay contacted him and asked him to advertise it is unclear. Another possibility is that a - fan - could have contacted or made Snowden aware of the project, at the end we will never know the truth.

This story quickly landed on Wikipedia to pretend Snowden would advocate it and maybe wrongfully imply he uses it himself, there is no proof for any of the claim as of today. Another theory is that some security or privacy advocate made Snowden aware of the project which is highly likely because such individuals tend to spread their finding quickly on social media. It should be pointed out that this was years after the NSA leaks and years after 2014 when he started the journey. In meantime lots of stuff changed, as well as AOSP itself added countless security measurements, the changes are also unrelated to any NSA leaks because everyone OS usually evolves regardless of what actually happens in the world.

At that time in 2014 there was practical no competition to Stock ROMs, there existed some one-man-developer projects but Snowden cannot suggest such projects because if the funding is unclear the project maintainer can close it at any time, so claiming here to say Snowden suggested the best is a bit of a narrative point of view in order to support the GrapheneOS. De facto we had in that time not much of alternative projects who actually want to do this for a living, which is what Daniel Micay wants to do.

Second point, Snowden is not an expert in this field, he basically has no actual qualifications to advise what people should use or not, besides we do have the same information after his leaks then he has, of course he did not leaked everything he mainly was a contractor and consultant and was and still is not involved into the smartphone market nor is or was he a security consultant per-see. The advise he gave are all not new or groundbreaking, this was all known before any of the NSA leaks, that e.g. GSM is insecure and vulnerable etc. There are lots of other people working in national security and none of them advocate a specific OS because such recommendations are not professional nor acceptable for broad mass of people. He finally lost all my respect once he introduced his app that fights surveillance with surveillance which is a nonsense app and approach, not only does this stand against what he judges himself about mass surveillance also it is not practicable, drains your battery and depends on the fact user need to be aware and install such an app instead of directly addressing this in an OS. Snowden had bunch of nonsense approaches and controversies that my conclusion is that he cannot be called a security expert who is qualified enough to advise others, or at least not in the smartphone business, mainly because his lack of experience or missing interaction with other developers and the community. I could go much deeper here about Snowden but this is not the topic, I however wanted to expose that he is not qualified enough, which is clearly proven.

Android evolves with or without Daniel Micay

There is a killer argument that Daniel Micay contributed to AOSP, first of all anyone can do this and it is not a special thing. The Android project is open and others can accept or reject your proposal and commits.

Second, because nature of the license you are forced to hand over the source if you do modifications.

And last but not least, the Android project has already more researchers, actual experts and contributors, claiming here that some small contributions are a game changer is a claim that cannot be verified because the code constantly changes, the OS responds to new or old existing threats and no one can say that the changes he contributed would have not landed one way or another in the OS anyway by someone else.

Claims, over claims - All unproven

What GrapheneOS does is to apply best practices the developer found on the internet, implement it and then claim security without any actual proof that this is effective enough to hold against an intelligent hacker, an entire group or against professional funded groups that have the tech, equipment and knowledge to exploit known best practices, there is lots of evidence that such professional hacking groups exists or that some of them are even sponsored by the government to hit specific targets. Practical everyone can harden every single OS this is no voodoo nor special lots of developer did this way before GrapheneOS even existed e.g. on XDA and other known platforms. Locking it down, break everything and then claim it is secure is not a challenge at all. It takes me approximately 2 hours do modify the kernel to do that. This is not security it is limiting the users ability to interact under a false promise.

GrapheneOS never had one single audit, never had one single actual security expert who did free or professional code review on a professional level. There is de facto no article, just nothing that proofs any of the security or privacy claims whatsoever. Not only because an independent audit is expensive but because the project uses Googles monthly patch policy, which means every month the AOSP gets updates and the game might changes in the meantime because why should you pay for an audit that is maybe already outdated by the time you need to inspect and submit suggestions because Google already released security fixes that you adopt.

GrapheneOS does not protect the user against sophisticated attacks, such as machine learning, data ex-filtration or e.g. spear phishing which makes over 90 percent of current attacks, not to mention social engineering as well as other techniques that leak your credentials. No one really gives something anymore about infecting the OS to crash it, the times are over, it is all about stealing your data and Graphenes hardening does not entirely help here, at best it can reduce the attack surface but if you are a target and work against multiple attackers or a collective I doubt this would withstand. Opening eMail attachments with malware is still one of the first and big ways to compromise the OS. At the end you are weak against this, with or without a hardened system and spreading knowledge is better than claiming a hardened OS would protect you against such things, the knowledge comes above installing apps or systems because you already reduce the surface if you are ware of certain key-factors and what to look for. Things that the OS cannot and never will cover because this is just not possible, but this is what an attacker would try to abuse in the first place.

The inner ring of GrapheneOS depends on systems that are not coded by GrapheneOS, such as secure boot etc. Keep in mind those systems are not perfect too. But at the end the security level is the same and there is no code commit that somewhat magically enhance the process here, because lots of actual security researchers and coders did here lots of research, testing and this is why such protection systems got implemented.

Security claims that are unproven are worth nothing, I come it with AVs that daily or hourly getting signature updates, similar things happens here, AOSP gets monthly security updates from Google and others that contributed to such patches. The security mostly depends on this factor. It actually reminds me of the Telegram crypto challenge - come hack me - but I change the keys every day. That is not security, it is a false premise to lure people onto your side in the hope for funding, support etc.

Nonsense respelled about Root

The rooting is insecure nonsense is spread because of the earlier days of rooting IoT devices and how this was approached, typically with closed source apps such as Kingroot, 360 Root, Framaroot, Baidu Easy Root, Towelroot, One Click Root und Mgyun, that are, depending on your viewpoint malicious by itself because no one could quickly review it without decompiling and reverse engineering it first, which is a lots of effort or more than when the code is already open. I am not going to say or imply that FOSS is more secure, but the core point of this statement is that in that period of time sahdy actors delivered repacked root apps that had malicious intentions or even manipulated binaries in it that a normal user might not b aware of or an AV check returned nothing. There were also entire fake clones of those apps under same name repacked with malware on the internet, often the infection started here.

However, the game has changed, Android evolved which made rooting harder and as of today we only have practical two methods left, both are open source. Magisk as well as Chainfires or LineageOS implementation of an rooting solution. Both approaches and solutions are open source, the original developers providing binaries as well as entire APKs - the modules that are considerable more secure than some random website or mirrors that spreads an unknown solution which is mostly copy and pasted, repacked with malware and that is practical it. The point here is that root got more acceptance, reviews and the code is open, which does not mean it is automatically secure but researchers can directly verify and check it. Assuming that root drills holes into the OS people could, with some effort, review and fix it.

There are also approaches to harden root solutions with e.g. PIN protections and other things that was not originally there, such solutions can make it harder to tamper with root assuming you installed an malicious app that tries to invoke an isolated root process. It is of course not perfect but at the end which software is absolute secure - none - until proven otherwise.

However, the media still spreads outdated information about how insecure is is, which is in the real-world not the case as most root solutions log access, restrict access or add additional layers. The rooting game actually got more open and it could be enhanced by implementing it directly into the OS and then adopt and make it part of the OS, security exploits against the OS or the rooting system then could be patched like you would patch other security holes, this could be made as an optional mechanism for those who want to gain full control.

Less evidence exist that root is per-see insecure, most evidence depends on malicious apps that exploit or undermine the trust system by e.g. injecting additional code into it. This is actually a problem but solvable by fixing the root process or harden it, prevent malicious code like it to be executed in the first place or build strategies to disallow known drive-by malware that comes with such malicious apps.

If you have no ability to root or gain privileged access some people even a bigger target, because of it. This is the opposite of security because what does the user do if he has no integrated option to gain root, well he searches the internet and might install random app or anyway ends up with the mentioned two or three approved systems. Malware typically starts here, people search and install random apps but eliminating this part could solve or reduce this vector a lot.

It should be pointed out that a user who is already privacy oriented inform himself anyway about possible risks or revoke root privileges once he is done, or even deactivates or uninstalls the root app. I see here less of a problem giving users control over the procedure.

Killer argument, but root could lead to malware that cannot be removed or starts with the boot mechanism.

Actually there are approaches to bypass secure boot but most of them got quickly got fixed with newer Android builds, the same logic applies to the root enclave that also could be patched to make processes more secure. In any case, you learn from malware and it usually once again starts with installing malicious apps in the first place, something that cannot be entirely covered by the OS unless you take away control or work with whitelisted app approaches. The underlying point about trusting secure boot is that it can makes sense to break it in order to provide support for newer system updates or an entire switch to an open system. Of course the implications are that malware can abuse it, but no one can guarantee that malware is not already implanted and hidden in another partition that boot verification cannot check or access. Just to further clarify that Verified Boot and Secure Boot are both ways to address a similar concern, which is boot security. But they apply to entirely different computers and computer architectures, take different methods to accomplish their end goals but the underlying statement is that this is no absolute counter measure as shown with some examples. In Androids case every partition is verified by Android Verified Boot and the verification data is stored in /vbmeta partition. The dilemma is that if an attacker prepares or captures a phone and replaced it with a malware infected image that is signed with a stolen key, you would boot the device, open the attestation app and then see it was tampered with by then the damage is already done, of course this scenario depends on some variables but it depends on the effort. The thing is not everything is disclosed on public and often it takes years to spot and reveal attacks but by then it might be to late.

Nutshell

• Most malicious intends start with phishing and manipulated malware apps.
• All reputable root solutions are FOSS as of today. People simply do not trust apps no one ever heard about or without reviews or source on credible platforms.
• Injection of code can me security critical but only if the first point is given, the coding platform here must provide reproducible builds to ensure security, as of today this point is still not given and more an exception as the norm.
• Exploits often depend on one of above mentioned 3 points. The software part itself is not more insecure as crucial parts of the inner Android systems, that also could be abused once you got full access. The basis for the - root is insecure - argumentation relies on the OS not protecting you enough against malware because security checks, once root do not covering that part and you see app breakages, SafetyNet warnings and failures etc. An implementation directly could cover this.
• In today's world ransomware, phishing and data ex-filtration are bigger security risks than theoretically physical access scenarios. Physical scenarios depend usually, and only under rare circumstances, on how the user handles his device e.g. avoid taking it with you on activism parties, political events etc. After all it is easier to swallow an sdcard of your camera than the entire phone when it comes to drastic measurements.
• Most apps would not require permanent boot, which means root could only be given on demand and after user approval.
• The real reason why no rooting method is implemented in the OS might be more because support reasons, if you brick your phone or do something that is not officially supported then this might causes more problems for Google, their moderators etc. This is more a political motivated decision, but we assume that even beginners only follow XDA provides guides that are tested, include a clear warning - which they usually contain at the top - and that the user possesses a minimum on skills.

But but GrapehenOS has benefits over normal AOSP

I doubt such claim a lot, this moreover depends on default settings VS alternative settings chosen as new hardened defaults and how knowledgeable the smartphone user actually is. In truth this actually hardly benefits any user that is not already knowledgeable or carefully. A normal average user gains knowledge pretty quickly by practicing various techniques that are well-known, such as do the normal background checks such as permissions, network activity checks and so on, or in other words do some small work which starts with obtaining information on the internet etc. However, in case the user has enough background, hes simply can use GSI, the bare naked OS perfectly, compile it, and be happy with it. The minimal work afterwards is quickly done with some scripting, often the community provides such scripts in form of MagisK modules, user scripts etc. Things you can optionally execute trough the normal GSI and get the actual freedom out of it. Additional hardening is normally not needed because as mentioned the privacy oriented user just do not trust randomly apps that are not FOSS and reviewed by the developer and the community. The rest is already covered such as FDE, profiles, app permissions, reviewing apps and so on, stuff that is not invented by Daniel Micay nor did he invented new and secure protocols that replace old and vulnerable ones that the user could choose from.

The benefits then itself are once again only best practices, de facto there is nothing you could not do yourself without depending on another third-party identity such as GrapehenOS.

Some of the specific features that GrapheneOS offers are listed as nutshell over here.

• Faster updates sold as feature. First of all just because there is an CVE does not mean it is abused in the real-world. Second just because there is no CVE disclosed does not mean there are none. Third the numbers of CVE are irrelevant in a security discussion as all argumentation based on this depends - usually - on other factors - assuming is is not a zero-click exploit. There is sometimes, not always, a lot of media attention about some holes that are in reality less of a problem because your apps or your OS was not affected or you can simply mitigate it by updating your existing apps. You can compile AOSP yourself if you cannot - for whatever reason - wait for the next major release. The developer here provides zero evidence, because there is none, that just because it is lets say 2 weeks not immediately patched automatically a risk for the user. On the other side he cannot provide any evidence that just because there is no public CVE disclosed no hole or someone who sells a 0day.

• Additional 0day protection. The developer once again seems to be inspired by Microsoft, the page sounds like Microsoft wrote it with lots of promises that are unrealistic, of course zero proof here and most of those protection mechanism are already implemented in AOSP. The benefit might not exist or if only on paper. Same like Microsoft claims that Windows Defender protect against most attacks, swiping under the carpet that the default settings are weak or that in reality not everything is covered because attackers quickly can check their malware against the signature and engine. IMHO it is pointless to point out additional mechanism and then ignore to say that most if not all are already in AOSP integrated. In particular his writing on this part are vague and without any technical details in it that makes the promise more trustworthy.

• Disabling 2G and enforce LTE. This feature is already added in Android 12, so the hardened OS provides here nothing really interesting. The reason why this option existed in the first place was backward compatibility, meaning in countries without 4G or less coverage you at least got the ability to call for an emergency. 2G and 3G also gets disabled at some point. Removing this option is potential problematic, of course this depends on your region and circumstances. Assuming this is meant feature for e.g. activists that might be victims of cellular tower attacks that are deliberately compromised, then there is bad news too for other networks because LTE is also fundamentally broken, regarding privacy and security. Going back to our previous activist example, the better advise is to leave the smartphone at home, use a camera without any networks, which demonstrates that the information is more valuable than such hardened OS. No network, no attacks possible and you can swallow, destroy otherwise any potential evidence aka the SDCard that might contains any information. Of course this is an extreme example but using such practices, assuming you are a high threat target is better than to rely on a operating system and the protection mechanism, because the police might can confiscate your phone and keep it as long as they need, and they have all the time. If that scenario is realistic or not as real-world scenario is up to you, there are popular examples but the overall point here is that there are easier methods to protect your privacy and security as activist, with dead simple tricks and guidance such as using a normal camera, taking out SIM card etc. Stuff that is known or can be obtained quickly and spread to others.

• While open source is not automatically more secure a weakness could already be that GrapehenOS discloses every part of the code and documents all mechanism, which gives an potential attacker to already know what he is up against. This point is a small point but it is one. However, since this is a general point that affects pretty much all open source projects I tend to be neutral on this point. However, there are studies almost every year saying open source is less secure because of this reason and mainly because of blind trust.

• Remote attestation, is not unique at all and is questionable. If the device is already compromised, your attestation does not prevent the delivery of the attack, it only shows a warning that something might be compromised without pointing out what exactly, when it happened and you need to be aware of it. The attestation only works if you actually do the checks, checks that usually are manually executed trough an app, interface, shell etc. Google does such checks in the background and it is interactive, which means you get directly notified. This is no matter how you see potential controversial because such checks are often without explicit user consent in the name of security, something that some people wrongfully call spying. Similar like an anti-cheat system that checks your processes, pc etc for modifications, known cheats etc. To make it easier to understand. In other words, it basically checks some parameters. In general attestation comes with some concerns, the implementation is here essential and if the user can rely on the chain of trust or not, e.g. when the device has embedded malware then the attestation might show wrong results but this is a sophisticated attack scenario. If any attestation makes sense on an already closed system is also questionable, it is like locking the door from the outside and then leaving the user in the room that can check manually if the door is still locked or not to make him feel more comfortable.

• Backup app, not a GrapehenOS invention nor is that coded by the developer himself. You also can install the app on every other Android system. It is simply preinstalled. There are also dozens of other solutions, some even faster and more elegant trough shell, that is overall easier to execute... depending on your own skill-set of course. However, it is questionable why someone should backup his OS this way because for normal user data you can just copy it manually and for the OS itself it is questionable why someone want to backup an potential - already - outdated system. It would be better to install an up-2-date image and then just only import the user data.

• Sandboxed Google Services. This feature was added after lots of breakages and complaints from within the own community. First of all play services are already sandboxed, which makes the term misleading. The application runs with several protection mechanism, runs inside a considerable - more - secure folder from other apps and there are other security mechanism in place. What is actually meant is not handing over specific data, as so-called sandboxing, over to Google by isolating the network infrastructure or parts of the layered model on how Google apps approach the internet and their ability to interact with Googles servers. This is different from visualization and therefore not sandboxing, apparently the developer does not know the difference between app isolation and network isolation and puts it under the marketing phrase of sandboxing. The developer fails to point out nor does he mention that most if not all so-called privacy invasive Google Play Features can usually all enabled or disabled at will. Re-spelling mass media half truth on behalf of Google simply helps no one, instead you should tell people that there are options, how to use them and why they exists in the first place. Telemetry aside, most third-party apps probably send much more data back to unknown servers, but the argumentation is pointless anyway as the developer does not backup his claims with evidence at all, in particular, when, how often, what etc Google Store as well as services makes so privacy problematic compared to other third-party apps or other eco-system related apps. This is simply unprofessional and only spreads a mass psychosis of - Google is all evil that is often unjustified and more to make clicks rather than providing actual evidence, especially given the fact that the Store, Services and other stuff constantly and very often gets updated in the background. Universally claiming everything is bad without anything is not helpful and some features that might be by-design problematic can be quickly turned off anyway, or submitted metadata are anyway not enough to compromise you directly.

• Support for specific banking apps. This is also nonsense approach, first of all such banking apps already have their own security checks in place that depend on SafetyNet and other mechanism coming once again from Google to ensure no tampering, or that they can be executed on e.g. rooted device without any attestation. This is more a precaution rather than security, as you still can use a rooted device without that you automatically be compromised or wrongfully assume you are directly more vulnerable.

• Removing the background clipboard monitoring functionality. This is best practice and nothing that could not be added into the AOSP, it is easily adoptable. I would not call that a security feature, assuming you do not store sensitive information onto the OS, it would make no difference. There is also the fact that security apps or lets call them password managers automatically wipe the clipboard content after a predefined time period. An attacker would require that an malicious process or app grabs the clipboard content, once again this starts and ends with malicious apps.

• Removing network access to specific apps or introduce apps, changed ones from AOSP with removed permission modal. Again this is also badness enumeration as people think or use such a system to think this introduce an addition. which might not be the case, depending on what malicious app the user install. The better approach is to pre-install secure apps or work with whitelist approaches to avoid the user can install questionable apps in the first place. It is again only best practice and heavily relies on malicious apps, lots of open source apps are reviewed and only request minimal network access or no internet access at all.

• Removing sensor access on per-app basis. Same as above, no malicious app installed no harm can be done. Besides this can be limited within the Android OS, which depends on the Android build.

• Camera indicator. This is not new and used in some laptops, it is optional and ineffective, because the detection can be bypassed, it stands and falls again with the malicious app and the Android Build, some newer Builds have this integrated already by default.

• Changed defaults. This is up to a debate, depending on how your own skills are you quickly can do it yourself. Turn on airplane mode, change all settings as needed and then turn off airplane mode once you are finished. Android does not use strongest possible settings because it might break usability, in that regard no OS that is used by 1 billion people uses such approach. This is just normal to avoid complaints. Claiming that changing the defaults is enough is questionable, a hacker can see - based on the source code - what was changed and build strategies around it. It is, as above mentioned target shifting approach.

• Vandaium, hardened WebView. You actually can install and use Beta WebView if you want latest versions, if that really helps is up to a debate. WebView is used, trusted my millions of apps and people, hardening and sacrificing security because you need to keep up with the upstream changes is questionable promise regarding security. Also unproven I might add because Vandium is not used by 1 billion people. [Since 2017 WebView is hardened](tab:https://www.xda-developers.com/latest-webview-introduces-isolated-renderer-process-and-in-app-safe-browsing/ and isolated) because of past experiences and security problems, this mainly affected - at that time - older Android versions, once again the game changed, Google learned from it and fixed it with newer WebView versions as well as restricted access in newer Android versions. It is questionable how modifications from single developer would beat an entire Google Team that works and improves WebView constantly. The self-proclaimed expert provides no examples, reviews or code to show why this is preferable over Googles WebView version that is inspected by a lot of more people.

• Encrypted backups via Seedvault-App. Afaik the app is not be coded by GrapehenOS, my approach is to not work with backups on IoT devices at all and even if I backup only personal data, they should never be stored on the device you carry with you because losing it is a real problem. Encryption can here protect but only as there is no exploit or attack found and is no absolute measurement that implies best practice, that remains to not do backups and not store sensitive information on the device at all. If there is reason that something is compromised you should wipe everything and re-install.

• Update protocol reduced metadata usage or information leakage to servers and can be used via VPN or over Tor. Well, you can also disable auto-updates and then manually install new images. Setting up an GitHub RSS-Feed is not hard, this approach is questionable. As the internet always sends some specific information it, limiting the amount is a neat approach but this also can be easily adopted to AOSP. Security benefits are none existing, it is more a privacy consideration but GrapehenOS provides here no evidence what Google uses, might sell or not sell or how it directly compromises your privacy if the statistics are anonymized. In most cases the update connectivity checks and background checks are used to obtain some anon stats and not to expose the user. This also depends on how the update-server works, GrapehenOS provides no evidence on how this can be abused to directly compromises my privacy, it would also not be possible to provide some evidence beyond e.g. a Wireshark analysis. Shocking news but some websites you visit might expose more, especially ones with surveillance ads.

• Going away from a trusted Linux Kernel to a micro-kernel. Apparently the developer wants to go his own way, this however could be fatal. More people watching and inspecting the normal Android or Linux Kernel and complexity alone is not the only factor that possesses a risk, you might also break device support, end up with more work and you constantly need to monitor and audit if the security aspect is given. The normal Kernel might be complex but it is considerable proven to be a solid ground. System that tend to go their own way often fail because later it points out that there are security related implementation flaws that only getting revealed later, given the history that there are no audits at all provided, not even code reviews it is a questionable move to then still continue to claim it is more secure than accepted standards.

• Wiping logs after x days, is enumerating badness. If the system is already compromised or the attacker has actual physical access he can read-out the logs. Dumping logs via adb is done in seconds. Black-listening or wiping it after x days unlikely prevents an bad actor or malware app to no gan access in the first place. Assuming your apps are secure by default, they would anyway not write private information into the log such as credentials or store other data in plain text on the device. The better system is to entirely disable logging, gain some performance but loose the ability to log - or introduce a system that enables logs only upon user request after approval or you let it enabled but ensure that nothing compromising is revealed. Critical information can usually be already obtained in the Android about screen which reveals MAC, IP, build info among other information and regardless if that is shown or not, it could be read-out via adb. The only viable protection would be to prevent adb, which is possible but then the user would lose even more control. It maybe should be noted that some apps store credentials in RAM, which attackers can obtain, GrapheneOS cannot protect against such attacks with just only wiping logs on device. The security factor here relies entirely on other OS implementation, but despite such attack vector it is controversial how reliable wiping random metadata are, there is no scientific research here provided on what grounds this would benefit a normal user and how an attacker would not anyway able to extract same or similar information trough malware apps, side-loading or other techniques. Wiping logs is also not an effective measurement, assuming a attacker has your device he can remove the battery or let the battery run out more quickly with some adb shell bombing to force the system to shutdown, in that case the system cannot log anything or wipe anything when the device is not powered up. The underlying point is that when new exploits are covered after a period of time, it could potential compromise the verified boot system to bypass it and then you can quickly dumb the system, copy files etc anyway. However, this depends on various factors like direct hardware tampering, bypassing several, not just one verifications and more but the point is that an attacker with access has all the time in the world if he obtained the entire phone.

MAC spoofing does not enhance security nor privacy

Apparently the developer thinks that spoofing specific things enhance security and privacy, this is not the case, despite wrongfully claiming that MACs are unique, they are not, this feature gets basically sold on the features page as a plus for the OS. In reality it can cause problems and the benefit is more than questionable because faked and none existing MACs can easily draw attention to you. Regarding security it adds basically nothing because it is said to be useless, because if an attacker has the skills to crack your WEP/WPA/WPA2 password, then they can certainly spoof the MAC address, as it is an almost trival operation in comparison. Assuming someone wants to attack you, he can easily obtain the knowledge, there are bunch of pen-testing tools and guides for free accessible on the internet.

The feature is also not unique and got added in Android 8, which is enabled by default in Android 10. Same like device encryption and boot protection, the developer wants once again sell AOSP implemented mechanism as security feature for Grapehen which plays not even a role in security nor privacy.

In the past my recommendation was to only change the last parts of your MAC to make it look less suspicious and keep it plausible, but I do not suggest this anymore because skilled attackers, as mentioned above, scan the entire network, all devices connected to it and can easily identify you anyway because modern tools make it much easier to target multiple devices at once.

The Fragmentation Factor

While on paper it seems to be nice to have alternatives, and in theory everyone can fork and modify the code it leads to fragmentation. There are over 600 Linux distros, maybe even more and most of them pure and simply suck. Lots of them are what I call one-man-developer-projects that are maintained by one or only five developers. Do not get me wrong, it is absolute adorable but when it comes to security and privacy they are often behind the mainstream Distros, normally original Distros that such developer use as upper layer are based on the known ones like Debian, Ubuntu etc. and then such developers just add only slight modification. Usually this ends up with several problems, such as:

• Maintenance
• Funding issues
• Partnering and questionable deals, or general spoken business model, strategy and a future beyond funding and depending on e.g. donations to expand and to hire more people
• Giving up after x years due to above reasons and then the user is forced anyway to go back to those mainstream distros
• Fragmentation can break things, backporting etc. are some real problems
• We have popular projects like Brave as Chromium fork, with dozens of developers in it that barely can keep up with Chromium and Google changes, at the end you only have the big players dominating the market because hobby projects are often behind or they simply cannot keep up with the massive amount of changes. At this point I do not say no one should not be encouraged to try but it might be better to submit changes to the original project in an attempt to add this - for everyone - into the original project, this simply benefits more people. The question here is who is in charge and control what is going to get approved and rejected, which is the biggest problem for progression because the community might see things different then Google, Microsoft and the other big players who have the last word at the end of the day. I think a good approach would be that with such huge projects that potential affect billions of people the community should get more saying or there should be a consortium that objectively can overrule such big players. But laws needs to change here to prevent monopolies, a fork simply is no game changer that improves the whole situation for everyone. I think we should focus and start here.
• What if the original project adds those changes, which makes a fork obsolete or at least parts of it.
• Should be encourage forks over the original projects.
• Are introduced changes really a useful addition that benefits everyone or only certain people, experts, beginners etc.

Community entirely based on fanboyism without any actual expert in it

Typically phrases you hear from the community that cannot argue correctly are:

• You do not know what you are talking about - Usually without anything to elaborate or to proof it. The typical full extent of a my word versus your word conversation.
• Trying to get personal - Linking material that is debunked as misinformation and smear campaign in an pathetic attempt to undermine your own credibility.
• What are your qualifications - Typical phrase in an attempt to change the subject or in an attempt to undermine trust to shape the public opinion about your own background.
• Toxic bias - People usually do everything to defend their heroes and idols. This is known and a psychological problem, people usually trying to compensate it by trying to argue their way out of presented findings.
• Going off-topic with irrelevant stuff... - You basically can count on it, it will happen, usually in an attempt to nail you on some cherry-picked things and to change the subject.

The patterns are typically like this, which usually makes the security and privacy discussions boring as those pattern usually re-occur each time, usually coming from people you never heard of or pure beginners.

Same like the Firefox community, GrapheneOS is one of the most toxic (he is also only a self-proclaimed security researcher but overall has a point here), based and defending community you can imagine, every criticism no matter if legitimate or not gets suppressed or talked-down like it is nothing. I never found any actual experts joining the GrapheneOS community that would waste his time to talk for or against a group of based people that are mostly, not always tho, unable to accept presented facts or even start approaches to solve them. Privacy and Security communities in general tend to be toxic because the ones that use GrapehenOS do everything in their power to justify and promote it, while the critiques getting banned, silenced or they need to talk against an entire wall of people which makes such groups inefficient. In other words, it often ends up with insults or my word vs your word or people claiming there are no alternatives but the question is not about alternatives it is more about proving security for the mass and not for just some random people who provide questionable services, products, apps and approaches to solve things that should be solved for the broad mainstream.

I talked about fanboyism a lot in the past because this is systemic wrong and leads to a based two-class society, extremists and the ones that are usually more vulnerable. I dislike this a lot and my approaches going more intro direction sharing knowledge and not selling random products under the name of security and privacy.

Take away your own emotions in a discussion or stop the discussion is the better way to handle actual criticism. The rest is otherwise just only defending the beloved developer, product, app etc. which only results of wasting your own time for nothing except to echo chamber what cannot be verified.

I am 100 percent sure, that GrapehenOS will pickup my guide and trying to defend the developer or the project by attempting to undermine my credibility, this behavior never changed in the privacy community and benefits my argumentation regarding objectiveness and criticism. This usually comes from people that never coded one single hello world or people without security expertise, or in other words, the same people that have absolute no qualification to come to any conclusion, instead those people judge in in instant, I personally care less, because this is expected behavior.

The main issue with blind trust and defending is that it suppresses the truth, tunnels the vision and maybe even blocks innovations or other improvements.

I overall judge the developer to never step in, or post something visible to anyone on the official website to sort this out and draw a clear line regarding communities behavior and content moderation. The project has certain impact and there should be a clear code of conduct for moderating content as well as a statement on what is unacceptable within the community and not officially tolerated such as harassment, racism and so on.

Community hates Google but shall buy and entirely depend on Google Hardware

The community within GrapehenOS hates Google, the paradox is that they shall buy a device that is coming from Google. The reason is - according to the developer - that the Pixel devices provide more security features than others, while this might be correct it directly helps Google to keep their monopoly and you never see support for other devices. The paradox is, that when a device is already considerable secure by default, why shall someone tamper with it and install a custom ROM. This makes no sense. APSO here provides enough security enough, the developer here provides zero evidence for his claims, instead he claims that 0days are an argumentation point saying that Google is not fast enough or that GrapehenOS would be faster in patching them, without any evidence whatsoever when this actually was abused on AOSP end. Not every 0day is easily exploitable and not every 0day is a direct threat because it might require additional dependencies to fully work. The point here is never mentioned with any word on the website. It is to scare people about potential threats without any evidence that those are really abused. These fear is typically spread by uneducated people on the subject which triggers moral panic. Again, your smartphone is not a server and therefore less of an target compared to a server that contains more data and is accessible 24/7 by various individuals. The developer here simply compares apples with oranges swiping under the carpet that lots of potential threads are usually covered by updating third-party dependencies, frameworks or apps that might be affected.

There is also missing to no evidence that Google is not private enough, the claim that Google invades your privacy is normally entirely based on default settings, the developer here swipes under the carpet that Google does have lots of options, toggles to opt-in and opt-out of a lot of things, some of the logs what people wrongfully claim is privacy invasive such as - last logged in from device x - is there to enhance security, because without any log you could never know if your account is compromised or not. This is only one example of many, usually the mass media spreads a lot of hate against Google because it brings the clicks, swiping half of the truth under the carpet. Some things are also by design privacy problematic because some protocols that are used to do X are old and you always have some sort of metadata, claiming here Google abuses them without anything is nothing but unprofessional. In most cases turning features off means really off, there are rare examples when this might not be the case, as history revealed but normally those problems getting fixed by Google pretty quickly. Some services are also explicitly mentioned to not be privacy friendly, because it would break too much, claiming here that Google does not do enough is controversial, some features and implementation depending on how you approach things e.g. remotely removing apps, some see it as security feature others would argue that this is potential abuse because there is no consent when Google removes an extension or app when they detected something suspicious - the point here is that the security and privacy argumentation depends on what user actually want and what do you define as secure and private. We explicitly exclude bugs in this scenario because not every leak that occurred means that the intention was to do that and this probably can happen on both ends.

I personally have a lot of problems with the buy a Pixel phone - philosophy, first of all it helps Google, remember the community hates Google and second it does nothing for other phones. Why not help others too, because of missing security features that might be added anyway afterwards at some point or because the entire strategy relies on those mechanism, regardless how you see it, I find it controversial because if everyone would suddenly use the same brand and phones we might have more leaks that needs to be patched because hackers would then quickly focus on those devices. It is also unclear if those promises really hold over time, Pixel phones got attacked in the past and exploited same like the rest. There is a difference between theory and real-world and apparently the GrapehenOS developer entirely trusts those mechanism without even mentioning that some of them got exploited multiple times too. I do not see how this holds up against an average user that foremost installs a malicious app in the first place, the approach here would be more helpful to teach him to avoid that so he does not do that which lowers any attack scenarios straight from the beginning.

Bad performance

The performance, compared to other ROMs is worse, due to the hardening process and all the extra stuff some apps directly crash and even if they run, they might have bad FPS or drain your battery much faster. The reason for this are some kernel changes, OS changes and how things are approached. This is maybe a small price to pay for some, but is a point to put into consideration. Some people do not want to buy a 600 Euro device and sacrifice the performance just to get questionable promises fulfilled.

GrapheneOS in Retrospect

• Security mechanism doesn't protect against threat models it wasn't designed to protect against. This should be clearly highlighted on top of everything, which is not the case.
• AOSP as well as iOS evolves, which helps much more people, to lockdown their devices.
• GrapheneOS developer wants to make a living out of it, while he obfuscate this point under the security and privacy argumentation. I for myself find this shady because it is an pathetic attempt to pretend your system is more secure, which is absolute unproven claim, as we revealed that the OS cannot withstand sophisticated attacks, at the end you have same level like AOSP in this regard.
• The security and privacy claims are unproven, practical all of them, there is zero evidence that when you apply best practices alone are secured enough. After all hackers use the same tools today and everyone can inspect the same and even if there are findings, it would be controversial if an attacker would leak them to the public or not. At the end you just never know.
• Daniel Micay is self-proclaimed expert without any qualifications and no background in the security scene. No actual expert heard of him. The OS mainly got his attraction trough Reddit as well as the Snowden tweet and not because of independent audits that have shown that actual experts could have not broken the system.
• The OS wants money, to survive, grow etc. It would be fine by me if that is not obfuscated under the cash-grab slogan privacy and security
• Security and Privacy arguments are not verifiable because the OS gets monthly updates anyway to address urgent problems.
• The OS does not work on all hardware. Which makes the - but Samsung delivers updates not so fast - argumentation null and void as you can switch to GSI and use the bare naked ROM and get those updates regardless of what your vendors delivers. Besides that GrapehenOS does not support such hardware, it heavily depends on some key factors such as what hardware it runs on and what the vendor supports as upstream patch level set. But why do I need you if the vendor anyway updates the system which you just modify, I can do this by myself or just use the bare naked ROM alone.
• No audits, code reviews by other experts. No articles or attack vectors has been shown.
• AOSP is trusted by 1+ billion devices - people. It us 1 billion VS. dunno maybe 1 million GrapheneOS users at best. Assuming you would use GrapheneOS as default OS it would end-up pretty much with the same outcome as the target changes and objectively spoken attackers would have more interest on hacking the OS. What it is is problem shifting, you trade defaults, settings as well as the overall target factor.
• Undermining the AOSP is lame, Android simply evolves over time, same like every other OS, some things getting fixed and not every attack vector leads to a success. Spreading knowledge to address those factors is more worth than selling a product because even a normal user can mange to deal with some major security related things, turn airplane mode on, turn out your SIM, leave the phone at home etc. which are security wise the better approaches if you actually value real-world security.
• GrapheneOS has zero protection against data ex-filtration attacks or social engineering protections in place, absolute zero. The ones that are in place are there to prevent device tampering but not attacks against you in person in order to extract information from you which you might hand over freely, once again the knowledge is more valuable than trusting a self-proclaimed expert without any actual qualification in real-life.
• You can manage yourself, most things are easily hardened yourself, if you want OPSec and believe in it. It is a matter of effort, the results are questionable but the benefit is you get a learning curve.
• Most aspects of the false promise of security relies on AOSP end, not on Daniels. This means the project highly and mainly depends on others to secure the OS, adding on top of that some questionable and unproven changes under the name of security can be seen as - fooling - beginners that have less or zero security background, because the would never able to find out how secure the OS actual is, because they do not care, have no time, do not want to put effort into research etc.
• Toxic community usually kids between 15-20 years and you will not find useful discussion nor experts in there that makes it worth to stay in the bubble. Usually the discussion ends with a moderator decision, you get banned or personally attacked if they cannot contradict you. Childish and nothing new.
• Lots of hardening is irrelevant to privacy such as flushing logs after x days. There are better solutions available that I have been mentioned and the exposure here depends on variables like what does the OS logs, what apps log and store in addition as well as if it is stored in plain text and how an attacker would try to access it. The GrapheneOS never shows why that would be of any problem because most attack scenarios are purely speculative.
• There are only 3 features that I acknowledge as useful, this is malloc hardening, sandboxing and Storage Scopes. The rest is already implemented in AOSP, depends on the app factor is is questionable because it requires that the device is somehow already compromised. Sadly the developer provides zero evidence with real-world examples ever to prove any of his claims. Linking to 0day spreadsheets is not evidence that those attacks alone are abused or that they cannot quickly be mitigated by updating frameworks, apps or Google Play Services. Not only is this unprofessional but people who are not involved into security might blindly believe everything without doing their own research. It is sad to see that AOSP related stuff that is already implemented are listed on the features page to pretend the GrapehenOS provides lots of features when in reality it comes down to exactly 3 features that are worth mentioning, I find such practice shady because you pretend to be better than other ROMs while you basically only applied best practices that are already written on the internet before the whole ROM was created, everyone can read them and apply them and get a learning curve which has multiple advantages over blindly installing a random ROM and trust a developer that seems to be inspired by Apple, Microsoft and Big Tech, which is concerning because their approaches are often pretty fast bypassed and restricting everything cannot be the way because it shifts everything away from the user, customization, learning and as already covered most attacks are only theoretically possible because it entirely depends on other factors, factors that we covered in detail above.

No Bug bounty program

All of the claims are unproven and no security expect spends 100+ hours looking into the code actually trying to find holes when it is unclear if there is a reward or not. The developer offers no such program which makes it unattractive to waste your own lifetime looking into it for nothing in return.

This is also one of the reasons Chrome is more secure than Firefox, more people working on it and the bug bounty program has a higher reward which makes it more attractive to submit something in order to get a reward back. Lots of Firefox exploits are never submitted because you get more money when you sell potential exploits on the dark web.

No Changelos on important pages

The features page, among several other pages have no revisions history, last edited indicator or visible changelog which makes it hard - without any archive or Wayback machine snapshot - to reveal what feature was added and what the author updated. The only way to cross-reference some features and when they got added is to check the Twitter Account or the source code commit, but this is much more effort for a reviewer. Assuming someone, like me, wants to review current features and link to the page the author can silently add stuff, edit or remove stuff at any point. Of course a website is not a Git repository and this is usually how things are handled but from the review perspective it is a problem. The page got so often updated and changed that you quickly can loose track what feature was when added and what was addressed. Usually such technique is used when you quickly want to swipe any kind of criticisms under the carpet and change things whenever you think it is necessary.

This is a small point because other pages are not better in this regard, however I hold GrapehenOS to a higher standard compared to most other projects because they better funded than other projects.

Using GitHub

First of all, I am biased on this point but this makes it not less problematic.

GitHub or shall I say Microsoft has a large history regarding anti-competitive behavior, shady tactics and becomes the internet toilette because every troll account dumps his shit on this platform which then quickly lands in the most used search engine, Google. There are other organizations like FSF that have problems with GitHub, their past and current approaches, so I am not the only one here who shoots against GitHub. Assuming that GrapehenOS gets funding, donations you would expect they host it on their own e.g. via Gitea but they go the mainstream way and use the GitHub platform that does not even allow you to self-host. Even alternatives like Codeberg or SourceHut are preferable and you still could mirror the code over to GitHub but as read-only and shift pull requests and code comments away from Microsoft. The positive effect would also be that others might see and follow such an example.

In general the GitHub platform got worse over the years, the current attempt to lure people on there is to make it more social, so that people stay longer on the platform. This is a social trick and apparently people falling for it. I actually expected from such a developer to go other ways and set an better example to others but this is not the case here, which is disappointing. At the end he does what everyone else does and swim with the mass.

Better ways

• Most stuff that is security and privacy related is well known and already covered in written down guides such as Data Security on Mobile Devices: Current State of the Art, Open Problems, and Proposed Solutions. Such guides are important because every developer can read and adopt those suggestions which makes the entire mobile business more secure. Google itself should enforce maximum standards, which they already do or they warn developers if something is not conform. Trusting only one operating system at leave apps and practices vulnerable is more than questionable, of course the OS is the gatekeeper but should not be advertised as privacy friends and secure because as we discovered some variables cannot be covered, the threat model might be different and in most cases third-party apps creating security issues, not the OS on its own.
• Spread knowledge to avoid in the first place that your contacts getting synced in an unknown void, after all your privacy is worth nothing if your friends upload all your details anyway. Then you can de-Google all day long, you still end up in a database.
• Do no cash-grab kids and beginners under false promises, that are deliberately planted to promote your project in order to raise funds.
• Play with open cards and directly say what this is about, it is about making a living out of it, nothing else.
• Give AOSP much more credit and do not pretend it is insecure just mainly on the premise that the defaults are chosen so that every beginner can use the OS and not only experts.
• Submit every patch to AOSP and harden the OS for billions of potential users, if the hardening breaks things, come with actual solutions besides the advertisement of your own ideas because no everyone is willingly to buy a Pixel phone or only specific models.
• If everyone uses the same Chip, the attack surface is bigger and not less. It should be clearly mentioned that bigger awareness and usage in the real-world always leads to higher or exponential bigger security targeting.
• Make people aware of solutions like naked GSI, and provide guidance instead, so that you teach others, spread knowledge and create a reasonable chain that people can discuss about.
• You could provide GSI with whitelists only apps, the attack surface then only remains to above mentioned points, points that GrapehenOS also does not address. Benefit of this approach is that the community could build some sort of - trusted - apps or developer approach, so you still have control over what you install but only trusted apps could be executed.
• Instead of supporting single man developer projects or projects such as GrapheneOS you better invest your money in form of donations into organizations that actual fight for your rights to change fundamental laws, I mentioned one example above e.g. vendors should be forced by law to support the device much longer than it actually is or the right to repair. There are organisations such as EFF or FSF which you can help because they take the fight directly to politics and the government. This benefits much more people and not only people with specific devices and can cause a large impact.

What security and privacy really means

Security and Privacy is not something you automatically gain or re-gain by installing the correct tools, operating systems or only follow best practices. It is not a sprint, it is more a marathon which requires the following as a minimum standard:

• Constant monitoring of new threats, this implies you have interest in the first place to stay informed.
• Proofs, Arguments, and Zero-Knowledge.
• Long breath, because it can be annoying but it is worth to read guides, news and talk with people that have actual background in the matter to share knowledge and experience. This then can be used to build new strategies or improve existent strategies.
• Less bait with security and privacy promises, if your app is secure than you do not need to advertise it as this is a special feature, everyone automatically should assume your app is secure if you provide enough evidence backed up with reviews, audits, reviews etc. This is not the case with GrapheneOS because there is no expert who took a serious look at it and tried to attack it, there is just no article about it instead you find only the yada yada about - look it is secure because we say so - on the internet. This is highly unprofessional and only naive people fall for it.
• Security and Privacy is gained with a relationship between developer and community that verifies the claims and code so that everyone can to a common ground on what security is defined with. You do not gain security by blindly trusting random developer, even if he is an expert, mistakes can be made and stuff could be overlooked, this is normal and this is why verification by others plays a bigger role.
• Self proclaimed experts tend to abuse naive beginners to quickly gain attention to promote their projects to gain a voice, people tend to re-spell the same that they found on the internet without doing any proper research. The responsibility here must be given by the developer to clearly pointing out directly visible what the limitations are and not only advertise security without mentioning the possible downsides, some of those sides are covered in this little article.
• We have more than enough pseudo-experts, I think we should finally agree that security cannot be gained by trusting yet another entirety that promises to do all better than hundreds of people, that said we should clearly come to the final conclusion that there is no such thing as ultimate security, it is an process that is gained my constantly monitoring, auditing, reviewing and the Android Open Source Project deserves a lot of credibility and respect for their continues effort to provide a reasonable secure OS that can customized, enhanced, patched, secured with trusted and verified securing mechanism. I think the developer here wants to undermine this important point here and make AOSP look worse than it actually is, because his argumentation and examples he possible can provide are pure statistics, if GrapheneOS would be used by 1 billion people we would encounter similar statistics that list past problems, but that is why updates are mandatory and important. The original AOSP provides lots of updates, the major issue is and always was that OEMs are typically, not always, fast enough to roll-out security patches, but this can be improved and new laws propose longer support and faster updates. However, most infections can also be addressed by reviewing in advance apps before you install them, which means the user needs a store that simply explains what to look for, pictograms and international standards could help to recognize signs better and Google is working on it, there are new verified developer batches, the review process is much faster and developers even complain these days that their apps are taken offline, which is absolute fine by me, better take it offline than take the risk. This is maybe annoying for the developers but ensures certain standards, such standards are not provided by alternative stores or only insufficient.
• Android Kernel is not perfect and has problems but the Android kernel mitigations obstacle race is solvable.
• Secure boot, verified boot and co might not be as effective as promised, which allows hackers to hack it, after years or when the device is not correctly updated, e.g. because there are no vendor updates provided, which means the entire security argumentation relies yet again on the update and review factor.
• There is no privacy possible, assuming you did everything right, tech evolves which means what you post into the internet might can be - in the future - compromise you, this means you can do everything right at the moment but in the future there might exit tech or tools that can backtrack and expose you. This is hard to predict. Prevention here is mandatory, in general you should not rely on a OS or apps to guard your privacy and only expose the minimum amount of information as possible. This challenge becomes much harder in the future because everything relies on clouds, apps and online identification that goes over god knows what servers and systems.