4 ms·
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 par
by lrvick 1y ago
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 1y agoSo 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 1y ago> 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 1y ago> 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.
- gf000 1y ago> 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 1y ago> 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 1y ago> 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 1y ago> 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 1y ago> 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.