GrapheneOS (like all modern AOSP based ROMS) can literally not function with just the open source code. It requires hundreds of binary blobs from the vendor partition of a stock Android ROM, many of which have root access and have not been audited by anyone, including Google, who often lacks source code for them.

Beyond that, the GraheneOS team still controls a single signing keychain for all phones in the wild, which we have to assume is still controlled by Daniel Micay (strcat) as it has not rotated as far as I can tell since he mostly stepped away from public view.

He is without question a brilliant security engineer, but we can't ignore his very public Terry-Davis-esqe history of mental illness. Making -anyone- a single point of failure for a ROM frequently recommended for journalists and dissidents is a bad plan, and especially not someone very prone to believing wild conspiracy theories.

I can't recommend GrapheneOS for any high risk use cases until:

1. they are able to find a device they can run 100% open source code on with no binary blobs

2. The ROM can be full source bootstrapped to mitigate trusting trust attacks.

3. The ROM builds 100% deterministically and is reproduced and signed by multiple team members publicly

4. Threshold signing or a quorum managed enclave issues the final signature only if multiple team members give it signed approvals of a hash to sign.

Until at least those points are covered, the centralized trust model of GrapheneOS is a liability and the central keyholder is at high risk of being targeted for manipulation or coercion.

Honestly there is no good solution to these problems right now, and as a security and privacy researcher my best advice today to potentially targeted individuals is don't carry a phone at all, or if you must carry one, keep it in airplane mode whenever possible and do not do anything sensitive on it. Consider QubesOS or AirgapOS for such things.

If you are fine with centralized control of a phone, and fine with binary blobs controlled by random corpos having God access to your device, but would prefer to eliminate as much proprietary corpotech bullshit as possible, then I would suggest considering CalyxOS which is at least run by a former LineageOS maintainer with a great reputation.

▲

tholdem 2 days ago | parent | next [-]

So you're saying don't use a smartphone at all, which isn't possible, or use CalyxOS, which not only suffers from the same "problems" you criticize in GrapheneOS, but is also inferior in every way when it comes to security and privacy?

This does not make sense at all.

▲

lrvick a day ago | parent | next [-]

> don't use a smartphone at all, which isn't possible

I run a b2b tech company in Silicon Valley and have not carried a smartphone in 5 years or had an LTE subscription in 6. I have a family and hang out with friends, mostly tech workers, at least once a week. I am online when I am at my desk or one of my family PCs, otherwise I am offline. It has been a massive productivity boost, attention span boost, and social improvement in every way.

I don't miss hours of doom scrolling a day and missing out on being present with friends and family. Took a few weeks to rewire my dopamine engine so the FOMO went away.

Phones -are- optional and if you think otherwise you might be an addict.

> CalyxOS, which not only suffers from the same "problems" you criticize in GrapheneOS, but is also inferior in every way when it comes to security and privacy?

It is better in one way: a reasonably stable person holds the keys to the kingdom. Personally I do not like having -any- central person controlling my devices, so I just opt out of Android entirely until that situation changes.

I am a supply chain security researcher and founded a Linux distro where no single computer or maintainer is trusted, so trust decentralization, freedom, and control in software are very important to me.

▲

strcat a day ago | parent [-]

> Phones -are- optional and if you think otherwise you might be an addict.

Smartphones are small portable computers. You're using a similar computer to make posts on social media platforms including Hacker News.

> It is better in one way: a reasonably stable person holds the keys to the kingdom.

Repeatedly claiming that I'm insane, schizophrenic, delusional, etc. is not a reasonable criticism of GrapheneOS. I'm clearly none of those things. I've been targeted with attacks including harassment and tons of fabricated stories for years beginning with my former business partner and his associates. You thoroughly discredit yourself by going as far as baselessly claiming that I'm schizophrenic because you don't like the way I've tried to defend myself from these attacks.

The lead developer of CalyxOS (cdesai) was a Copperhead employee directly involved in the 2018 takeover attempt on GrapheneOS. CalyxOS itself directly originates from the takeover attempt on GrapheneOS. The people involved demonstrated their lack of ethics through their participation in the attacks on GrapheneOS and partnerships with people involved in it. You've been attacking us for years alongside them. CalyxOS exists because of this takeover attempt. It's a non-hardened OS which was created by heavily using GrapheneOS source code and documentation without most of our privacy and security features.

▲

lrvick a day ago | parent | next [-]

I am not qualified to actually diagnose you with anything, but I think you are brilliant with normally well reasoned threat modeling, yet also you seem stuck in a revisionist history narrative that people were trying to rip off or steal from GrapheneOS, when I was there for a lot of it, in frequent contact with all main parties involved. The other projects simply existed with different goals that sometimes referenced or forked code you chose to open source (which everyone appreciates). The Copperhead shady licensing situation as I understand was understandable to walk away from, but the constant citing of conspiracies and sock-puppet campaigns that never happened and your hostility to CalyxOS, F-Droid and others who are good community actors was where a lot of people including me felt you lost the plot and were not being rational. The "takeover attempt" narrative never happened and every time you say it did without evidence you hurt your credibility. It is an incredible conspiracy accusation that merits proof, or you will continue to be called delusional. I do always make an effort to separate these seemingly irrational views with otherwise well reasoned security engineering work.

The primary thing we disagree on in a pure objective security engineering capacity is you feel it reasonable that a single person, you, can be trusted to resist coercion or manipulation to hold the signing keys that would allow pushing any code to the phones of a lot of highly targeted and vulnerable individuals. Otherwise I actually normally agree GrapheneOS has made the best effort defense calls it can in a very broken and proprietary ecosystem. Use open stuff where you can and where you can't try to put up IOMMU walls. I get and respect the pragmatism here. I do similar in AirgapOS and other projects.

I however absolutely can never recommend trusting centralized/proprietary software supply chains in areas where dramatically more open and accountable solutions already exist, which is why I do not actually use or recommend CalyxOS or GrapheneOS for high risk use cases and instead full source bootstrapped a Linux distribution from scratch that avoids any trust in me as the founder by design.

For low risk use cases where users simply don't trust Google or the stock phone malware, LineageOS or CalyxOS is just fine as they remove this, and I am more inclined to support cdesia/CalyxOS which at least attempts basic signing, and trust cdesia as a keyholder when someone really wants to use Android purely because of his peace-keeping personality that is normally very receptive to criticism, and is never hostile to anyone that forks their code for use in other projects as you have a history of doing, but ultimately again, I don't actually use or recommend CalyxOS or GrapheneOS for most people for most use cases.

If forced to use a mobile device again I would probably fork GrapheneOS, remove all the proprietary bits I can, LTE, bluetooth, etc be damned, and sign it myself only for my own use, until I could develop an quorum enclave controlled signing scheme and then offer that.

If you were to agree to take on quorum controlled signing of reproducible builds, then there is no central trust in you, and all my primary arguments against GrapheneOS go away and GrahpheneOS would be leaps and bounds better than CalyxOS by any technical measure I am aware of.

If you put aside any dislike of me, objectively, removing trust in a single person makes you and the project and users safer, and make it much easier for people to separate your personal views from the stability of the project as a whole.

I could get dementia tomorrow and I am confident the StageX project would continue without me with signatures by other maintainers by design. The team already has made several releases without needing signatures from my key already. This is a proven strategy now, not just a theory I parrot to try to win arguments.

GrapheneOS, for all its high risk users, deserves to be protected from the failing of any one human or build machine.

I'll let you have the last reply as this will go on forever otherwise. You know how to contact me if you ever want to discuss any of this privately.

▲

strcat 18 hours ago | parent [-]

> I am not qualified to actually diagnose you with anything

You should stop calling be insane, delusional, etc. It's quite easy to stop.

> yet also you seem stuck in a revisionist history narrative that people were trying to rip off or steal from GrapheneOS

No, I'm not doing that. The fact that they built on our code while trying to undermine us with misinformation and numerous forms of attacks is what makes it wrong. Calyx knowingly spread and supported misinformation about GrapheneOS and myself. They welcomed, tolerated and worked with people involved in harassment along with frequently participating in it. You do it yourself as you've demonstrated here so of course you don't see it for what it is or think it's wrong.

> but the constant citing of conspiracies and sock-puppet campaigns that never happened

The harassment and their involvement in it happened and continues to happen. Your involvement in it is real and continues too. There's no conspiracy. It's plain for all to see you repeatedly calling me insane, delusional, schizophrenic, etc. and personally targeting me in similar ways over and over. You're just one of many people doing it. That is the harassment, which clearly does exist and you participate in it including in this thread. Calyx and their community are heavily involved in it.

> your hostility to CalyxOS, F-Droid and others who are good community actors

CalyxOS and F-Droid both have multiple people who were involved in the takeover attempt and supported their attacks on us, including the lead developers of both projects.

> a lot of people including me felt you lost the plot and were not being rational

It's factual information, and it's you not being rational about it.

> The "takeover attempt" narrative never happened and every time you say it did without evidence you hurt your credibility

It is exactly what happened. My former business partner tried to take over my open source project against the terms of our agreements. The project was started prior to the company existing in late 2015 and was very clearly separate from it. This has been confirmed by other people involved and around at the time including the 3rd person involved in forming the company.

> It is an incredible conspiracy accusation that merits proof, or you will continue to be called delusional

My former business partner trying to take over my open source project is what happened and is not a conspiracy theory or delusion.

> I do always make an effort to separate these seemingly irrational views with otherwise well reasoned security engineering work.

My statements and views about this are not irrational.

> The primary thing we disagree on in a pure objective security engineering capacity is you feel it reasonable that a single person, you, can be trusted to resist coercion or manipulation to hold the signing keys that would allow pushing any code to the phones of a lot of highly targeted and vulnerable individuals.

We don't disagree on the concept that it would be nice to avoid trusting a single person with this. Where we disagree is that I do not think your proposed approaches are better or that they actually address the trust placed in many people.

> and I am more inclined to support cdesia/CalyxOS which at least attempts basic signing

Not clear how you think we do not do basic signing.

> and trust cdesia as a keyholder when someone really wants to use Android purely because of his peace-keeping personality

He was directly involved in the very real takeover attempt on the GrapheneOS project at Copperhead. He stood by as Nick repeatedly spread misinformation about GrapheneOS and personally attacked me including regularly covering it up. He has a long history of making false claims about GrapheneOS and myself himself. He's friends with many people participating in harassment towards me and clearly has no issue with it along with openly helping them do it.

> that is normally very receptive to criticism

In reality, no, and they'll quickly shut down conversations particularly involving any of this. You think they'd talk openly about this where someone raises actual things they've done and participated in? No.

> and is never hostile to anyone that forks their code for use in other projects as you have a history of doing

Calyx gained influence over Seedvault, a project written for GrapheneOS by a GrapheneOS user, and has since used that to be hostile towards our users reporting issues there and us for continuing to reluctantly use a project now hostile towards us. They've done the same with other projects. They're hostile towards our users, not only us.

A Calyx contractor recently closed a valid F-Droid bug filed by a GrapheneOS user causing it to wrongly show a warning on GrapheneOS every time it installs/updates an app. It's clearly an F-Droid bug since we use standard Android infrastructure to add our Sensors permission and their bug occurs with the POST_NOTIFICATIONS permission and multiple other past cases of added or split permissions in Android. It's a long term F-Droid bug which has existed for ages. Instead of fixing it, they're keeping incorrect code with no purpose and instead adding workarounds for specific cases found to occur with Android's added or split permissions. There's no reason for F-Droid to be checking that the requested permissions parsed from the APK by them match what the OS considers to be the requested permissions. The APK is verified before it's installed and F-Droid's understanding of permissions not matching Android's understanding is fully expected since it does not handle implementation details. It cannot properly handle it as the OS does because the OS adds and splits permissions this way in future releases, so adding all of the current ones still causes it to break in the future. This used to break automatic updates for GrapheneOS users, but at least now it only displays an incorrect warning. They may change it to break things again. Meanwhile, they falsely claimed we were avoiding doing something about this to hinder F-Droid's compatibility with GrapheneOS when they are blatantly doing that. This is one example of how they misuse their control over projects to cause harm to their own users to hurt GrapheneOS. They've done so repeatedly.

> If you were to agree to take on quorum controlled signing of reproducible builds, then there is no central trust in you, and all my primary arguments against GrapheneOS go away and GrahpheneOS would be leaps and bounds better than CalyxOS by any technical measure I am aware of.

The whole thing is a personal grudge and you hold us to a standard you don't hold other projects to based on it. A substantial amount of resources is required to simply make 1 set of builds. Blocking releases indefinitely any time there's a regression in determinism without any more resources to deal with that or early access to address issues prior to when a stable release comes out isn't going to work. When we're porting to a new release like Android 16, addressing some kind of new bug causing something to be non-deterministic cannot be our priority without early access to the release and resources to handle it. If you truly wanted us to do this then you could have helped us get what we needed to do it, make the required scripts and improve protection against non-determinism getting introduced. Instead you act as if this isn't something we want, when it is, but we aren't willing to break updates with an improper implementation.

It's not clear how you avoid trusting me or the developers doing nearly all of the actual development and code review on GrapheneOS through this though. Reproducible builds combined with checking it's reproducible from other parties does not truly accomplish that. Source code is being trusted either way.

There is someone actively reproducing each of our builds after we make releases. It's fully reproducible but AOSP and other projects do have upstream regressions for this we have to fix on a regular basis. It's not always easy to fix.

> If you put aside any dislike of me, objectively, removing trust in a single person makes you and the project and users safer, and make it much easier for people to separate your personal views from the stability of the project as a whole.

I dislike your false claims about me and your harassment towards me. Most of the few times I've interacted with you for several years have involved you making personal attacks on me and talking about us not providing a reproducible build verification feature which barely any projects provide and which is not practical for a project largely based on AOSP without early access or the resources to fix all reproducibility issues they introduce prior to stable releases.

> I'll let you have the last reply as this will go on forever otherwise. You know how to contact me if you ever want to discuss any of this privately.

I don't think we're ever going to come to an understanding. I simply want you to stop making public personal attacks on me. I'm not showing up in threads about your projects talking about what you've done towards me, but you keep showing up in discussions about GrapheneOS to claim that I'm crazy and delusional. You're doing the opposite of encouraging us to implement the signing feature you want.

	▲	lrvick 5 hours ago \| parent [-]
		I was referring to CalyxOS doing signing over LineageOS which does not (in any useful way), as the two popular operating systems that happen to share a lot of hardware compatibility overlay with GrapheneOS (but admittedly little else in common). The one point I will take that is fair is to stop trying to diagnose you as that is not my background or place to do. We will likely continue to have wildly different accounting of the same events and the motivations of those involved, but it is on me to not lower my communication standards when dealing with people I find to be extra difficult or extra wrong. Point taken. I apologize for any and all assumed medical diagnosis related comments about you and I commit to stop making these as I am not qualified to make them. I will also discourage those comments in my communities as I can. We should be better than that. What I can and will repeatedly say is that you are obsessively defensive about GrapheneOS to the point that all criticism of it or your communication style or use of your code in related projects is regarded as a coordinated attack or harassment campaign when it is simply a lot of people who have independently found your personality impossible to work with in spite of making useful code. So much so that many have taken steps to actively fork things away from you so they do not have to deal with you because your approach puts -their- mental health and desire to work on related code at risk. This is a real shame things went this way, because so few doing hard and important security work also have strong interpersonal skills. I am going to try to do better here, and I hope you do the same. It is unlikely we ever be friends but I hope we reach a point where we can make use of ideas or code each other might have been involved in without drama. I am even considering adding hardened_malloc as an optional package in stagex because I still feel this is great work. I will stay out of threads on your projects unless about something I am actively working on or working with, but I will continue to share my own view of shared events and my issues with trust structures in current Android efforts, including GrapheneOS and your leadership style, when they come up organically by others in my communities. I hope you are able to take that for the win that it is.

▲

cindyllm a day ago | parent | prev [-]

[dead]

▲

strcat a day ago | parent | prev [-]

> CalyxOS, which not only suffers from the same "problems" you criticize in GrapheneOS, but is also inferior in every way when it comes to security and privacy?

CalyxOS lacks the current driver/firmware patches and isn't a hardened OS with similar privacy and security patches. There are plenty of worse options but people are better off using an iPhone.

Hardware and firmware is closed source in general and the complexity of that dwarfs a few dozen closed source driver libraries used on top of open source kernel drivers. Pixels have those libraries built with debug symbols and they're not hard to review. It's not obfuscated code and you're given the function names, etc.

Those few dozen mostly quite small libraries being open source instead of closed source with debug symbols would be nice and is something we want. With an OEM partnership, we can have access to the sources and build them with hardening even without those being open source yet. We can likely include debug symbols just as Google did for the most part on Snapdragon Pixels. Convincing a company like Qualcomm to open source those would be ideal, but it's far from being at the top of a rational list of privacy and security improvements which could be made.

> This does not make sense at all.

You can see he's once again making a baseless claim that I'm schizophrenic, delusional, etc. in his post here as he has done many times before. There's also the baseless claim that I believe wild conspiracy theories. It's not me making unsubstantiated claims about backdoors and proposing approaches to prevent it which disregard the hardware and firmware to focus on the OS having reproducible builds, which would not stop malicious changes hidden at a source code level. I don't think Hacker News should permit baselessly claiming someone is schizophrenic. It's not reasonable discourse, and neither is linking what's clearly harassment content from a Kiwi Farms as happens here regularly. I've never claimed GrapheneOS prevents hypothetical backdoors and certainly wouldn't claim reproducible builds (which we have) can somehow we used to prevent it for the OS.

We can make more use of the reproducible builds but enforcing anything based on it requires early access and more resources to fix reproducibility issues early to avoid delaying security updates. It will not avoid trust in the OS developers and the projects it uses itself. It can only reduce trust in the build infrastructure and people involved. Open source does not prevent backdoors. The small amount of closed source library code for supporting a modern smartphone SoC, etc. is also quite insignificant compared to the overall hardware and firmware complexity. Reviewing those libraries is also quite doable. Open source is not a hard requirement to review something, particularly with debug builds for most of it and no obfuscation. When we find bugs in this code with MTE, we get nice tracebacks with the function names due to the debug symbols. It's hard for us to make our own fixes for it, but not impossible. We would prefer if they were open source, but it's FAR from the most pressing issue and is something SoC vendors could quickly solve if convinced to do so.

▲

gf000 a day ago | parent | prev | next [-]

> my best advice today to potentially targeted individuals is don't carry a phone at alil

Lol. I hope you like working with geese, but be careful, they can't be trusted!

Also, you are pretty much factually wrong on a bunch of items on your list. GrapheneOS still has room for improvement of course, but they are very ahead of anything else on every aspect. And where you are not factually wrong, you are just unrealistic. There is no 100% open-source hardware, period. This is complete "what color you want your dragon to be" category.

▲

lrvick a day ago | parent | next [-]

> Lol. I hope you like working with geese, but be careful, they can't be trusted!

Geese? That is offensive. I raise chickens.

I also run a successful tech company, and have a full EE lab, several full server racks, and more tech in my home than anyone I have ever met.

Phones are completely optional in modern society. We have just convinced ourselves we need them because doom scrolling and constant notifications are addictive.

Print your boarding pass, ask for paper menus, pay with cash, and arrange times and places to meet people and then actually be there on time. The rare times you really need to do online work on the go, bring an actual computer with a real keyboard. Free wifi is everywhere.

Works just fine, and as a bonus your time away from home becomes mostly invisible to marketing firms.

▲

lrvick a day ago | parent | prev [-]

> Also, you are pretty much factually wrong on a bunch of items on your list.

If you are going to call me misinformed, please take the time to prove it so I can stop sharing information I otherwise have no reason to believe is incorrect.

> There is no 100% open-source hardware, period.

Multiple fully or mostly open hardware computers exist. They just cannot run android.

MNT Reform, Precursor, and Talos II are the top three that come to mind.

Those are lightyears ahead in openess and auditability compared to anything Google produces.

	▲	strcat a day ago \| parent [-]
		> Multiple fully or mostly open hardware computers exist. They just cannot run android. No, not really, and there's no reason those can't run AOSP. > MNT Reform It has a typical closed source ARM SoC and other components. The chassis and board being open doesn't make all the components open. CPU, GPU, MMU, USB, etc. are provided by the SoC and are closed source as usual. It has closed source hardware and firmware for the SoC along with other closed source hardware and firmware. Not having to load firmware from the OS does not mean it's open hardware and firmware. It's barely more open than other computers for the most complex parts of it. How is something fully open hardware if the vast majority of the complexity is in closed source components providing most of the functionality? The SoC is just the most complex of these by far. Why couldn't AOSP be run on a regular ARM SoC used in devices which run AOSP? AOSP works fine on top of the mainline Linux kernel and drivers. > Talos II A mostly open source motherboard where you drop in a closed source CPU is not really an open source platform. It's not fully open source itself and the CPUs used with it are not open source. IBM took steps towards open sourcing PowerPC as an ISA and relatively primitive open source cores OpenPOWER core designs exist. However, what's actually available and used with it are closed source CPUs. In theory, there can be open design CPUs for use with it. As a motherboard, it's pretty close to fully open hardware. As a functioning computer, it's mostly not because a motherboard is not a whole computer and is far less complex than the CPU even with a more traditional desktop design with less functionality moved into an SoC. > Precursor It has a closed source FPGA as the primary processor and other closed source components. It's far closer to being open source, but it isn't fully open hardware. This is the only one you listed which is anywhere close to mostly open source. It is very far from a powerful modern smartphone device though. > Those are lightyears ahead in openess and auditability compared to anything Google produces. The primary SoC in each is closed source. Precursor programs their CPU on top of that closed source FPGA so the CPU is open source in that sense and much closer to being mostly open. It's not the only closed source part of it. The other 2 examples have a closed source SoC. One uses a regular closed source ARM SoC incorporating far more than a CPU and GPU into the closed source chip. The other depends on a more traditional desktop style closed source CPU from IBM outsourcing more to the motherboard.

▲

strcat a day ago | parent | prev [-]

> GrapheneOS (like all modern AOSP based ROMS) can literally not function with just the open source code.

It does not inherently require any closed source code or hardware. Real world hardware is closed source and requires tons of closed source firmware. Not updating the firmware doesn't make it not exist. It would mean it was outdated and missing important security patches. Lots of firmware is updated by GrapheneOS. All of the kernel drivers are open source. Replacing closed source libraries such as the Mali GPU library to use hardware components is something relevant to GrapheneOS and any other OS targeting the same hardware. It's best for the SoC vendor and OEM to be involved in that rather than spending many years gradually assembling it downstream where by the time things work, the device is end-of-life. The hardware/firmware would still be just as closed source after doing all of that.

Ignoring all of our hardware requirements would not result in there being a single device we could support without nearly entirely closed source hardware and firmware.

> He is without question a brilliant security engineer, but we can't ignore his very public Terry-Davis-esqe history of mental illness.

There's no basis for these repeated claims that I'm insane, delusional or schizophrenic. Defending myself from frequent attacks by many people doing exactly what you're doing doesn't make me crazy or an aggressor towards the people doing it. You're demonstrating the ongoing libel, harassment and bullying directed towards me. There's no point in claiming it's a delusional when you've repeatedly engaged in it. Engaging in this in plain sight and pretending it's imagined is ridiculous.

> Making -anyone- a single point of failure for a ROM frequently recommended for journalists and dissidents is a bad plan, and especially not someone very prone to believing wild conspiracy theories.

I do not believe any wild conspiracy theories. It's a baseless and dishonest claim. I'm not the one pushing unsubstantiated claims about backdoors and a clearly non-working approach to preventing them. Not having the Mali GPU driver library and similar closed source userspace libraries would not change that the hardware and firmware is closed source and also far more complex.

> 1. they are able to find a device they can run 100% open source code on with no binary blobs

There's no laptop, desktop, tablet or smartphone which is not filled with closed source hardware and firmware. Having some closed source libraries for a Mali GPU driver, etc. which are not obfuscated, generally have debug symbols and can be thoroughly inspected/audited if you want to do that is insignificant compared to the vast complexity of the closed source hardware/firmware.

A device avoiding having a few dozen closed source vendor libraries would be nice but it's still going to be closed source hardware and firmware. It would allow us to cover it with our added compiler-based hardening and much more easily fix or work around bugs we find with our hardening features such as memory tagging. It's something we want and can eventually be a requirement, but not yet. Tensor Pixels greatly reduced how much of this there is compared to Snapdragon Pixels but didn't keep going in that direction especially with Android 16 throwing away a lot of progress.

> 2. The ROM can be full source bootstrapped to mitigate trusting trust attacks.

It's an operating system, not a ROM. Having a standard toolchain build is for reproducible builds and all parts of the toolchain itself can be built from the source tree.

> 3. The ROM builds 100% deterministically and is reproduced and signed by multiple team members publicly > 4. Threshold signing or a quorum managed enclave issues the final signature only if multiple team members give it signed approvals of a hash to sign.

GrapheneOS has reproducible builds. There's a community member regularly testing it and publicly reporting any issues which come up in our public development room. A recent example is that Android 16 split up the kernels into 3 groups which we found hard to explain and make sensible for people building it, which they ran into. There are sometimes regressions in AOSP which cause minor reproducibility issues. This community member looks into those to determine what's wrong. There are not currently any known build reproducibility issues which occur regularly. There's no strong commitment from the Linux kernel, AOSP, Chromium, etc. to keeping builds fully reproducible and blocking security updates based on this wouldn't make much sense, particularly with a strict interpretation of it rather than investigating the actual differences and determining if it's even an actual code difference.

	▲	strcat a day ago \| parent [-]
		AOSP having a regression causing a timestamp to be added somewhere isn't a reasonable justification for blocking security updates. No system without the ability to investigate the cause and determine if it's okay would be reasonable. We would need to finally have early access to new Android releases to test this in advance and have fixes ready to go prior to the stable releases. We do not currently have this early access but will likely obtain it from the OEM we're working with soon. We would still need additional resources to have ongoing testing for this and fixes for any relevant regression that finds. Porting to new releases prior to them being stable and specifically testing this would be needed. We can't risk introducing a very a fragile system which could result in substantially delayed updates. Our plan for reproducible builds is to provide an opt-in feature where people can select which additional parties they trust to reproduce builds without falling behind significantly. This would solely be for the OS update client and App Store updates. It would not be for other uses of signing such as verified boot which are not designed to handle this. It would a system to verify that signed hashes from other parties have been published for an update. The meaning of that can be defined by these parties reproducing builds, such as how they'll investigate a mismatch and the way they'll determine if it's an issue. In practice, this would be based on tools we publish for others to use for building and comparing. Similar to the rest, people are trusting the source code and the people who wrote it. Source code is not inherently trustworthy and provides no magical privacy or security properties. Reading the sources does not mean you will find all the vulnerabilities, particularly subtle ones or hidden ones. It clearly doesn't provide that even for extensive audits/review. Why does the Linux kernel have so many serious vulnerabilities being found on a regular basis including ones which are years and even decades old if this approach works? If you truly believe that I'm insane, why do you think it's reasonable to use code that I wrote or supervise writing as long as the build matches the sources? > Until at least those points are covered, the centralized trust model of GrapheneOS is a liability and the central keyholder is at high risk of being targeted for manipulation or coercion. You use many open source projects with far fewer review. GrapheneOS itself is based on AOSP which uses a huge number of open source projects from a huge number of people. The Linux kernel alone has a massive number of contributors and most code has little review. It's filled with vulnerabilities which are found regularly. https://lore.kernel.org/linux-cve-announce/ provides a very flawed overview of this based on what is backported. These devices are compromised in the real world by exploiting vulnerabilities like many of these. Reproducible builds and checking that others have reproduced builds is not actually going to stop a software supply chain attack in practice, which would work within the constraints and use source code. If one of the projects used by AOSP has a backdoor added to the sources, how do reproducible builds help? We'd just be building the code and the backdoor would be reproducible. > Honestly there is no good solution to these problems right now, and as a security and privacy researcher my best advice today to potentially targeted individuals is don't carry a phone at all, or if you must carry one, keep it in airplane mode whenever possible and do not do anything sensitive on it. Consider QubesOS or AirgapOS for such things. Computers have closed source hardware and firmware in general. A few small closed source libraries are not significant compared to the overall complexity of the closed source hardware and firmware. Those libraries are easy enough to review. Pixels have debug symbols enabled for them. Reviewing firmware is a larger scale and much harder undertaking. How do you review the hardware itself? Even if the hardware design was fully open source for the SoC including the CPUs, GPUs, MMU and everything else along with the radios and other peripherals, how would you verify that what a chip manufacturer like TSMC produced matches the hardware design? > If you are fine with centralized control of a phone, and fine with binary blobs controlled by random corpos having God access to your device, but would prefer to eliminate as much proprietary corpotech bullshit as possible, then I would suggest considering CalyxOS which is at least run by a former LineageOS maintainer with a great reputation. The lead developer of CalyxOS is a former Copperhead employee directly involved in the takeover attempt on GrapheneOS in 2018. You're talking about someone who was a direct participant in doing shady things for Copperhead's CEO going against the ethics of the open source project the company was meant to be supporting including participating in the takeover attempt and then leaving following it. He was involved in subsequent attacks on GrapheneOS including similar harassment to what you participate in yourself. CalyxOS does not have current Android privacy/security patches. It's still missing the June 2025 patches for Pixel drivers/firmware. It isn't a hardened OS like GrapheneOS with similar privacy or security improvements, and it doesn't maintain all of the standard security model due to the privileged code they add to the OS.