GrapheneOS is the only Android OS providing full security patches
grapheneos.social
grapheneos.social
> GrapheneOS has officially confirmed a major new hardware partnership—one that marks the end of its long-standing Pixel exclusivity. According to the team, work with a major Android OEM began in June and is now moving toward the development of a next-generation smartphone built to meet GrapheneOS’ strict privacy and security standards.
It's impossible to escape the Apple/Google duopoly but at least GrapheneOS makes the most out of Android regarding privacy.
I still wish we could get some kind of low resource, stable and mature Android clone instead of Google needlessly increasing complexity but this will over time break app compatibility (Google will make sure of it)
Edit: I do think Pixel devices used to be one of the best but still I'd like to choose my hardware and software separately interoperating via standards
0. A privacy first approach would be something like this:
`You+App --Read/Write-> f_private(your_data) <--Write only- 3p` and App cannot communicate your data to 3p or google/apple.
Think of Yelp/Google Maps but with no _read_ permissions on location, functions can be run in a private middleware e.g. what's near an anonymous location or ads based on anonymous data. You can wipe your data from one button click and start again for EVERYTHING, no data is ever stored on a 3p server. Bonus: No more stupid horrible permission fiascos for app development that are just plain creepy.
1. An opensource data effort that can support (0) with critical infra e.g. precise positioning, anonymous or privacy preserving functions that don't reveal their data or processes to 3p.
Here is my favourite open source effort: Precise Location Positioning. A high recall, opensource, 3D building and sattelite-shadow Data-Infra effort[3]. This world class dataset on shadows and sattelites are a must. Most geo-location positioning tied to Radio signals is just a bandaid and fraught with privacy issues — thought there are heroic privacy first efforts in this direction[1][2] which though amazing will be playing catch-up with google already deploying [3].
[2] https://github.com/wiglenet/m8b
[3] https://insidegnss.com/end-game-for-urban-gnss-googles-use-o...
`You+App --Read/Write-> f_private(your_data) <--Write only- 3p`
I'm imagining a future where you buy a smartphone and when you do the first configuration, it asks you which services provider you want to use. Google and Apple are probably at the top of the list, but at the bottom there is "custom..." where you can specify the IP or host.domain of your own self-hosted setup.
Then, when you download an app, the app informs the app provider of this configuration and so your notifications (messenger, social media, games, banking, whatever) get delivered to that services provider and your phone gets them from there accordingly.
Is there anything like that in the world today?
It's not the right solution long term, but you can't expect the entire ecosystem to appear overnight. Using it allows deferring the driver issue a bit while building out the rest of the ecosystem.
The problem is it won't run any apps, so you'll need to carry this open-source secure phone in addition to your normal phone.
Unless you're Fabrice Bellard who literally created a 4G softmodem - no. It takes a whole lot of people (or, again, one genius Fabrice Bellard clone) to design a smartphone. You'll need AT THE VERY LEAST:
1) a SoC that has reasonably open device drivers and specifications - without that, all attempts are moot
2) a hardware engineer to deal with the PCB
3) a low-level system engineer to deal with the initial bringup (aka, porting u-boot and maintaining it)
4) an RF engineer to deal with the black magic that is designing ultra high performance PCBs that deal with the RF stuff (2G-5G phone networks, BT, WiFi, NFC, GPS) and high-frequency buses (storage, RAM, baseband, USB, PCIe, CSI/DSI)
5) a GPU driver engineer of the class of Alyssa Rosenzweig to get the GPU drivers to behave (she literally provided better-compliant drivers than Apple)
6) a battery engineer to ensure you don't end up with something like the ill-fated last Galaxy Note (that had to be fully recalled due to battery issues)
7) a ton of software engineers to get the basic things running that people expect from a smartphone (e.g. phone calls, 911, SMS, MMS, a browser and enough userland libraries so that third-party developers can begin to port games)
8) hosting engineers that deal with reliably delivering OS updates, application updates and A-GPS data
9) a skilled purchase and finance department to acquire all components as well as skilled QA people to make sure you don't get screwed in your supply chain by someone cutting corners or trying to engage in outright fraud
10) plastics and metal design engineers for the housing and other related engineering, and you'll probably also need engineers specializing in mass production and assembly as injection molding is a skillset on its own
11) engineers specializing in low power domains to get something that doesn't eat through the entire battery in a matter of hours
12) UX, UI designers to get something people can actually use (partially, that's also compliance stuff - think of accessibility laws)
13) testers to test your device against an insane load of other things - headsets, headphones, consumer and enterprise wifi, car head units, mice/keyboards, game controllers, USB hubs, monitors, projectors, adapters, dongles, IPv6 in its various abominations, phone network-side vendors, how devices behave in trains, cars, airplanes, cruise ships, in temperature and humidity extremes, under water, in back pockets (bending!), in dirt, dust, rain, being drenched in all kinds of beverages, muck, snow, fog, right next to extremely powerful broadcast radio transmitters, high magnetic/electric fields, teeth both human (toddlers) and animal (cats and dogs)...
14) logistics experts to deal with shipping, returns, refunds, recalls
15) customer support
16) psychoacoustics and acoustics engineers to make sure your device doesn't sound like shit (both what you hear, and that includes safeguarding the speakers from burning out, and what others hear from you, aka the beamforming stuff that the Asahi people reverse engineered)
17) video/colorspace engineers to make sure the whole darn thing isn't off color
18) camera/optics engineers, even if you acquire camera units these need to be integrated properly
19) lawyers and domain experts to deal with the compliance crap: RoHS, CE, FCC, India's regulatory authority, licensing, binary blobs, video codecs, audio codecs, carrier compliance testing, HDMI, HDCP, the RF compliance crap that's needed for US compliance [1], tariffs, sanctions laws... the list is endless
20) advertising (although admittedly, word-of-mouth could be sufficient), and PR in general (including websites, print media, AtL/BtL marketing)
21) deals with app developers, lest you end up like Windows Mobile
22) security testers/experts to make sure your devices don't get 0wned by cellebrite, mossad, nsa, cia, ...
23) human resources experts ("people engineers") to herd all the cats
24) packaging engineers to make sure the product arrives at the customer's hands both looking appealing and undamaged (tbh, that's at least four distinct skillsets as well)
You're looking at a minimum of 2-4 million $ for the engineers alone, another 4-5 million $ for the compliance crap, many millions for the app deals and way more in upfront cash for components and logistics chains.
That's why every attempt at a reasonably open source phone design has either failed or is many years behind the mass market. And the list of organisations attempting to do so include household names of the likes of Mozilla. And that is also why/how ODMs exist... they all have figured out some "minimum viable design" that gets tweaked a bit for the customer brand, and that's it. Everyone else went bust. Including, as mentioned, Microsoft. Including former powerhouses such as HTC. It's simply too complex to keep up.
On HN, we could probably drum together people of all these skillsets, no doubt (it took me half an hour to think of all these people and I'm pretty certain I've missed important aspects still!), and even ones with enough money to burn. But even then: the competition are the richest companies on the planet: Apple, Google, Samsung. Good luck...
(And yes: a minimum viable phone - probably a lot of people here including myself could whip that up using a COTS 5G modem, a Raspberry Pi and a power bank. But that's a MVP, not something you can sell to anyone less nerdy than Richard Stallman, and it's based off of the work of a lot of the people I just spent 58 minutes to think of and write down)
At this point? Reliable emulation that can run 99% of Android apps, to provide a bridge until the platform is interesting enough for people to develop for it "natively".
I think the easiest way to do that would be to run Android in a VM.
The problem is the critical payment and government ID apps that will never run in an Android VM because they intentionally break without hardware attestation.
Actually, if you rely on the app, you really on the Android SDK which is not open source.
Now if you could run AOSP but your own apps built with an open source SDK, that would be a different story. Some people seem to really want to do that with PWAs. I personnally tend to hate webapps, but I have to admit that they can be open source.
Sony's cameras used to have an Android userland that they used for their PlayMemories apps. No idea how exactly that one was implemented though, but it should be possible to get Android apps without going into being an Android fork.
There is a reason GrapheneOS is number one and a reason why they only run on Pixels (for now).
Graphene is in a class of its own compared to both of these though and there's frankly no reason to bother unless you're trying to improve those ecosystems.
In case others, like me, weren't aware.
I'm quite enthusiastic about Graphene's OEM partnership,though.
This is why I can’t do GrapheneOS. Pixel devices do not suit my needs (& aren’t available). 2 of the big appeals for my going Android was 1) device options 2) ability to customize (appearance, apps from other sources, root access). Google has basically done everything to prevent #2 & GrapheneOS prevents #1. …This is why I also have a Linux phone to just leave these restrictions.
When i have more freetime during the holidays i will test further. I especially want to try how it works when i combine stuff like steam + fex + Proton or run other GPU stuff
I'd much rather GrapheneOS continue to get popular enough that banking apps are forced to support phones without attestation.
Now developers can choose to support it (and some of the developers do!) aside or apart of google "attestation". How it should be, reliable providers should be able to certify it equally firmly.
Google should be forced to accept a valid hardware-attestation certification as their own. GOS have raise the issue with the European Commission and I hope Google will get fined and forced.
in quotes because it mostly confirms that google runs in the privileged mode and can't detect one of the issues. But google also gives a pass to many very old, insecure, rooted devices. It's a scam.
They already do; Google's flavour of Android adds plenty of proprietary components on top of AOSP.
Don't get me wrong: they are locked-in, that's a fact. And to be fair they benefit from all the work of Google on the OS. But that's not a reason to desire to go further and lose even more control.
thats the thing, they would supply android os to these major manufacturer, but for the rest??? need vetted applications
Huawei pulled it out with HarmonyOS (I don't know how good/bad is it, and if it'll have staying power, but other companies are putting in the effort)
PS: btw, Samsung already had its own, non-Android OS with Bada (of course, developing a new OS is only the first step, getting it to be successful wouldn't be easy)
Bada lasted, what, 3 years? So it did better than Firefox OS (unless you want to count KaiOS as the same thing), but not by much? Not a great look I'd say. And things haven't gotten any easier during the past 15 years, with Apple and Google's positions being more entrenched than ever.
> Not sure if the big manufacturers would want to depend on a proprietary Google OS.
If a manufacturer doesn't want to depend on a proprietary Google OS, licencing that Google OS is not an alternative.
If they would close-source it, the community for sure will pick up the pieces.
https://www.reddit.com/r/GrapheneOS/comments/1o3vmn5/comment...
My guess is that its either HMD or Nothing. Will probably still take a while until we learn about this
> "It is a big enough OEM that there is good chance you may have owned a device from them in the past."
I think this takes Nothing out of contention.
I'd love for it to be Framework.
As OnePlus is kinda dead and taken over by oppo, I'm guessing Sony. They have some similar collaboration in the past like with Jolla. My Sony XA2 was one of the few models that could run sailfish.
I don't think that there is any need to restart a new category. Just make your new phones good enough for GrapheneOS.
GrapheneOS has close to half a million users, I think it's worth doing some adjustments.
They basically sold the brand to TCL iirc
The GrapheneOS devs are doing the right thing for the longevity of the project. Focus on a small number of phones/hardware. It guarantees its long term success.
Excellent work I think, also the Pixel hardware design offers slightly better security with the baseband.
Hoping this helps you get your hands on a cheap Pixel!
Nothing about brand new ones.
Just that the new ones might be easier to buy international.
Phone without warranty is better than phone you hate, or phone with OS you disagree fundamentally with - in my opinion.
You dont notice unless youre gaming or encoding video or doing other heavy workloads. The daily driver experience is very smooth.
The cameras and camera software is in the top 5 consistently though, the screens are also really good, so its a mixed bag hardware wise.
But yeah, it's my choice as well, because f** Sony software updates policy.
Now if you just bought a Pixel, it will be supported for 8 years, so by this time hopefully GrapheneOS will be available on many different devices :-).
this will take a while and RAM prices will be out of control for a while as well
Obviously Google + Phone makers is a "trust", its frustrating the lawsuits aren't really going anywhere.
To understand how healthy a market is, ask 'how easily could a brand new startup innovate in this area'. If the answer is 'not easy at all' - then that thing is going to be expensive, rent seeking, and actively distorting incentives to make itself more money.
There's no crypto, as far as I know, in all the binary blobs in the kernel, yet we still can't re-implement enough of them to even have a true Linux phone without reusing the manufacturer's kernel.
Its really easy to make a custom rom but hard to do serious "real life" stuff; companies don't want to make it easy. To most regular users, if they cant download apps from the google play store, and they can't use venmo\cashapp, then the OS is dead in the water from day 1
When you buy a Windows PC, the first thing a lot of tech people will do is format it and put on a clean install of Windows without all of the OEM crapware, or in these days install Linux if grandma is just using email and Facebook anyway.
If you try to do that on your Android device, your bank app is broken, most importantly not because of anything the alternate OS is doing wrong, which causes the vast majority of people to not want to do it even if it means suffering the OEM crapware, with no way for the alternative OS to fix it. And that in turn allows the OEMs to get away with locked bootloaders etc., because then they're not losing sales to a competitor that lets you remove the crapware when nobody can do it either way.
But I still haven't contacted the support to ask them to verify phones in another way.
It's crazy how locked down the ecosystem is.
[1] https://old.reddit.com/r/Magisk/comments/1lxbdpw/tutorial_ge...
> You can pay app developers to port their apps off of play services, you can pay developers to add support for your attestation keys.
an additional anecdote from my time then: they came to where i was working at the time and proposed funding a windows mobile version of our app (quite a large sum) but our supervisor finally said no, because the upkeep of now 3 apps would be too much for too few customers
you cant just throw money at devs and expect much unless you have the user base (potential market) to back it up
1. It doesn't require an entirely new app. You can ship the same apk on all platforms.
2. Most apps already don't have a hard dependency on play services.
We actually saw this play out twice with Microsoft's return to mobile (Windows phone) and web browsers, money is a pretty small part of it.
There are technical reasons, but as ever the real underlying causes are incentives. Companies realized that the OS is a profit center, something they can use to influence user behavior to their benefit. Before the goal was to be a hardware company and offer the best hardware possible for cost. Now the goal is to own as large a slice of your life as possible. It's more of a social shift than a technological one. So why would a company, in this new environment, invest resources in making their hardware compatible with competing software environments? They'd be undercutting themselves.
That's not to say that attempts to build interoperability don't exist, just that they happen due to what are essentially activist efforts, the human factor, acting in spite of and against market forces. That doesn't tend to win out, except (rarely) in the political realm.
i.e. if you want interoperable mobile hardware you need a law, the market's not going to save you one this one.
My guess is that modern hardware is too complicated for one hacker to write reliable drivers. That wasn't the case back in the 90-s, when Linux matured. So we are at mercy of hardware manufacturers and they happened to not be interested in open upstreamed drivers.
Modern hardware has turned our operating systems into isolated "user OS" nodes in the schematics, completely sandboxed away from the real action. Our operating systems don't really operate systems anymore.
On any PC, you can still use BIOS/UEFI services to get a basic framebuffer and keyboard input. You cannot do that on embedded ARM devices - you need to get several layers into the graphics stack to have a framebuffer. I tried it on the PinePhone, using existing source code as a reference, and the furthest I got was sending commands from the video port to the LCD controller and then not having an oscilloscope to see if the LCD controller replied back.
But, I'd guess this accounts for a relatively small fraction of corporate decision on lock-in strategies for rent extraction - advanced users should be able to treat their cell phones OS like laptops, with the same basic concepts, eg just lock down the firmware for the radio output, to keep the carriers happy, and open everything else, maybe with a warranty void if you swap out your OS. Laws are needed for that, certainly.
Because that's what customers want to buy. People are paying premium iPhone prices for hardware with mediocre specs and then the hardware sells out when someone like Purism or Fairphone actually makes an open one. How many sales would you get if you did the same thing on a phone that was actually price/performance competitive with the closed ones?
Meanwhile all of that "profit center" talk is MBA hopium. Nobody is actually using the Xiaomi App Store, least of all the people who would put a different OS on their phone.
The real problem here is Google. Hardware attestation needs to be an antitrust violation the same as Microsoft intentionally breaking software when you tried to run it on a competing version of DOS and for exactly the same reason.
Yes!! Absolutely agree. This needs to be made illegal.
Plenty of adversarial countries have a competent security service. A foreign government can compromise the corporation's root signing key for the devices through technical attacks and through bribery, espionage, physical intrusion, etc. And they're not going to tell you that they have before using it against your high value targets, so how do you protect them? By not relying on systems with a single point of compromise.
Since a PC was a big box of parts anyone could manufacture one. A modern phone is much more complicated.
As to why there aren’t a plethora: the market doesn’t demand it that much. The people doing it aren’t wildly successful. Perhaps that’s changing (I hope so) but I know very few people outside this community who have ever thought “I wish I could have a third party version of Android”.
Edit: I am not saying just user replaceable. I mean standardized so the same cells in a 2024 phone also works on 2025...
"Battery capacity" is like the one thing phone manufacturers still try to improve.
IBM didn't think to lock it down, the BIOS was the main blocker and was relatively quickly reverse-engineered (properly, not by copying over the BIOS source IBM had included in the reference manual). They tried to fix some with the MCA bus of the PS/2 but that flopped.
> almost every phone has closed drivers
Lots of hardware manufacturers refuse to provide anything else and balk at the idea of open drivers. And reverse engineering drivers is either not worth the hassle for the manufacturer or a risk of being sued.
> Why are there not yet a plethora of phones on the market that allow anyone to install their OS of choice?
Incentive. Specifically its complete lack of existence.
From triumph of the nerds part 2 ( worth a watch.. they also explain how IBM ended up getting and operating system from Microsoft)
https://www.pbs.org/nerds/part2.html
“In business, as in comedy, timing is everything, and time looked like it might be running out for an IBM PC. I'm visiting an IBMer who took up the challenge. In August 1979, as IBM's top management met to discuss their PC crisis, Bill Lowe ran a small lab in Boca Raton Florida.
Bill Lowe:
Hello Bob nice to see you. BOB: Nice to see you again. I tried to match the IBM dress code how did I do? BILL: That's terrific, that's terrific.
He knew the company was in a quandary. Wait another year and the PC industry would be too big even for IBM to take on. Chairman Frank Carey turned to the department heads and said HELP!!!
Bill Lowe Head, IBM IBM PC Development Team 1980:
He kind of said well, what should we do, and I said well, we think we know what we would like to do if we were going to proceed with our own product and he said no, he said at IBM it would take four years and three hundred people to do anything, I mean it's just a fact of life. And I said no sir, we can provide with product in a year. And he abruptly ended the meeting, he said you're on Lowe, come back in two weeks and tell me what you need.
An IBM product in a year! Ridiculous! Down in the basement Bill still has the plan. To save time, instead of building a computer from scratch, they would buy components off the shelf and assemble them -- what in IBM speak was called 'open architecture.' IBM never did this. Two weeks later Bill proposed his heresy to the Chairman.
Bill Lowe:
And frankly this is it. The key decisions were to go with an open architecture, non IBM technology, non IBM software, non IBM sales and non IBM service. And we probably spent a full half of the presentation carrying the corporate management committee into this concept. Because this was a new concept for IBM at that point. BOB: Was it a hard sell? BILL: Mr. Carey bought it. And as result of him buying it, we got through it.
It's not your phone, it's theirs. They're just letting you use it, and only if you're a good boy who follows all their policies and terms and conditions. Subvert this in any way and it's a felony.
Rooting/jailbreaking have had exemptions for many years now, on a three year basis which has seemingly been continually renewed, by the Librarian of Congress.
Exemption to Prohibition on Circumvention of Copyright Protection Systems for Access Control Technologies (2024)
https://www.federalregister.gov/documents/2024/10/28/2024-24...
Very little of it was open, including the headliner apps of WordPerfect and 123.
Google had the benefit of three decades to study IBM's loss of control to prevent it with Android. Aside from China, they have been largely successful.
That's a long running effort, going all the way from lobbying (DMCA and their ilk), to all kinds of hardware root-of-trust, encrypted and signed firmware, OS kernels and drivers etc etc. And yes, today we have the transistor budgets to spend on things like this, which wasn't an option back when the PC architecture was devised.
These days things are way slower and the are no exponential growth in users. Plus fast cellular networks made the speed of local hardware much less relevant. So the software became way more important and so its control.
The other notable thing about the situation is that three companies ended up simultaneously responsible for a large part of the PC platform, originally -- IBM, Microsoft and Intel. They all worked in various ways to encourage competition to each other -- the reason we see OS competition on the PC platform is that IBM and Intel both found it in their interests to allow other OSes on the platform to reduce Microsoft's leverage over them. IBM in fact created one of the competing PC OSes out the gate, OS/2, which was originally an IBM/Microsoft joint project until they started feuding. Now, OS/2 is dead, but IBM's interest in being able to support their own OS instead of Microsoft's is a big reason the PC platform was built in an OS agnostic way. People criticize UEFI for locking down the PC platform more than the previous BIOS implementations, but UEFI is still _way_ more open than basically any other platform, most of which don't have a standard for bootloaders at all. It's really the absense of a standard for bootloaders that keeps most Android phones locked down. Two Android phones from the same OEM might have different bootloaders, much less two phones from different manufacturers. We've yet to see an alternate OS with the resources to support implementing their own bootloaders for a majority of Android phones.
Here you go: https://puri.sm/products/librem-5 and https://pine64.com/product-category/pinephone/
Besides that, "app store" was just not feasible with tech of the day.
When vast majority of customers do not care, you can ship a locked down device.
You can buy a hackable phone, but it's a niche
https://www.fcc.gov/oet/ea/rfdevice
> INTENTIONAL RADIATORS (Part 15, Subparts C through F and H)
> An intentional radiator (defined in Section 15.3 (o)) is a device that intentionally generates and emits radio frequency energy by radiation or induction that may be operated without an individual license.
> Examples include: wireless garage door openers, wireless microphones, RF universal remote control devices, cordless telephones, wireless alarm systems, Wi-Fi transmitters, and Bluetooth radio devices.
https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A...
Other countries have similar regulations.
PCs don't have that restriction.
You might be able to get to the point where you have a broadcast license and can get approved to transmit in the cellphone radio spectrum and get FCC approval for doing so with your device... but if you were to distribute it and someone else was easily able to modify it who wasn't licensed and made it into a jammer you would also be liable.
The scale that the cellphone companies work at such liability is not something that they are comfortable with. So the devices they sell are locked down as hard as they can to make it clear that if someone was to modify a device they were selling it wasn't something that they intended or made easy.
And a huge reason it seems like BS is this:
> PCs don't have that restriction.
There are obviously PCs with Wi-Fi and even cellular modems, so this can't be an excuse for a phone to not be at least as open as a PC.
Where do you see this in the rules? The only thing I see that even comes close is the following sentence:
"Manufacturers and importers should use good engineering judgment before they market and sell these products, to minimize possible interference"
Maybe it's because I don't routinely deal with the FCC but to me, that language doesn't imply anything close to your ironclad rule you posted.
I'll also point out there are plenty of other devices that get sold that seemingly break your rule. SDRs, walkie talkies with the power to transmit for miles, basically every computer motherboard made since the year 2010, the Flipper, etc. At most, they simply have some fine print in the manual saying "you should probably have an FCC license to use this".
https://www.reddit.com/r/RTLSDR/comments/dx5sln/do_developer...
Depending on the power of the walkie talkie, it may require a license.
https://www.rcscommunications.com/which-two-way-radios-requi...
> MURS (Multi-Use Radio Service) – Two-way radios programmed to operate within the MURS (Multi-Use Radio Service) are not required to be licensed. They transmit at 2 watts or less and only operate on pre-set frequencies between 151 -154 MHz in the VHF band. MURS radios have a general lack of privacy, a limited coverage area, and frequent channel interference.
> ...
> GMRS (General Mobile Radio Service) – The General Mobile Radio Service (GMRS) is another of the most popular and numerous licenses the FCC granted. GMRS licenses allow for radios to transmit up to 50 watts. GMRS licenses also allow for hand-held, mobile, and repeater devices. The GMRS spectrum has 22 channels that it shares with FRS and an additional 8 repeater channels that are exclusive to GMRS.
> Virtually Every Other Land Mobile Radio (LMR) Device – Virtually all two-way radios beyond the models mentioned above are subject to FCC licensing. In fact, any device that transmits at 4 watts or higher requires coordination (and, thereby, licensing) by the FCC.
---
The Flipper is licensed to operate with a particular set of power and frequency ranges. https://flipperzero.one/compliance
For the SDR it is licensed to operate between 304.5 - 321.95; 433.075 - 434.775; and 915.0 - 927.95 MHZ range in the US.
Note that none of those are the cellphone frequency bands.
---
https://prplfoundation.org/yes-the-fcc-might-ban-your-operat...
which quotes 2.1033 Application for grant of certification. Paragraph 4(i):
> For devices including modular transmitters which are software defined radios and use software to control the radio or other parameters subject to the Commission’s rules, the description must include details of the equipment’s capabilities for software modification and upgradeability, including all frequency bands, power levels, modulation types, or other modes of operation for which the device is designed to operate, whether or not the device will be initially marketed with all modes enabled. The description must state which parties will be authorized to make software changes (e.g., the grantee, wireless service providers, other authorized parties) and the software controls that are provided to prevent unauthorized parties from enabling different modes of operation. Manufacturers must describe the methods used in the device to secure the software in their application for equipment authorization and must include a high level operational description or flow diagram of the software that controls the radio frequency operating parameters. The applicant must provide an attestation that only permissible modes of operation may be selected by a user.
and 2.1042 Certified modular transmitters. Paragraph (8)(e)
> Manufacturers of any radio including certified modular transmitters which includes a software defined radio must take steps to ensure that only software that has been approved with a particular radio can be loaded into that radio. The software must not allow the installers or end-user to operate the transmitter with operating frequencies, output power, modulation types or other radio frequency parameters outside those that were approved. Manufacturers may use means including, but not limited to the use of a private network that allows only authenticated users to download software, electronic signatures in software or coding in hardware that is decoded by software to verify that new software can be legally loaded into a device to meet these requirements.
If neither of the two major players can make an open, secure, _simple_, easy-to-understand, bloat-free OS, then we somehow need another player.
Presently (and I confess, my bias to seek non-state solutions may show here), it seems that a non-trivial part of the duopoly stems from regulatory capture insofar as the duopoly isn't merely software, but extends all the way to TSMC and Qualcomm, whose operations seem to be completely subject to state dictates, both economic/regulatory and of the darker surveillance/statecraft variety (and of those, presumably some are classified).
I'm reminded of the server market 20ish years ago, where, although there were more than two players, the array of simple, flexible linux distros that are dominant today were somewhere between poorly documented and unavailable. I remember my university still running windows servers in ~2008 or so.
What do we need to do to achieve the same evolution that the last 2-3 decades of server OS's have seen? Is there presently a mobile linux OS that's worth jumping on? Is there simple hardware to go with it?
Now with that said: so much work has gone in to Android (and by extension, Graphene) to improve on power usage/security/etc that I'm not sure I'd bother to actually run a mobile Linux device. The juice just doesn't feel worth the squeeze.
I know I would love to give them a try, but a 720 screen is an absolute non starter for me. It would be hard for anyone to sell me on just a FullHD (1080) screen in the era of QHD (2K) being industry standard. Additionally, I believe their FAQ even admits that their already low power devices only get a few hours of battery life.
Small company that deals with what hardware they can get their hands on. They're shipping a device when others are not. It's a pretty straightforward equation right now; people who want to advance the ecosystem should consider it if they want a device they can drive and build for.
Otherwise there's no real reason to not just run Graphene.
I really hoped that Huawei would go for a fork of AOSP (they could even pull the changes from Google :-) ), but they chose to go with their proprietary HarmonyOS.
I looked through https://news.ycombinator.com/item?id=46162368 and there was nothing like that mentioned.
The new Jolla actually does look really good compared to all the other avaiaobale Linix phone hardware options.
OEMs want 2-4 month cycles.
This is a perfect representation of the state of the software industry.
OEMs have quite a lot of extra steps before releasing any build to the public.
They have to pass xTS, the set of test suites required before getting certified by Google, possibly carrier certification, regulatory requirements and more depending on where the build will be released.
There are "quicker" release channels for security fixes, but I don't think it's common for OEMs to only ship those without any other change to the system.
I don't think Graphene does anything of sort, they take what's already certified in the Pixel builds and uses it. Not like they could do much aside testing on the public part of xTS.
Fair?
> OEMs have quite a lot of extra steps before releasing any build to the public.
AIUI updates are less stringent and burdensome than initial certification. Regardless much of the process is automated. Graphene has CI too. 3PL's taking 4 weeks to run automated tests is also absurd. There are some "manual steps" to run CTS-V but they shouldn't be weeks level burdensome either. This is the point, this is an industry problem.
The reason that the OEMs even have to deal with this 3PL test mess is for GMS certification, so again this is a policy decision that enforces a poor process. The bad properties of the process are not inherent to the problem space of validating builds against requirements. An industry problem.
> There are "quicker" release channels for security fixes, but I don't think it's common for OEMs to only ship those without any other change to the system.
Seems like a decision that is not user-centric.
> I don't think Graphene does anything of sort, they take what's already certified in the Pixel builds and uses it. Not like they could do much aside testing on the public part of xTS.
Private test suites for software are a toxic idea, it's in the same box as "SSO tax", and other such "pay for security" models. Given the software industry can't be trusted not to do this, I'm almost keen to see legislation to explicitly ban this practice.
They don't allow adding our Network and Sensors toggles which are detected as modifications to the permission model. They don't detect Contact Scopes and Storage Scopes but they might be considered Compatibility Definition Document violations. We don't worry about this, our focus is passing the tests which are actually relevant including the ones we've added for duress PIN, hardened_malloc, our more advanced hardware memory tagging integration that's always on, etc.
If we wanted to get access to the proprietary GTS for Google Mobile Services to see how much sandboxed Google Play passes, we could, but we focus on real world app compatibility.
That's true having dealt with some of it, nonetheless I haven't found that much of a difference due to having to use 3PL.
There's more manual steps on top of CTSV for camera and GMS, but that's all there is to it.
The only real difference I've seen is on Google's side to actually say "ok" before it getting approved.
Carriers and regulations are better on that side, but assume you have a security fix in the modem, for some carriers you're supposed (emphasis here) to redo it...
> Seems like a decision that is not user-centric.
I can see how having two release channels one solely for security and a bigger one might be a burden on some. But you hardly want to only fix security issues when you have a real bugfix you want to also release, so it makes sense to me the channels have to be merged.
> Private test suites for software are a toxic idea
To be fair on android side they're quite fine. One is specifically for GMS compliance, one for camera verification, and one for security patches verification.
The latter is janky and not as updated as you'd think, so unless you really forget to apply patches it'll pass.
With that said, the amount of people running those test suites not for certification can probably be counted on a single hand, I think that's the least of the problems.
Samsung and Google ship a small subset of the security preview patches early while we're shipping all of them. We're doing a lot of work to integrate and test those. We also have to port them from Android 16 to Android 16 QPR1 and now Android 16 QPR2. It seems they might start providing them for Android 16 QPR2 themselves but for now we had to port them for our QPR2 releases.
We also have to test and fix all the issues caused by us having much more advanced exploit protections including full system hardware memory tagging with a more advanced implementation. We uncover MANY upstream memory corruption bugs we need to fix. Features like Contact Scopes, Storage Scopes, 2-factor fingerprint authentication, etc. are not always easy to port to new versions. We still don't have early access to upcoming quarterly and yearly releases but we'll get it and then we can have day 1 updates for those instead of it taking days for an experimental release and around 1-2 weeks before it reaches the Stable channel. We intend to do much better than we are now, we just need the same early access OEMs have but don't actually use to make day 1 releases for major OS updates.
Fuzzing, actual security analysis - all those things are done by Google.
We use much newer Generic Kernel Images than the stock Pixel OS as the base. Android 16 QPR2 was released this month and they finally shipped 6.1.145 from July 2025 for the Pixel 6 through Pixel 9 compared to us being on 6.1.158 which was the latest until yesterday (6.1.159) which will be incorporated soon. It's similar for our 6.6 and 6.12 branches compared to theirs. 6.6 is the current Pixel 10 and near future Pixel 6 through Pixel 9 branch. They only update the kernel revision every 3 months in quarterly/yearly releases so this is the smallest the delay gets right after a quarterly release. They'll still be on 6.1.145 until the next major release in March 2026 so the current delay of having the July 2025 kernel in December 2025 is not representative but rather is the small side of the delay. Shipping the newer LTS revisions is not easy due to frequent regressions both in the upstream code and to a much lesser extent in the out-of-tree drivers needed for Pixels which often need small changes to adapt them to the new LTS revisions.
GrapheneOS does a lot of deep security analysis and has proposed firmware, kernel and userspace exploit protections adopted by Google. We helped them get a bunch of vulnerabilities being exploited in the wild blocked off as whole classes of vulnerabilities including perf events, reset attacks on fastboot mode and much more. GrapheneOS is focused on addressing classes of vulnerabilities rather than individual bugs. Google puts a decent amount of resources into finding and fixing individual bugs and that isn't our focus. We get the bug fixes from the upstream project many months earlier and the Pixel driver fixes from them other than cases we fix them early due to finding them with hardware memory tagging which they don't use for the kernel even in Advanced Protection mode (or most of the base OS processes either, while we always use it for both with a much better implementation in userspace).
Most of our changes are in userspace where we don't try to collaborate with upstream developers as much as we do with the Linux kernel. Most of userspace is not developed as openly in a way we can properly collaborate.
https://www.androidauthority.com/cellebrite-leak-google-pixe...
https://arstechnica.com/gadgets/2025/10/leaker-reveals-which...
You're talking about people misrepresenting what we say and lying about it while ignoring the provided evidence. You shouldn't be basing what you think GrapheneOS says from people misrepresenting that as part of attacking it.
> claims without links to any evidence
You've provided no links to any evidence for your inaccurate claims about us.
> accusations of /e/os and Iode having government ties
What our project account actually said is that both have been attacking GrapheneOS with false claims about our project and team for many years, including the false narratives you're using. We've provided ample evidence of that and linked to a recent example of the founder of /e/ and Murena supporting libel/harassment content from a neo-nazi site here. If you need that linked again:
https://archive.is/SWXPJ https://archive.is/n4yTO
We can provide dozens more examples of him supporting harassment content. We don't link spreading harassment content so we try to avoid linking to it like this. People who are hostile towards us won't actually apply any skepticism to it but rather will just spread it to try to harm us more. Why would we regularly help them with doing it?
It is a fact that /e/ is heavily government funded despite the fact that it exists to build products for their for-profit Murena company to sell.
https://www.projets-libres.org/en/podcast/e-os-a-degoogled-a...
> The European Union has subsidized us to the tune of several million for this project.
This is the same EU moving ahead with passing Chat Control. /e/, Murena and iodéOS are based in one of the countries most strongly supporting it with national law enforcement actively smearing GrapheneOS with inaccurate claims due to considering a reasonably secure device intolerable. The recent attack from Duval linked above was made in the direct context of these smears against GrapheneOS. Duval has himself used his personal account, /e/ project accounts and Murena company accounts to falsely claim GrapheneOS isn't a privacy project, isn't for regular people and is only for people to protect themselves from the state. He has directly played into trying to marginalize it and support attacks on it from the French state which supports his project. Do you deny this? We did not say they're working with the government. We said they're taking advantage of it and trying to leverage it to harm us similarly to their years of spreading misinformation about GrapheneOS and supporting harassment towards our team to boost their extraordinarily insecure and non-private products/services. If you need third party sources on that, they're in https://discuss.grapheneos.org/d/24134-devices-lacking-stand... and both Divested Computing + Mike Kuketz also cover iodéOS too, as do other experts.
> A common person isn't going to go digging where that evidence has been presented if it isn't very clearly available
Yet you believe inaccurate claims about us without evidence, including the ones you're propagating and making here. People engaging in these attacks linking to unsubstantiated claims and harassment material from each other is not evidence. A YouTube video with a self-contradictory and clearly dishonest monologue pretending to have references not showing any of what's claimed is not showing evidence. That apparently passes as evidence for you, but actual proof and things you can verify do not.
And deserved criticism is not harassment.
Open source communities should help each other, and work together, not fight.
I havent noticed a lot of that in the community myself, in which im very active. Its exceptional in my eyes. Common though is technical criticism on other projects when people ask advice about it or want a comparison with alternative. Also common is people being fed up by harassment by other projects.
The founder of /e/OS repeatdely attacks GrapheneOS in random internet threads that are only mention GrapheneOS. This contrast with the approach of GrapheneOS where they will only do a comparison with /e/OS in reponse to posts where both are mentioned and compared by others. Or, in reponse of wrong comparisons in the media or harassment (personal attacks etc.) stemming from them.
F-Droid does also have some maintainers that engaged in personal attacks against the GOS founder. And anyway what do you expect the project to do if people ask whether to get apps from Play Store or F-Droid? Pretend there is no technical security difference? If people ask questions, the project and community try to inform.
There is big conflict with Debian or Linux kernel at all. They also dont mismarket themselves or spread misinfo about GrapheneOS. They are concerned though that both heavily used projects lack a security focus.
(Typo)
https://archive.is/SWXPJ https://archive.is/n4yTO
Check out the site for yourself. The linked video is plainly filled with extraordinarily dishonest claims that are widely disproven. Copperhead is losing the legal battle very badly and should end up paying our years of legal expenses soon. Other groups attacking us can look forward to similar losses in court when our attention moves to them. Years of libel, bullying and harassment has consequences.
Here's an example of what you support by the founder of Murena and /e/ who you support linking to libel and harassment on a neo-nazi conspiracy site (check out the site for yourself):
https://archive.is/SWXPJ https://archive.is/n4yTO
The video that's linked there is an extraordinarily dishonest character assassination video filled with very blatantly false claims. The person who posted the video is unsurprisingly friends with a bunch of neo-nazis. Copperhead failed in their attempt at filing a baseless lawsuit against us and is on track to pay years of our legal fees.
A typical approach you folks take is linking to Kiwi Farms adjacent harassment content based on fabricated stories and spin targeting myself and the rest of our team. One of the two main people orchestrating harassment towards us has an identity verified Kiwi Farms account and was the one who involved them in targeting me (kiwifarms . st/members/larossmann.132201/).
What team are you talking about? JMP/Cheogram? This is the first I've heard of this.
Just wonderful. Google should know better than this, shame on the other OEMs that forced this mess.
https://discuss.grapheneos.org/d/27068-grapheneos-security-p...
This implies that anyone can download GrapheneOS firmware images and use binary diffing techniques to find what are still 0-day vulnerabilities on every Android other than GrapheneOS.
Useful! Thank you GrapheneOS developers.
Same question, how does Graphene get patches?
Currently they're only permitted to release binaries of the patches due to the embargo, this is why these patches are in the parallel stream/optional (so people unhappy with being unable to see the sources won't have them shoved down their throats).
I don't have URLs at hand at the moment but all these questions have been asked many times and explained extensively on their discussion forum.
I, for one, feel safe. I was patched since late October (IIRC) for the vulnerabilities that Android-related outlets were warning about in early December.
It's quite surreal how unsafe the standard Android is. And how Google and the big companies pretend old devices (these running Android 11, 12, 13, not updated for several years) are safe and secure. While all it takes is the user stumbling upon one malicious we page or getting a WhatsApp message they won't even see.
Well that's untrue. I'd even venture to say that with how many OEMs there are it's insane how safe Android is. Google for one updates their devices for 7 years since Pixel 6, they can't control OEMs who might have ~10 people working on their devices.
Pixel 8 https://endoflife.date/pixel
Pixel 8 line:
> Ends in 4 years and 10 months (01 Oct 2030)
It was built back when Google owned Motorola, before they sold off everything but the patent suite. And was intended to be their flagship phone - which the Pixel later became. Looking at the GrapheneOS FAQ, it doesn't look like I have a prayer of installing it on such an old device as it doesn't have the needed security hardware. Is there a lightweight Android install available?
Here is a good place to get started with your Moto X. https://xdaforums.com/c/moto-x.2449/
I personally don't care about "security" all that much, my main reason for using Graphene is freedom to use my hardware in any way I wish. This means unrestricted ability to run any program on the phone from any source. Sideloading restrictions don't apply to Graphene, and it is also impossible for state actors to impose things such as client-side scanning of text messages. It's also immune to unwanted AI anti-features.
I use my own "cloud" infrastructure with my phone and I am not interested in using Google's. My Graphene device is configured to route all traffic through Wireguard tunnel and my DNS server. I also use exclusively use my own email server and "cloud" storage for all non-work related purposes. Graphene makes this easy by not leaking any information to Google.
I haven't switched it to Graphene OS yet because I read that there are issues with NFC and a few other things. I assume this new phone won't have those problems so I think that will be my catalyst to do a big overhaul.
The OEM partnership would not change that.
In non-NA regions there may be more options for mobile contactless payments using apps that are not Google Wallet/Pay. So it also depends where in the world you are.
GrapheneOS wants to make a FOSS Android with the security model that makes it hard for any bad party to break into the phone.
LineageOS wants to make a FOSS Android that respects user's privacy first and foremost - it implements security as best as it can but the level of security protections differs on different supported devices.
Good news is that if you have a boot passphrase, it's security is somewhat close to GrapheneOS - differing in that third parties with local access to the device can still brute-force their access whereas with GrapheneOS they can't - unless they have access to hardware level attacks.
GrapheneOS is both in terms of security and privacy the best but currently only supports pixel phones.
LineageOS is trying to support as many devices as possible still with lot of google connections and missing security updates.
>Good news is that if you have a boot passphrase, it's security is somewhat close to GrapheneOS
its not anywhere close https://grapheneos.org/features
Obviously it would be preferable to have up to date security patches, but as long as there are plenty oven even more easily exploitable devices, and there is no WannaCry level attack ongoing it is a risk I'm willing to accept for more user freedom.
Is that actually true? It's such a big deal, and I see little to no work being done on this front.
Anyone have any idea what GrapheneOS actually deblobbed?
Nobody, including Graphene, is getting away with building their own modem firmware. The reduced blobs are on userspace and some HAL components.
Unrelated, but this led me to find gnuclad, which may be somewhat externally maintained and is used to create the cladogragms.
LineageOS has a place for those who care less about security and more about features, "freedom", compatibility, community etc...
I was a LOS user and maintained my own forks for devices, but switching to GrapheneOS was a good decision and I don't really miss anything.
So if the bootloader can be relocked and not passing Play Integrity scam is not a problem, Lineage may be a better option. Better than nothing, that is.
Poof, it's transformed from unusually-glitchy e-waste to a tool someone can actually benefit from.
> So if the bootloader can be relocked
Their website says they recommend against that and will not support it, because of a high chance the device will get bricked. :(
You can have root to control your own device on Lineage, but not Graphene.
I stand corrected. Still, as you say, less point in it since it breaks their security model.
It breaks the entire point of the security model on ALL android devices. It isnt recommended on any Android distribution. It doesnt matter if its LOS or GOS
For a list of security features see here [0].
Battery life is still better than stock in my case, and it's just as reliable as sandboxed Play. Highly recommend.
There are plenty of deals for pixels under $820: https://slickdeals.net/search?q=pixel&searcharea=deals&searc...
A used 256GB Pixel 8 in good condition is $320. https://swappa.com/listings/google-pixel-8?carrier=unlocked&...
The list linked above (and the price tag deduced from it) is restricted to unlocked phones only for this reason.
will other phones be supported? why only pixel?
Also, "people" who buy a Google-Pixel-level phone every two years are likely among the richer... let's say 10% of the world's population? Probably even less. The rest - don't do that.
A connected world full of devices with excessively vulnerable hardware & software is also something GrapheneOS are desperate to avoid.
The baseband hardware is not integrated the same way like other phones are.
>A component being on a separate chip is orthogonal to whether it's isolated. In order to be isolated, the drivers need to treat it as untrusted. If it has DMA access, that needs to be contained via IOMMU and the driver needs to treat the shared memory as untrusted, as it would do with data received another way.