> 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.
Oh that's one of the best news in the smartphone world in a long time.
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
I have been trying to come off of google and cloud by building — quite slowly — my own nas server which has 2 nodes in two geographic regions where I am building certain services like cloud storage and backup, webhosting etc. But I think there are a few key things that need to be community driven to really get rid of this duoply.
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].
It means any 3rd party even the app provider cannot read your data or the output of the function run. They can provide some data/resources like say map tiles, PoI data and a function to run.
I'm not knowledgeable enough -- what would it take to escape the Apple/Google duopoly?
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.
There are some good stuff on the software side that people mention, but a big one is the driver support. We would need device makers to upstream support so there is less worrying about reverse engineering or needing to run modified ROMs based on old builds. Or just publish specs on the hardware that is enough for implementation. Sure, you can buy a specific phone and run a de-googled android or linux, but that only really works for the hobbyist who wants to spend time doing this. Which makes it difficult to create a market that encourages developers of software to port their software or write new software. With out being able to broadly support devices, most people are gonna be better off running Google's android.
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.
Any one of us here could learn the skills to design a smartphone. It won't necessarily be good, but I remember that years ago, someone made one with a touchscreen hat and GSM hat atop a Raspberry Pi, rubber-banded to a power bank. I'm sure any one of us HN users could do this. And it worked. Quality only goes up from there.
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.
This is not as simple as you're saying. Making a new phone not relying on proprietary drivers tied to Android is impossible without a huge effort: https://news.ycombinator.com/item?id=21656355
Or use everything via the web browser; but yes, I think apps are the main reason we can't just have a generic Linux phone OS on an open hardware platform
Apps make or break operating systems and app stores. Just ask Microsoft (Windows Phone) or Huawei (HarmonyOs). IIRC amazon was paying devs to publish to their app store or something like that.
Thankfully, some apps have both web and native mobile versions but for a modern digital life, the critical apps are sadly not on both versions.
No. There are a few that claim to, but none of them are actually any good. Waydroid, for instance, requires that your kernel is compiled in basically "Android mode" (e.g. binder enabled).
> Waydroid, for instance, requires that your kernel is compiled in basically "Android mode" (e.g. binder enabled).
Waydroid needs you to have a single kernel module, which is in mainline Linux and just happens to be disabled in many desktop builds. That hardly makes it an "Android mode" kernel, and I certainly see no reason why it should make the system no good.
> Any one of us here could learn the skills to design a smartphone.
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)
As I wrote: 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.
Good luck getting that to perform. Or even boot. High-speed buses are the darkest of the dark arts to design, at the kind of frequencies particularly PCIe runs even the slightest trace length mismatch, impedance issue with the PCB itself, vias, or even external RF sources can, do and will mess with your sanity.
That's my entire point. It's not easy to design a complex thing such as a smartphone.
> I'm not knowledgeable enough -- what would it take to escape the Apple/Google duopoly?
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.
> 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.
The private key used for attestation is stored in the secure element hardware, which runs its own OS, completely inaccessible to the main hardware's OS, even with root.
Some apps don't actually check the attestation signatures, so they could be spoofed for now, but if spoofing became common, apps would just get strict about checking attestation.
Why not run Android directly, such as using Graphene OS. It's decades ahead in both OS architecture, developer tools, and developers compared to non Android based Linux operating systems.
Graphene uses the Google codebase, so Google is choosing its long-term development strategy and standards it will support. It's like choosing Chromium to escape Chrome.
If someone is making a new browser, considering you want to support the same web standards as everyone else, being independent is pretty low on the priority lists. In fact it is more of a liability since it could make for compatibility issues.
The same can be said about the Linux codebase. Tomorrow Linus could private his branch and stop supporting public releases. If AOSP goes closed source then people can fork it and continue to maintain it.
I do agree that each company's influence in case of the kernel is much lower, than Google's relevance in Android, but there are other big-ish players in the space as well, like Samsung.
Well if you rely on running Android apps, you still rely on Android.
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.
> I think the easiest way to do that would be to run Android in a VM.
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.
You could, but using containers requires that your kernel directly provide and secure Android-compatible functionality, such as binder. A VM gives you more options for abstracting that functionality.
If you expect to be "essentially android, but a little different", containers make sense. If you want to build an entirely different mobile OS, but provide Android compatibility, I think a VM is much more likely to give you the flexibility to not defer to Android design decisions.
How do you run WhatsApp or Signal without a smartphone? Pretty hard.
If your answer is "don't use them", then you're not living in a country where the vast majority of communications are done on WhatsApp or Signal, good for you I guess.
Yes that's fair. I have a an old iPhone without a sim that I use as my master for those apps, but I keep it in a drawer since the desktop apps work fine. Funny enough the phone the app is installed on doesn't have to be the same phone you use to register by number, so the number I registered with is my flip phone
Access to Signal and Bitwarden are the only two apps I really need daily that keep me on a smartphone. I have tried using a feature phone in the last couple years, but honestly I might as well just not have a phone at that point as almost all my communication is via Signal.
Well honestly that's part of the flip phone lifestyle, if someone doesn't want to call me, that's fine, they can send me an email. We don't have to bring Google or Apple into this relationship, it's a choice people make because the prefer texting and being available to everyone they ever met 24/7
> We don't have to bring Google or Apple into this relationship, it's a choice people make because the prefer texting and being available to everyone they ever met 24/7
You're changing the discussion now.
The original point is this: Given that people want to be able to text with their friends in what is perceived as a normal way, how can they do it without a smartphone?
If you change the rules ("Given that people are fine being disconnected"), of course it changes everything.
I don't think that 24/7 availability is universally perceived as "a normal way". A large number of my contacts will answer several days after a message. In my experience it is usually only inside the nuclear family that people expect answer within 2 hours and these are the kind of people who can always choose to call instead of text if they know their child/sibling/parent is not usually text available.
I don't know how many time I would have to repeat it, so I'll do it one last time.
The beginning was:
> what would it take to escape the Apple/Google duopoly?
To which someone answered:
> Has no one mentioned not using a smartphone as an option?
To which I answered that in a ton of situations this is just not an option.
And yet I keep getting answers that give examples of when it is an option. Sure, sometimes it is an option. Now for the majority of normal people who don't consider "not having a smartphone" as an option, I was saying that it is very, very hard to escape Apple/Google.
I am NOT saying that most people would die on the stop if they suddenly did not have access to a smartphone. I am saying that there is no solution to that that most people would consider viable.
> I don't think that 24/7 availability is universally perceived as "a normal way".
I never said 24/7 availability. I said "not having access to WhatsApp/Signal [in one's pocket, some of the time]". The part in brackets was implicit because we were talking about smartphone operating systems.
Doesn't really make sense in a conversation about security (the HN post was referencing security).
Traditional desktop OSes (Windows, MacOS, traditional Linux distros) are just at an entirely different level than modern mobile OSes (Android OSes, iOS) and ChromeOS. They also often run on less secure hardware, especially compared to a Pixel.
They don't publicize it because they'd rather sell all the data they don't have already through your payments and bank movements but many still send you a dedicated device if you mention you don't have a smartphone.
You can escape the duopoly by using a GNI/Linux phone, Librem 5 or Pinephone, but don't expect any support from Google or Apple for them. I'm using the former as a daily driver.
GrapheneOS doesnt really proactively attack GNU/Linux. What happens is that there are posts on the internet about GrapheneOS or mentioning GrapheneOS in which or under which completely wrong comparisons between GrapheneOS and GNU/Linux get posted. It makes sense that you care to clarify or correct if you spot people are talking about your project and are (intentionally or unintentionally) spreading wrong information about it by making comparisons based on misconceptions or falsehoods.
The thing you link about restricting network traffic doesnt make much sense. GrapheneOS has a proper network permission which other OSes dont have. The outbound traffic restrictions to certain destinations which are being referred to are just a bad approach. You can send the traffic to one server and just process it there and send out to other servers.
You also say :
> Also, if I explicitly don't trust Google with anything, GOS is extraordinarily insecure for me until a new vendor
If thats the case, dont opt for GNU/Linux either given the large code contributions made by Google. Also avoid any software built with LLVM, written in Go, written in Flutter, using Angular, ...
The two "problems" you link arent really huge security issues. How is GrapheneOS having access to the embargoed patches and being able to ship them a security issue? Also the planned sideloading restrictions dont even apply to GrapheneOS. It would only apply to certified OS that license Google Mobile Services. Also, that isnt even a security issue. Its a freedom issue.
> How is GrapheneOS having access to the embargoed patches and being able to ship them a security issue?
This is not the actual issue. The actual issue is that existing patches for a known vulnerability become unavailable, because Google decided so, making GOS potentially insecure. Patches without the source code shouldn't be trusted.
> It would only apply to certified OS that license Google Mobile Services.
Until Google alters the deal.
> Also, that isnt even a security issue. Its a freedom issue.
There is no security without freedom. If you're protected by a steel door, but you don't have the key, you aren't safe: You're imprisoned. You can't protect yourself from Google without having freedom to run what you want on "your" device.
Im not trolling. You say you dont trust Google at all. Thats your position. Then my argument is to not trust their code, regardless of which project its submitted to. How is that unreasonable. Your argument is the unreasonable one. You somehow think contributions by other companies to Linux would balance out or erase your trust issues with the Google code? Why would that make any difference.
> This is not the actual issue. The actual issue is that existing patches for a known vulnerability become unavailable, because Google decided so, making GOS potentially insecure. Patches without the source code shouldn't be trusted.
The issue gets patched. Whether the code is published doesnt change the code... People can also sti reverse engineer the code. Its not a black box. Its often just Java code. You can easily decompile Java, bytecode maps easily to the source code. Its an effort you have to do, yes, but so is reading and properly auditing the source code as well. You seem to think publishing the code somehow magically makes it more secure. While that isnt true. People would still need to properly audit it. It barely happens in practice. And it can also perfectly be done with compiled code.
> Until Google alters the deal
If Google were to put the restriction in AOSP, GOS can simply remove it from the code... And if its not in AOSP than it doesnt impact GOS.
> There is no security without freedom. If you're protected by a steel door, but you don't have the key, you aren't safe: You're imprisoned. You can't protect yourself from Google without having freedom to run what you want on "your" device.
This metaphor doenst make any sense in relation to the planned sideloading restrictions. I suggest reading the blogposts from Google about what the process will look like.
> You made a general statement about attacks from GOS on GNU/Linux.
No, I provided two specific examples, one quoted and another linked to. None of them happend in the context of wrong comparisons being made.
> You say you dont trust Google at all. Thats your position. Then my argument is to not trust their code, regardless of which project its submitted to. How is that unreasonable.
Your argument is completely unreasonable. Google has full control over Android and therefore GrapheneOS. It has very little control over Linux. All their contributions to Linux are carefully verified by many independent
parties and suspicious things not accepted by community are rejected. The latter doesn't happen in Android, see my examples above.
> The issue gets patched. Whether the code is published doesnt change the code...
Only if you 100% trust Google. I see you do and promote them. I wonder why you would defend a trillion-dollar, monoppolistic megacorp hostile to its users.
> People can also sti reverse engineer the code.
This takes huge effort and time. One can't rely on it to be secure.
> If Google were to put the restriction in AOSP, GOS can simply remove it from the code...
The effort to keep a hard Android fork up-to-date will grow exponentially. I don't expect that GOS team will manage to do it for long.
> This metaphor doenst make any sense in relation to the planned sideloading restrictions.
This is exactly what is happening with Android right now. Users are constantly loosing their control over the device in the name of the false sense of security.
> I suggest reading the blogposts from Google about what the process will look like.
This is not even funny. Are you working at Google? I suggest you to read blog posts by a non-profit instead: https://eff.org.
> No, I provided two specific examples, one quoted and another linked to. None of them happend in the context of wrong comparisons being made.
You made a general statement here ("being known for"). You put a link there indeed with a quoted example and another link.
> Indeed the GrapheneOS community is known for attacking the GNU/Linux mobile with false claims, https://news.ycombinator.com/item?id=45562484.
You have to look at the parent replies of what you link. Read the thead properly, please. Like I said , "What happens is that there are posts on the internet about GrapheneOS or mentioning GrapheneOS in which or under which completely wrong comparisons between GrapheneOS and GNU/Linux get posted". Replies that were literally mentioning GrapheneOS got a reaction. Thats not an unfounded attack. The statements that those other options are less secure are clearly backed up with technical information.
> All their contributions to Linux are carefully verified by many independent parties and suspicious things not accepted by community are rejected. The latter doesn't happen in Android, see my examples above.
That's really not how it works in practice. There is a ridiculius amoumt of code and code changes. Systematic proper exhaustive auditing doesnt happen. Also, you distrust Google and think they are malicious. Google can do their best to hide bad stuff in their code so quick reviews wont notice it. Do you think malware developers write functions called doTheBadStuff()?
> I see you do and promote them. I wonder why you would defend a trillion-dollar, monoppolistic megacorp hostile to its users.
I am not promoting Google. I am just countering your posts critizing Google using bad arguments. Google is a multi-faceted compamy some of the things they do are good for end users, some aren't, most things will be liked by some and disliked by others.
> This takes huge effort and time. One can't rely on it to be secure.
Reading and properly understanding source code also takes huge effort and time. And like I said, if you dont trust the devs, you cant trust function names, variables names and code comments to give a faithful portrayal of functionality anyway. So do you really lose that much if you decompile Java bytecode and mainly just miss naming and comments? It can even be argued it will remove preconceptions and let you read the code with a more open mind. Its a hurdle and annoying for sure, though. I would prefer Google to lower the embargo as well. But, public source availability just isnt the magic silver bullet you think it is.
> The effort to keep a hard Android fork up-to-date will grow exponentially. I don't expect that GOS team will manage to do it for long.
You dont need a hard fork for that. If the sideload restriction were to be put in AOSP you can remove that in a soft fork.
> This is exactly what is happening with Android right now. Users are constantly loosing their control over the device in the name of the false sense of security.
I agree Googles plans arent a good approach. But it isnt a false sense of security either. Registering app IDs and associated public keys is a usefil thing. There are other, begger approaches though, tbat dont have the downsides of what they planned.
> This is not even funny. Are you working at Google? I suggest you to read blog posts by a non-profit instead: https://eff.org.
Based on what you were saying and your bad metaphor it is just clear you arent accurately informed or up to date about what the sideloading restrictions will be. The best place to read what the procedures will be is in Google's blog posts and documentation. I am not saying you have to go read that to make a value judgement on the merits. You just need to read that to understand what is actually being talked about. I dont like Google's plans either but I am aware of what they are.
Something being a non-profit doenst automatically mean all posts they write are of good quality. EFF does many good things but I dont see why their posts about things are somehow automatically good and authoritative because of their non-profit model. Best to judge individual posts on their merit.
Google has implemented lots of privacy and security features in AOSP over time. The app sandbox and permission model has evolved a lot, in a good direction. The codebase is also modernized with the increasing adoption of memory safe code. At least Google seemes to have a thought out development strategy to enhance security and privacy, contrary to the projects you mentioned elsewhere in this Hacker News thread.
Also, what you link doesnt prove what you think it does. Manifest V3 is a very good thing for privacy and security. It restricts and controls the access of extensions much more. With MV2 you have much less control over your data.
> It restricts and controls the access of extensions much more.
You mean, it restricts users even more and gives to websites the freedom to track you? I won't engage in further discussion with you, you're just trolling.
You link three things, that doesnt equate to "every independent organization". One of your links is a post by Brave and Brave isnt independent in this. The unsubstantiated fear of people for MV3 is beneficial for them, it could grow their userbase because they keep the support for MV2.
Content blocking (ad and "tracker" blocking) are convenience features, they dont foundationally improve security. Defining what a tracker is is difficult and you cant list them exhaustively. Also smart businesses and organisations can just shift to sending all data to the main domain and handling it server side to send it onwards to other domains, including third-party domains. If you dont trust a site to not send data to third party domains directly, why do you trust it to not send it indirectly?
No, I meam it restricts extensions because it does. Vouching for MV2 is like vouching for an Android OS without a proper permission model. MV3 helps against tracking, its good for privacy and security. If you want the convience of content blocking, uBlock Lite still works good enoough for many people. Though, you still lose on security and meaningful privacy (again, define a tracker and list them all, impossible) because extensions in general hurt site isolation and increase your fingerpint.
> You link three things, that doesnt equate to "every independent organization".
Seriouslu, is this the only counter-argument you could invent? I didn't have the goal to list all independent organizations in the world. Now, you have to find one saying the opposite to EFF.
> If you dont trust a site to not send data to third party domains directly, why do you trust it to not send it indirectly?
Against tracking by whom? By FLOSS add-ons intentionally installed by user and verified by the community? In contrast to random, untrusted websites running megabytes of proprietary JS?
If you're stateside and want a shipping Linux phone today, [FuriLabs](http://furilabs.com) is another option.
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.
I admit to being shocked that such a common phrase isn’t widely understood, but this site has plenty of international traffic so I can only say thanks for the context comment. :)
Yeah, it's funny how our contexts shapes what we believe to be universal :) I had the same experience with "ground floor" and "first floor", where seemingly every country has a different understanding and way they use those. Or even what "Caravan" actually is seems to differ too. Language is fun :)
> but still I'd like to choose my hardware and software separately interoperating via standards
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.
The success of an OS is inevitably linked to the availability of apps. A "smart" phone today is basically useless if it can't run either iOS or Android apps. Projects like Waydroid can make Linux phones viable, but since there are approximately zero native Linux apps for phones, you might as well use Android as a FOSS base. This is precisely what Graphene and Lineage do.
I have an Xperia with Sailfish OS. The Android app support ironically ends up what makes it usable, but the new patch isn’t released with kernel support that actually makes the IO work properly. Its own app selection is pretty small. It would be cool if all desktop Linux didn’t need an entirely new skin to work at this form factor, else I could get what I needed. I also use Nix to smooth over some of the repository shortcomings.
Sailfish OS just takes the wrong approach, to be honest. It makes more sense to have the more secure OS at the host (Android) and the less secure as a guest for compatability (traditional Linux distro). Its also problematic that the app compatability delivered via the Anseood support uses an outdated Android version etc.
Pixel phones currently have the additional benefit of a full Debian OS running via AVP. This is (imo) on par with or better than having Termux on a rooted device. It's still fairly off-the radar which makes it a really good time to be exploring it's uses.
I agree, it has been lots of fun testing around in the KVM. Recently a GrapheneOS update even included the Button to attach to the "screen" of the VM. It also has GPU passthrough iirc?
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
Totally agree. Pixel devices are probably still the best Android offering, but I originally got into the ecosystem because it was less confined and that appears to be changing. While I'm likely not representative of most consumers, I would love it if I could choose both the right device and right software for my particular needs .
We will see how that goes. I love GrapheneOS, I've used it for years, but the details matter. An OEM partnership might promise a lot at the start, but a lot can change between now and delivery.
What do you mean? Graphene OS devices DO support Hardware-based attestation (AOSP standard), they just don't support STRONG or DEVICE Play integrity checks.
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.
Will never happen. Banks will not support this unless insurance companies include that. And that will never happen because they will never support something that a large company doesn't committ to.
I'm writing this on a grapheneos pixel 5. I have the app for very-large-USbank and a few others. With 'exploit protection compatibility toggle' enabled they works fine. In what regard this applies to device attestation I couldn't say.
GrapheneOS has device attestation support on Pixel devices, i.e. it passes SafetyNet. It's just that some apps (e.g. Google Pay) explicitly exclude it.
They depend on the Play Service and Play Store, that's for sure. But I'm pretty sure they know it's a risk already.
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.
Pretty sure that Google sells the Android licence for as much as they think they can. Make it too expensive and the manufacturers will try to move away.
What's the alternative? I doubt even someone as big as Samsung will be willing or able to develop their own alternative OS (atleast one that can actually grab marketshare enough that critical apps get ported), and I can't imagine them wanting to hitch their wagon to the Linux alternatives.
> I doubt even someone as big as Samsung will be willing or able to develop their own alternative OS
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)
Huawei has a whole-ass Chinese government behind it with quite a lot of incentives to move away from Google. Samsung does not. Heck, China's making its own GPUs and x86 CPUs. They're not great, but when the incentives over there are that strong, the market forces are clearly in a whole different universe compared to the rest of the world.
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.
> Huawei has a whole-ass Chinese government behind it
I don't like how Chinese companies systematically get reduced to "it's because the government can help them". The US TooBigTech get a ton of help from the US government, starting with political pressures when other countries want to regulate them.
Huawei have really good technology and very competent engineers. It's not the Chinese government that does the engineering.
DJI is years ahead of everybody else technologically, and that's again not the Chinese government doing the engineering. Let's stop believing that the US are superior in every single way and that someone else doing better means that they must be cheating.
Equally lets not forget that china sees this as a key strategic necessity for a forced reunification attempt on taiwan, both for national security and the ability to produce chips solo.
Two things can be true. They can have great engineers and government money. Theyre not mutually exclusive.
Governments all over the world try to support their economies. It's not just a Chinese thing. How much does the western world invest in LLMs? But for some reason, we only call it "cheating" when China does it and is more successful than us.
What an outburst lol. I didnt call it cheating. Its just as worth noting as when it happens elsewhere. Perhaps you should stop reading what isnt there.
Now that their market is established, I don't think open-source is a requirement anymore. They would of course share with hardware vendors strategically.
Those OEMs are responsible for the Android lock-in situation, and they do profit off it. They have the power to break that dependency easily with any alternative platform of choice.
Consider a GNU flavored Linux distro (includes busybox+musl also) or a BSD as an example. The difficulty that their devs face on smartphones is the driver set. Everything above it is open and free for anyone to implement any functionality without the need for any reverse engineering. All that the OEMs need to make them work is to release the hardware drivers for the platform - especially of the RF baseband. Open source drivers are preferable, but even proprietary driver blobs work to some extend (like the nvidia proprietary drivers on PCs).
But if the OEMs do that, then people would do a lot more with their smartphones. No more OEM blot/malware, infinite customizability and app options and the biggest of all - endless updates. People would use them till something in it dies, and then use it for something else that doesn't need the dead part. For example, how many smartphones are thrown out because their screens died? How many kubernetes clusters could you build with them? Naturally, that would affect the phone sales and OEMs certainly don't want that.
So then, what happens instead? Have you noticed how Graphene and Lineage struggle to support devices that already run Android? Obviously the drivers for AOSP exist. Google and the OEMs enter into a direct partnership where Google supplies the Android part with all its proprietary and play components, while OEMs convert it into the final blobs after adding their drivers and malware. The only way an external party is going to get those drivers is if somebody manages to extract them from those blobs. The OEMs supply updates for them for a few years and conveniently drop them after that. The consumer is forced to buy a new phone eventually, because their software becomes hopelessly outdated.
In addition to this, similar restrictions are imposed by manufacturers of subsystems like SoCs and RF baseband. Make no mistake about it. No matter how open any of it seems, the entire group of companies involved in this is a racket that's out to squeeze out every penny and bit of personal information from you. The OEMs are very willing participants in this scam.
More and more functionality is locked behind closed-source play services. AOSP is basically useless at this point, it can't do much of anything without Google Play Services.
Well, in the much longer term they have usually mentioned they would like to use a more secure/private foundation (more in the direction of Qubes/Redox/Fuchsia) with a compatibility layer for Android apps if they have the resources to do so.
Has the OEM in question been revealed yet? Likely not one of the major OEMs because they all lock their bootloaders. I'm crossing my fingers it's Fairphone but that's because I love my FP5. The GrapheneOS devs have been pretty harsh towards Fairphone because of their slow updates.
Those are no longer big these days so no. Also, they're not going to restart a whole product category just for grapheneos.
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.
BlackBerry hasn't been OEM for their last few phones - the KeyOne, 2LE, and 2 were all outsourced to TCL, who is still making handsets. This would also fit with BlackBerry's security image, and even pull in the OnwardMobility vapourware.
I'm every bit as skeptical as you are, and in no universe is BlackBerry the OEM in question, but I would like to live in my delusion until GrapheneOS proves me wrong - I want a keyboard, dammit!
If you've run a open source project almost of any size, it's quite a task having to support it on various devices scenarios.
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.
Damn, I just got a Pixel 10 pro XL for installing GrapheneOS. I hate how below average Pixel's hardware is and I wouldn't have minded waiting a couple of more years for this.
Pixel with GrapheneOS is still great. And it may take 1-2 years before GrapheneOS gets on this new device.
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 :-).
Why was it that in the early PC days, IBM was unable to keep a lid on 'IBM compatible', allowing for the PC interoperability explosion, yet today, almost every phone has closed drivers, closed and locked bootloaders, and almost complete corporate control over our devices? Why are there not yet a plethora of phones on the market that allow anyone to install their OS of choice?
Nobody gave you the actual answer. IBM was under an antitrust decree and had to openly license their technology for a nominal fee. (Supposedly about $5/PC.) So yes, they were in a hurry and used generic parts, but they still had tons of patents on it. When they got out from under this, they came up with Microchannel.
IBM had/has a monopoly on mainframe systems. But they never were really dominant in midrange systems (e.g. VAX, UNIX), and Microsoft and Apple etc became huge companies in the PC market. So you can't really disagree with the rationale.
Obviously Google + Phone makers is a "trust", its frustrating the lawsuits aren't really going anywhere.
I continue to be of the opinion that many of our economic problems could be improved with more competition. (Depending on your definition of "problem" of course. The current state of affairs is fantastically profitable some.)
Oh for sure. Why are movies scattered all over oblivion? Because there's no simple marketplace for licensing movies, it's a closed market that requires doing lots of behind-the-scenes deals. Healthcare? Only specific providers can make medical equipment, tons of red tape, opaque billing structures, insurance locked out in weird ways, etc.
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.
This and also cryptography technology was not nearly as sophisticated and easily accessible as it is today, and where it existed it was pretty slow on the hardware of the time.
How much of it is cryptography? The only notable cryptographic locks are just the TPM-backed Widevine and the infamous Play Integrity, both rarely required due to how many older devices that would lock out.
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.
Secure Boot (or whatever it's called on each hardware platform) relies on trusted cryptographic keys to sign "the next step" in the boot chain, all the way back to the bootrom. This is how the higher-level SafetyNet attestations work on Android, and equivalent features on iOS, XBONE, etc.
You're getting a lot of indirect responses. If you've ever tried to mod your android phone the answer is simple. Its google play services and hardware attestation for things like banking websites.
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
Yeah but lots of phones you can't get ROMs for from a reputable source, and I sure as heck don't have the know how or time to build one, even if possible, which a lot of times is not due to locking down bootloaders, drivers, etc.
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.
The thing is they are the best e-scooters provider in town. They have fantastic support, few times agreed to my feature requests. They have very forgiving policy for when you forgot to lock the scooter and so on. I really believe that if I messaged them off season (when they work on the app, like now in winter), and suggested changing the way they attest phones, they would consider using the attestation that GOS can pass.
I think you're not asking for enough here. A scooter rental app does not need to attest phones. It doesn't even have a bad excuse for wanting to attest phones since payment information is surely stored server-side and it would be surprising if the scooters didn't have their own network connections and GPS trackers.
Years ago I used to love playing around with roms on my phone on XDA and it worked OK. I don't know what folks use these days. But as recently as a few years ago I merely rooted my phone and I couldn't use a lot of apps, not just banking, but even some games.
There are tools to make your device appear to every app as running in a non-rooted environment. Here[1] is a tutorial on how to bypass Google/Samsung Wallet detections. There are threads for different apps and it will quickly turn into a cat and mouse play when Playstore app itself updates, but as the phone is rooted, someone will continue to find a way to bypass attestations and will post a comment on Reddit or XDA explaining how to do it.
This just shows that the barrier of entry of a new phone OS is more than $0. You can pay app developers to port their apps off of play services, you can pay developers to add support for your attestation keys. Considering how many billions of dollars Android makes for Google, there is a room for a return on investment for an alternate OS to enable investments into a new OS.
> You can pay app developers to port their apps off of play services, you can pay developers to add support for your attestation keys.
microsoft literally tried this back in the day when android/ios was rising against windows mobile... spoiler: it didn't work
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
That's akin to creating a new browser and pay site owners to support your client. You can do it for a few dozen sites but that can't be your primary strategy.
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.
How much do you want to pay? Who will be paying? Big companies will probably laugh such an effort out of the room, nay, they will not even let you into the room to talk with them.
Have you ever tried to pay a bank to do something for you ?
Trying to get some scale, you're hypothesizing about giving 10 millions to HSBC to make business with your startup, when they're throwing away 500+ millions every year just to cover their money laundering.
But what what I'm asking for is only a small amount of engineering time to add 1 line to their gradle and change 1 line in their app's code. This isn't a deal spanning many engineering years doing on going work and having to measure how effective things are. It's a small change plus the overhead of making a deal and getting through the beurocracy.
I see it akin to the proverbial "not getting out of bed for less than XXXXX". You're getting out of bed every day, for free. But having someone make you do it for a specific reason will be an exponentially harder proposition.
> 1 line in their app
Aren't you asking them to maintain compatibility outside of Play Services and be on available on your platform ? That's a whole project, including their (or their contracting shop's) validating the whole new stack from a security and technical perspective, and a legal and business check on what that actually means to them.
Perhaps we can look at it from a darker perspective: if a random guy came to the bank to ask them support for their parralel phone ecosystem, the bank would at least want to know what they're getting into and what's in it for them. Especially if they're offered 10 millions for allegedly one line of code.
I just made up the figure. Perhaps 10 billion dollars is more enticing. Perhaps you have to purchase the company outright and then dictate they add support. My point is that it's not impossible to get the apps people need to work on an alternate Android OS. It is a matter of funding conpatibility. You can find a niche audience of people to start out with to make a competitive OS for them. And then overtime expand that audience more and more.
>Aren't you asking them to maintain compatibility
Typically the complaints about banks is that they use the Play Integrity library which doesn't trust other operating systems. So the ask is to support the Android API for integrity and to trust the key of the OS provider. This would be done via a new library to make integration easier and more foolproof.
Key clients requesting support for the alternative OS will be a way faster route IMHO. The same way nobody bribed banks to support android, they saw the market share and potential and decided by themselves it was a worth doing. Which is why it came so late.
I understand you're offering a way to get around the chicken and egg problem, I'm saying dealing with the supply part is crazy hard. Somewhat paying users to buy into your ecosystem despite the lack of support could be a better use of money (I'm thinking about Meta subsidizing Occulus until it got some traction, and I assume it's still in the red after so many years)
> the Android API
People loosely explain the lack of technical challenge, but from the institution's POV you're asking them to expand their trust from Google, a US company which will be solely responsible if anything critical happens...to potentially each single phone maker, whoever happens to be selling the device to your clients ?
If Google didn't exist that's what they'd do. But Play Services is a thing. The more I think about the less I see an incentive for any established player to do that move until customers are actively clamoring for it. There's just no upside otherwise.
Where do you think the creators will get this money from? Look at existing ones, they are cash strapped as they are, paying a million to get an app over beyond their budget, let alone 10 million
Investors. Trying to become a new competitor in an established industry often takes a large amount of capital. If you tried to create a business to compete in another industry, you'd also need to find investors or other forms of financing if you are cash strapped.
Investors are not dumb. The current duopoly is entrenched and merely asking for money to create an alternative os won't give you investment. Microsoft and Nokia among others failed big time even though they had plenty of money and competing operating systems. Investors give you money if they think you will be successful and return a multiple of that investment within a reasonable timeframe.
You need to solve the 3 player problem before you even ask for money: getting device manufacturers in even though you have no operating system, no devs and no users, getting devs even though you have no operating system, no devs, no users and no devices, getting users even though you have no device, no operating, no devs and no apps.
You need an MVP that shows promise towards all the above if you seek money.
This is like taxi on demand app business or the takeaway delivery business but with more players and with a higher minimum funds requirement. Plus the fact that unlike taxi apps or takeaway apps, choosing an operating system is a zero sum game so you are competing in the most direct way against well known and well established brands like iOs and Android who are funded by the richest companies on earth. Unlike Uber vs Lyft, where a user can install both and use both, your battlefield only has one victor. And given that other companies with more funding that you will ever see in your lifetime still failed, you have a virtually impossible task of explaining (before they even consider giving you a single cent) how you are going to be able to capture market share with your own solution to the 3 player problem.
Nokia and Microsoft only understood this right at the end: to avoid losing in the mobile os market, you need an ecosystem. Miss any of the elements and it all crumbles. Read Elop's memorable Burning Ship note on the final days of Nokia.
> Why are there not yet a plethora of phones on the market that allow anyone to install their OS of choice?
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.
I don't believe that's the true problem. Booting operating system is not a problem. There's no standardized hardware abstraction layer in PC either, every OS brings their own set of drivers.
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.
> My guess is that modern hardware is too complicated for one hacker to write reliable 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.
In the ARM world, there isn't even a standard way to boot, and there are no standard hardware interfaces - except maybe the interrupt controller, since it's part of the CPU and only ARM designs the CPUs.
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.
I worked with ARM boards, I know a bit about it. Booting into Linux is never hard, it's all about using uboot, sometimes with tiny patches on top. I think it's actually even easier with android phones, as you don't have access to the low level bootloader, you just use fastboot stuff.
Having basic framebuffer in BIOS/UEFI is neat for toy OSes, but not very relevant for something practical. You gotta need proper driver for GPU. And if you're just starting, UART console is actually more preferable way to interact with board, IMO.
Booting into a mainline Linux kernel on your average junk-level SBC with all the hardware working (without simply sticking to an Android-like downstream/proprietary BSP) is quite hard, and that's what you need in order to make a phone usable as a daily driver. That's really the root issue; mobile phones are built as embedded devices, with no consideration for running a generic OS kernel. This isn't even an Android issue, OpenMoko was the same deal. If anything, Android was the first mobile platform to even loosely approach any kind of PC-like openness.
If drivers are available and you just need to write DTS to configure the driver, that's not a big issue. I don't think anyone thinks that Raspberry Pi has terrible Linux support, despite lack of UEFI, ACPI and all that stuff. Plenty of Linux distros support it well.
I generally agree, but as a caveat sometimes it's cheaper, more robust and more efficient to build an integrated system without having to worry about interoperability. BYD's electric vehicle chasis for example, seems to greatly cut manufacturing costs, even if it makes swap-in repairs harder down the road.
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.
> So why would a company, in this new environment, invest resources in making their hardware compatible with competing software environments?
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.
Which is another reason we need to strip this hardware attestation stuff out of the hardware. It either needs to use exclusively keys the user loaded into the device themselves or the keys aren't on the device whatsoever and then the "high value targets" verify the contents of the drive from a known-clean machine once they get it back from the adversarial foreign officials before putting it back into service. Or better yet, keep a separate laptop on each side of the border and then sync the data over the internet instead of losing physical control over the device at an adversarial border.
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.
Ok and buys the laptop with malware? How the customs knows that high value target will buy that specific laptop they swapped the ssd? And what they do exactly? Put malware to steal his data?
The only thing proprietary in the early PC architecture was the BIOS. Everything else was pre-existing architecture from third parties, there was nothing to keep a lid on.
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”.
Even the batteries are not interchangeable on phones. You'd think all phones should have the same exact battery, that this kind of standardization is beneficial for phone manufacturers as it helps them bargain with their parts suppliers but no for whatever reason we can't have that.
Edit: I am not saying just user replaceable. I mean standardized so the same cells in a 2024 phone also works on 2025...
The interfaces and the external dimensions can remain the same even as the internals change though, right? And you can have more or fewer cells. The cells don't have to be cylinders, either. They can be flat.
Who will make these custom battery pouches for old phones though? Think my old Poco x3 pro, not the iPhone 17. I am sure there are tons of people willing to make batteries for the iPhone 17 but I feel like the interest wanes as the phone gets older?
For older phones, the batteries we buy are likely also old stock left over if we can find some in stock anyway, right?
> Why was it that in the early PC days, IBM was unable to keep a lid on 'IBM compatible', allowing for the PC interoperability explosion
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.
“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.
Cory Doctorow answers this in his book “The Internet Con”. IBM fought with DoJ for years. Today, it’s a felony to mess with anything locked down (anti circumvention)
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.
The problem is doing it as a company. IBM wasn't defeated by hobbyists building their own PCs. They were defeated by other companies reverse engineering their BIOS and selling their own IBM compatible systems. This isn't possible anymore. It just means you get buried in lawsuits until you go bankrupt.
Well actually, it isn’t for individuals and certain groups, technically.
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)
Yes, I’m familiar with the case. He was caught interfering with equipment on the MIT campus in order to additionally violate TOS of JSTOR, wasn’t he? He shouldn’t have expected to prevail in court, and I’m saddened by his decision to end his own life. That said, he did a whole lot more besides violating TOS, so I’m not sure how applicable his case is to the topic under discussion, strictly speaking.
The systems and software were vastly less complex and powerful in the 8088 days.
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.
Other companies saw that IBM effectively lost control over their platform (and thus lost a large revenue stream), and are determined to not make the same mistake.
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.
Well, back in the day many of the people making buying decisions were tech enthusiasts who like the idea of upgradeability, etc. Computers were quite expensive, and people didn't want to waste money on a box which can only do one thing.
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.
The hardware was evolving way faster 40 years ago and in much consequent ways than these days. Plus number of users grew exponentially. So a company spending too much efforts on software could loose its edge on the hardware side. And locking hardware would be counterproductive since as it would limit new users.
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.
Because the original IBM PC was designed to be cheap and built in a hurry. IBM had a mandate for the original PC to use off the shelf components as much as possible. They also neglected to secure an exclusive license from Microsoft for DOS. 95% of building an IBM PC clone was buying the same parts and getting a DOS license from Microsoft (which they were very happy to sell you). Everyone saw what happened to IBM and just didn't do it that way again.
You can actually look at history and see what happens when IBM tries to wrest control of the PC platform back with the PS/2, which was a flop with consumers because it wasn't backwards compatible enough with IBM's own previous PCs or the wider PC market that developed. A bunch of PC clone manufacturers got together and came up with the EISA bus standard so they wouldn't have to pay IBM license fees for MCA, and made it backwards-compatible with ISA cards people already had. It was successful enough that IBM ended up adopting EISA for some of their PCs.
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.
The company making a device that is licensed by the FCC has to do everything that they can to mitigate the risk of an unlicensed broadcast on their devices.
> 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.
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.
I see people saying things like this all the time and then when I ask them for the specific text requiring them not to e.g. publish source code, nobody has been able to show me.
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.
> The company making a device that is licensed by the FCC has to do everything that they can to mitigate the risk of an unlicensed broadcast on their devices.
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".
> 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.
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?
One comment mentioned Jolla. Another currently available option is [FuriLabs](http://furilabs.com). It runs atop Hallium/etc but you are effectively still able to daily drive a mobile Linux shell and contribute to the ecosystem if you want to see it grow.
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.
Furilabs was just in the news here because they discontinued their device models from a few years ago, and released a new device for a big price bump with _significantly worse_ hardware.
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.
> 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.
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.
It was discussed here when it was announced. I believe it was determined the hardware is an ultra-low-budget Aliexpress design that normally retails for ~$100 that they had custom built with a mic cutoff switch added to it (probably the cause of a large portion of the hardware price increase). I dont remember the specifics, but even thr most optimistic were pretty sure it won't get hardware vendor support for even a full year based on the specific processor it contains.
Replying to myself:
Apparently I was mixing up the new Furilabs FLX1s and new Jolla phone. The FLX1s that's a major downgrade from the prior FLX1 and some people were reporting are based on a design that's really cheap on Aliexpress and using very old hardware but with a custom spin to add some physical switches to it.
The new Jolla actually does look really good compared to all the other avaiaobale Linix phone hardware options.
WARNING: This is a Kickstarter device still, and needed funding to even create a proof of concept device last time it was discussed (extensively). It's a Flagship phone device and price, but with only the oldest of pans on how it's actually going to deliver some on of the promises.
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.
> 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.
Android CTS and VTS are open source so we can and do use those. They're filled with flaky and badly made tests along with enforcing anti-privacy and anti-security design decisions though, so not everything is supposed to pass. Google likes to enforce that OEMs aren't allowed to make certain kinds of privacy and security improvements which could impact app compatibility until Google decides to do it themselves in new major Android versions with new API levels forcing app developers to deal with it.
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.
> AIUI updates are less stringent and burdensome than initial certification
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.
We'll have the same update pace for security updates and major releases with the devices we're working on with our OEM partner. That's not specific to Pixels. It will in fact be easier to support the devices with the OEM partner due to them planning on doing most of the device support work including getting MTE working properly. For Pixels, we have to do a lot of work on device support, while for non-Pixels that work is going to be done for us. Our OEM partner is actively getting what's needed from Qualcomm including getting them to fix things. We're in direct contact with Qualcomm ourselves and plan to deploy new security features they've developed which are not yet available elsewhere.
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.
Hopefully you don't mind me asking this question, but didn't you work with people who managed to do exactly what you are suggesting with a fairly small team at Essential for a few years?
Yep. And GrapheneOS's changes to the kernels of devices they ship are laughably small, 20-30 commits at most. I don't think they even do any basic CVE checks on any of the source code.
Fuzzing, actual security analysis - all those things are done by Google.
Their contributions upstream go way back, I think someone could misread this comment that they've not contributed, and that would be an unfortunate misunderstanding.
GrapheneOS has made substantial upstream contributions to the Linux kernel and Pixel drivers including vulnerability reports. Many of our kernel changes are for the out-of-tree drivers needed for Pixels which are in a separate repository from the Generic Kernel Image code from the upstream Linux kernel. We make important downstream changes including enabling many more of the upstream security features and adding important protections not yet available there. We worked with multiple upstream Linux kernel developers to get many of the changes we used to have upstream and therefore no longer need them. We have major kernel security improvements in development including more security-focused integration of hardware memory tagging, but indefinitely maintaining those downstream is not the way we try to do things.
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.
It doesn't seem to be the entire project, just one dev (afaik) that's quite outspoken and does make accusations that they don't always seem to back with evidence. Also insofar as the actual "product" remains completely untouched by any spats it shouldn't be a dealbreaker for anyone wanting to use GOS, but of course it isn't ideal to have any drama attached.
Alright, didn't mean to make any libelous claims, it's just so it happens I never saw any evidence from your accusations. I already know these people are the worst, but it would be helpful if in any of your posts you would share some evidence like you did right now.
Where's the evidence for the accusations being made towards me? No need to answer: fabrications and spin on Kiwi Farms and 2 Kiwi Farms adjacent videos on YouTube, which are regularly referenced and directly linked to by people involved with multiple companies and open source projects in the space. Here's a very recent example of the founder of /e/ and Murena once again linking to libelous harassment/bullying content, this time on a blatant neo-nazi conspiracy site:
He's done this many times before and has directly spread Kiwi Farms harassment content himself from his personal accounts along with using the /e/ and Murena accounts for similar attacks. We never picked any fight with /e/ or Murena, they spent years spreading misinformation about GrapheneOS to mislead people into buying highly insecure products and services. They're enraged by us countering that misinformation as we did here with verifiable, accurate information with third party sources you should read too from Divested Computing, Mike Kuketz, their own forum (sending sensitive data to OpenAI without consent and falsely claiming it's anonymized when questioned) and elsewhere:
What is it you think hasn't been adequately proven?
Our chat rooms, forum, etc. are being endlessly raided with CSAM, gore and harassment towards our team. Our team is being swatted and threatened on a regular basis. We're having endless libel and bullying directed towards us including these baseless claims that we're insane. What the people attacking us can point to is that they think our replies debunking it and defending ourselves are too verbose which somehow makes us insane and delusional. Us banning people from the Techlore and /e/ communities raiding our rooms pretending to be users initially then attacking our team with harassment or posting CSAM is somehow us being toxic rather than those communities being toxic. It's not them being targeted with harassment. It's not them having fabricated stories spread about them.
It's you folks making accusations without evidence which simply reference a bunch of harassment content proving what we're saying is true. Linking to that harassment content proves people are doing it since most people can see it for what it is: a bunch of poorly made lies and misrepresentations to target someone with harassment.
You're making libelous claims without evidence while falsely claiming that I'm doing it. This typically goes along with baseless claims that I'm insane, delusional, schizophrenic, etc. with links to extraordinarily dishonest content filled with obvious fabrications from a couple serial harassers. One of those serial harassers has an identity verified Kiwi Farms account and was the one who involved them in targeting me (kiwifarms . st/members/larossmann.132201/). We've provided a large amount of evidence. Here's the leader of Murena and /e/ linking to libelous harassment content towards me on a conspiracy site this week: https://archive.is/SWXPJ + https://archive.is/n4yTO and we have dozens more examples archived for him specifically. You target us with libelous claims, bullying and harassment then claim we're creating drama for defending ourselves from it and documenting it. If you want the 'drama' to stop then stop engaging in harassment.
Don't know if you're replying to a wrong person but my point in the comment was about many of the tweets that get passed around include claims without links to any evidence. The recent tweets I've just seen from the top of my head were in relation to accusations of /e/os and Iode having government ties, but no evidence for that was linked in the tweets. A common person isn't going to go digging where that evidence has been presented if it isn't very clearly available, if at all. It may have a hassle to include it to every tweek, but the impression stands. Also never contested any of the harassment you have received.
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:
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.
> 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.
People in that thread mention a GrapheneOS project member together with the worst of bigotry, slurs and death wishes. And Rossman just decides to keep replying and talking in that thread. Like its worth engaging with these people and they deserve attention.
He didn't say anything about Gos devs in there, yet they say he did. It's just not true. Do you have a Facebook account? Facebook is full of scams, are you also a scammer? Probably.
He engaged / replied to the people that were talking about both a GrapheneOS dev and an Asahi Linux dev.
Imagine the following: People in a thread made about you start posting death wishes about people you have conflicts with, make bigotted comments about them and on top of that are in general being ableist and hateful towards multiple societal groups (things akin to "I wouldnt trust the GOS dev just like I wouldnt trust a <insert horrible slur agains trans people even though completely unrelated>").
Would you think it makes sense having a friendly chat with these people, as if they are worthy conversation partners? Shouldnt they either be ignored or judged?
Do you research everybody you engage with? Are you a fed?
He went there to refute some claims about himself, like a man, instead of crying behind organization brand on social media.
And stop moving the goal post. Now it's guilt by association, what's next?
He replied to the problematic bigotted messages of those people. Im not saying he talked to people that were acting problematic in other posts/threads. He engaged with problematic people saying problematic things as if they were totally fine unproblematic people worth engaging with in a friendly manner.
That's the most delusional thing I've read all month. Sometimes you must deal with problematic people. Ever heard of Daryl Davis? Be like him 1% and world will be a better place. Don't be like a reddit moderator.
That is also my feeling, at least from a part of the GrapheneOS community. I have seen them despising and bullying /e/OS, Debian, F-Droid, the Linux kernel... Too bad for this project, that is amazing, to have such toxic folks.
Open source communities should help each other, and work together, not fight.
You can't equate actions from a part of the community with actions by the project. If you would see any bigotry by a GrapheneOS community member, please report it to the moderators. Bullying, toxcity and misinfo are not allowed. Action will be taken.
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.
“The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.”
Being on the receiving end of valid, technical criticism in response to making misleading claims about GrapheneOS for falsely marketing products is their own choice. It's certainly a lot nicer than being on the GrapheneOS team heavily targeted by libel, bullying and harassment from those groups. Here's a recent example of the founder of /e/ and Murena linking to libelous harassment content on a conspiracy site, which links to a Kiwi Farms style character assassination video from someone friends with neo-nazis:
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.
The attacks on GrapheneOS from Copperhead and their supporters including within other projects were not a fight we picked. You're pushing a false narrative in support of years of libel, bullying and harassment towards us. Your project's team has regularly engaged in very underhanded attacks on ours despite us never doing anything to you. We have archives of it.
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):
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/).
GrapheneOS did not attack you or your project. The same goes for the people you're supporting who chose to attack us for years and then feigned being victims when we finally began defending ourselves. We'll defend ourselves from the libel from your project too. You're choosing to make manipulative attacks on it without an actual basis to try to pile on the existing ones, while feigning ignorance of all of that. The chat logs show you aren't actually ignorant of it.
You came to this thread to promote an inaccurate narrative in support of the absolutely vile attacks on us. Meanwhile, we've never done anything to you or your project beyond promoting it as one of the available options. We stopped doing that a while ago due to attacks from yourself and other project members. We haven't responded to those attacks beyond not mentioning your project anymore and removing our many past links to it.
We have chat logs archives of your rooms which can be used to prove ongoing attacks by your project members towards GrapheneOS and our team. That includes voicing support for harassment content. Is it as severe as what we can show for many others? No, but it's enough. I'm not confusing you with someone else. I'm aware of who you are and what yourself and others you work with have said over the years.
You regularly attack the GrapheneOS project and our team in your chat rooms including supporting libelous claims about us, as do others who work with you.
You can tell it's truly secure and private because the Cellebrite leak says they can't break it (one of very few!) and some governments assume you're a drug dealer if you use it. My next phone will run GrapheneOS.
Marketing is known to lede a lot of bullshit. Celebrite saying "We tried our stuff and it didn't work" is very likely more about obscurity than focused effort. Unless you know that celebrite has been specifically hired to break into a GrapheneOS device and put as much effort into it as they do into standard Android and iOS and failed, it means nothing. It's like the old thing about MacOS 9 being more secure than Windows.
I don't see anything written there that says Apple has a current capability to "access any phone" which I am assuming to mean personal info like SMS message contents... just a whole lot of reasoning why they haven't had that capability in years.
They are literally in PRISM you fucking idiot. But hey, go ahead. Be ignorant, believe what they say and their marketing team which has been deceiving normies since forever
Great, so this means that the only way to get an Android release that's up-to-date on security patches is a binary-only distro - either Google Pixel, or the GrapheneOS preview channel.
Just wonderful. Google should know better than this, shame on the other OEMs that forced this mess.
If it's any consolation, preview builds are reproducible at the point that the embargo ends. A bit better than the definition of binary that we're used to.
GrapheneOS goes even further by allowing you to opt in to pre-embargo security releases, bypassing the vulnerable window between vendor disclosure and OEM patches. Awesome!
So this is interesting, they release the patched binaries several months before anyone else does and several months before the source code of the patches is released?
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.
I absolutely loved my Moto X with the walnut back. I switched to an iPhone when it stopped getting security patches.
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?
They have partnership an OEM who provides them with sources.
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.
> It's quite surreal how unsafe the standard Android
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.
If I don't misunderstand you, you're suggesting the Pixel 8 line is shown red/discontinued? If that's it, you're probably on a mobile browser which might cut off right after the Discontinued column. The table goes on next to that where you'll see that all Pixels since 6 are currently still supported.
You misunderstood. He’s saying that Google provides 7 years of device updates only for the Pixel 8 and later. That’s true: Pixel 6 and Pixel 7 only get 5 years of updates.
If you have a Pixel -> Graphene, if not -> Lineage.
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.
Don't understand your statement about avoiding client-side scanning of text messages. I've always assumed it would be done by the apps themselves, e.g. WhatsApp, Telegram, etc..
That sounds amazing. I aspire to get a setup like yours. I am on a Pixel with the stock OS and I can't stand the way Google is pushing AI into everything on my phone.
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.
This depends what you mean by 'issues with NFC'. My understanding is that Google require an OS that is blessed by them for contactless payments in Google Wallet to work. That restriction applies to all alternative operating systems that aren't Google certified stock Android.
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.
I doubt contactless payments will ever work on Graphene. In any case, I don't find carrying a credit card particularly inconvenient. I prefer cash for small transactions too; it's the only means of payment that is truly anonymous.
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.
This is the correct response. I use both GrapheneOS and LineageOS. But LineageOS focus is on delivering newer versions of Android to many phones abandoned by their OEM. GOS exclusively focuses on security and privacy. If you want a reasonably secure phone but don't want Google or Apple inside your device, your best bet is GOS.
How can LOS's security be somewhat close to GOS if it's worse than OEM? LOS lacks verified boot, hardware security features, it's often behind is security patches.. With "advanced protection" enabled stock OEMs are even more secure, but GOS is even more secure still. When it comes to EOL devices, LOS may be more secure than OEM depending on your threat model.
It very much depends on your personal threat model, if you expect targeted attacks LOS doesn't hold a candle to GOS, but at least for my threat model verified boot and hardware security features outside of my control don't have a substantial security benefit.
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.
They can because they essentially support Google chipsets, which are not blobby like MediaTek or Qualcomm because Google for all its faults is still relatively open (except their recent change in release schedules is why the Pixel 10 series still only has experimental GrapheneOS support).
Yes, even Apple with its practically infinite resources took 14 years from when it acquired Infineon's mobile chipset unit to launching its C1 modem. So much of the telcos' allegedly open protocols are actually implementation-dependent that it takes a lot of testing on actual mobile networks to validate interop.
No, but they used to publish the source code for the drivers as part of AOSP. Now they no longer publish the device trees. Check out GrapheneOS' other Mastodon posts for the gory details.
Nice! Thanks for the link. I noticed they didn't mention MOCOR OS (for the new Nokia 3210), but then I remembered that that's not an Android version. I'll see if they can add it somewhere else.
Unrelated, but this led me to find gnuclad, which may be somewhat externally maintained and is used to create the cladogragms.
It might be important to mention, that Lineage OS is available on a number of the devices abandoned by their original vendors, so sometimes it may be a much better solution to get a Lineage OS onto their former "flagship" which stopped getting updates 18 months after the release.
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.
GrapheneOS is a locked-down, security-hardened system that's good if you need absolutely maximal security (e.g. journalists, activists, folks targeted by state actors). LineageOS is a more of an open system for tinkerers who want to play outside Google's walled garden.
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
Not having root prevents me from taking proper backups that include app data, it prevents me from using Aegis to import TOTP codes from Authy. I get that on some abstract level it is more "secure" from any malicious software that might find its way onto the device, but the practical upshot is largely obstructing the user from using the system.
Have you ever had to work on a locked-down machine at an office? I don't need Google or Graphene to play IT department for me.
As I'm sure you're aware, SeedVault won't backup app data if the app authors have opted out of it. Again, this is an example of a system serving masters other than the device's owner.
It's not really locked down. You can toggle or enable some of the more activist-orientated features. The only limitation I'm aware of is that some apps requiring the strongest Play Integrity setting (ChatGPT, some banks, very few airline apps) just won't work on GrapheneOS.
Graphene OS provides advanced security capabilities and a thorough defense-in-depth approach including a hardened supply chain. GOS aims to provide mechanisms to protect against 0day attacks. For example Celebrite can not open up GOS. GOS relys on hardware support provided by Pixels. Graphene OS works on getting their developments upstream.
Yes, but keep in mind individual apps like Signal need to run in the background at all times if you want to receive timely notifications on Graphene, because they cannot rely on the Google backend for that. If you have enough such apps, you may well find that battery life is shorter than on the stock OS.
Good point, I chose not to on my main "Owner" profile to be fully Google-free. I have the sandboxed Play Services on a separate profile I hardly ever use for testing purposes.
GrapheneOS doesn't have any proprietary kernel drivers. There aren't any for the supported devices. Firmware and a subset of userspace driver libraries such as the Mali GPU driver library are what's proprietary.
Graphene has really caught my eye in the last several months, but unfortunately I couldn't find a good deal for Pixel phones (>128GB storage), used or new. That's the biggest bottleneck for adoption it seems. I just finally switched from an S10E to a S25Ultra (black friday deal brought down to $820), but not being able to use Graphene in the future hurts a bit for sure.
>Graphene has really caught my eye in the last several months, but unfortunately I couldn't find a good deal for Pixel phones (>128GB storage), used or new. [...] I just finally switched from an S10E to a S25Ultra (black friday deal brought down to $820),
One caveat--you have to be certain that you get a Pixel with an unlocked bootloader. There are a lot of Pixels (mostly sold by Verizon) that are unlocked for use with any carrier, but whose bootloaders remain locked. If you have one of these ex-Verizon phones, there is no way as of now to unlock the bootloader.
There's no way to easily tell that those phones have unlocked bootloaders, though. Ex-Verizon phones may be completely carrier unlocked, will work on any network, and still have locked bootloaders. This isn't an issue for anyone running stock Android, but will restrict those phones from being used to run GrapheneOS.
That would become a meaningless effort security wise as time goes on. The drivers and firmware will become outdated. OS updates are necessary but not sufficient. I get the e-waste / enviromental argument, and I think its very warranted to criticize OEMs for not providing long support times in the past. Apple and Google do this well in recent years, luckily.
The OS is not very relevant to the Pixel. Compare the Pixels you like that are new (GrapheneOS drops support as models become older flagships, I think for security reasons) and get that one. IIRC, currently only Pixel is allowed, because the bootloader can be opened without rooting the device.
Given what they choose to ship with their phones in some regions, id say that Samsung absolutely doesn't care about the security of their customers of they can get away with it.
> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.
> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
Apparently I'm a downvote bot, a honeypot and member of a mob. My life is much more exciting than I realized!
Your repeated unsubstantiated claims about GrapheneOS just don't ring true with my experience as a user across multiple devices for years. It is an excellent AOSP fork, and has numerous security and privacy enhancements. Every time I've asked you to explain your position, you fall back on, "do your own research." I've done plenty and it's why I switched to GrapheneOS and remain on it.
LineageOS is great for its purpose: supporting a long tail of legacy devices. But as a result it is less secure than stock AOSP. Switching a recent Pixel from GrapheneOS to LineageOS is a baffling proposal for all but the tiniest of edge cases.
It's inaccurate that GrapheneOS fully endorses Signal and Tor. The GrapheneOS founder was blocked by Moxie (when they were still leading the project) for criticising their approach. They have also warned countless times about the limitations and weaknesses of Tor.
It supports devices just as long as the OEM does, which for modern Pixels is now 7 years, which is more than what Apple advertises for the iPhone. Considering people upgrade phones every 2 or 3 years, this is over double the amount of time of support than one would use the phone for. I disagree the support is for a short period of time.
An important motivation for a FOSS OS for phones is not having to buy a new phone just to have up-to-date software.
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.
Reducing waste is very important, but I think this is something you need to take up with the Android OEMs. GrapheneOS can't really do anything about the fact that Android OEMs stop supporting the device and allow vulnerabilities to go unaddressed. For context in this situation, GrapheneOS is also trying to provide a best-in-class privacy/security experience for people. There were other projects that are/were dedicated to supporting abandoned hardware.
A connected world full of devices with excessively vulnerable hardware & software is also something GrapheneOS are desperate to avoid.
I don't think that is a consideration for the project. Their OEM partnership also includes supporting a current generation Snapdragon SoC which seems to feature an integrated modem.
>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.
https://tbot.substack.com/p/grapheneos-new-oem-partnership
> 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.
Oh that's one of the best news in the smartphone world in a long time.
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
I have been trying to come off of google and cloud by building — quite slowly — my own nas server which has 2 nodes in two geographic regions where I am building certain services like cloud storage and backup, webhosting etc. But I think there are a few key things that need to be community driven to really get rid of this duoply.
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].
[1]https://beacondb.net/
[2] https://github.com/wiglenet/m8b
[3] https://insidegnss.com/end-game-for-urban-gnss-googles-use-o...
I don't understand your syntax:
Does this mean a server where third parties can send code to run on your data, but cannot respond to them?It means any 3rd party even the app provider cannot read your data or the output of the function run. They can provide some data/resources like say map tiles, PoI data and a function to run.
They mean 3rd parties have wo permission instead of rwo to your data store
I'm not knowledgeable enough -- what would it take to escape the Apple/Google duopoly?
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?
There are some good stuff on the software side that people mention, but a big one is the driver support. We would need device makers to upstream support so there is less worrying about reverse engineering or needing to run modified ROMs based on old builds. Or just publish specs on the hardware that is enough for implementation. Sure, you can buy a specific phone and run a de-googled android or linux, but that only really works for the hobbyist who wants to spend time doing this. Which makes it difficult to create a market that encourages developers of software to port their software or write new software. With out being able to broadly support devices, most people are gonna be better off running Google's android.
Halium [1] technically handles that right now.
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.
[1] https://halium.org
Any one of us here could learn the skills to design a smartphone. It won't necessarily be good, but I remember that years ago, someone made one with a touchscreen hat and GSM hat atop a Raspberry Pi, rubber-banded to a power bank. I'm sure any one of us HN users could do this. And it worked. Quality only goes up from there.
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.
This is not as simple as you're saying. Making a new phone not relying on proprietary drivers tied to Android is impossible without a huge effort: https://news.ycombinator.com/item?id=21656355
Obviously you'd only choose hardware that works the way you want it to.
Hardware relying on free drivers is almost non-existent in the mobile world. There is nothing to choose from, obviously.
Then aim for freely distributable drivers. You can share copies of Raspbian, so it seems possible.
You mean the Linux distro that exists because it needs to contain broadcom drivers/blobs/etc that are under NDA?
Then your hardware will turn into e-waste as soon as the vendor decides so and stops updating the drivers.
Or use everything via the web browser; but yes, I think apps are the main reason we can't just have a generic Linux phone OS on an open hardware platform
Apps make or break operating systems and app stores. Just ask Microsoft (Windows Phone) or Huawei (HarmonyOs). IIRC amazon was paying devs to publish to their app store or something like that.
Thankfully, some apps have both web and native mobile versions but for a modern digital life, the critical apps are sadly not on both versions.
We have generic Linux phone OSes: Mobian, PureOS, postmarketOS and more. They can even work as daily drivers on some phones.
Isn't there an emulator that can run Android apps inside any Linux distro?
No. There are a few that claim to, but none of them are actually any good. Waydroid, for instance, requires that your kernel is compiled in basically "Android mode" (e.g. binder enabled).
How do the Android developer tools run Android apps on Linux then?
Inside a virtual machine which is easy to detect.
> Waydroid, for instance, requires that your kernel is compiled in basically "Android mode" (e.g. binder enabled).
Waydroid needs you to have a single kernel module, which is in mainline Linux and just happens to be disabled in many desktop builds. That hardly makes it an "Android mode" kernel, and I certainly see no reason why it should make the system no good.
We can have it. It won't become as popular, but we can have it.
> Any one of us here could learn the skills to design a smartphone.
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)
[1] https://github.com/lenovo/lenovo-wwan-unlock
or you could slap a GSM shield on a Raspberry Pi.
As I wrote: 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.
Then you can copy the relevant parts of the designs from both boards onto one smaller board.
Good luck getting that to perform. Or even boot. High-speed buses are the darkest of the dark arts to design, at the kind of frequencies particularly PCIe runs even the slightest trace length mismatch, impedance issue with the PCB itself, vias, or even external RF sources can, do and will mess with your sanity.
That's my entire point. It's not easy to design a complex thing such as a smartphone.
[dead]
> I'm not knowledgeable enough -- what would it take to escape the Apple/Google duopoly?
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.
> 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.
Yep, otherwise, VM is effectively one of the better ( and maybe even safer ) way of trying to escape the established ecosystem.
Isn't this spoofable with root access?
The private key used for attestation is stored in the secure element hardware, which runs its own OS, completely inaccessible to the main hardware's OS, even with root.
Some apps don't actually check the attestation signatures, so they could be spoofed for now, but if spoofing became common, apps would just get strict about checking attestation.
Parts of it are, parts of it aren't. Some of it is based on hardware attestation.
Why not run Android directly, such as using Graphene OS. It's decades ahead in both OS architecture, developer tools, and developers compared to non Android based Linux operating systems.
Graphene uses the Google codebase, so Google is choosing its long-term development strategy and standards it will support. It's like choosing Chromium to escape Chrome.
Not the worst choices!
Indeed. However, in terms of the independence, better choices exist.
If someone is making a new browser, considering you want to support the same web standards as everyone else, being independent is pretty low on the priority lists. In fact it is more of a liability since it could make for compatibility issues.
I don't understand what you're talking about. Firefox supports all reasonable standards and so does GNU/Linux.
The same can be said about the Linux codebase. Tomorrow Linus could private his branch and stop supporting public releases. If AOSP goes closed source then people can fork it and continue to maintain it.
The Linux kernel cannot be relicensed. Linus does not hold copyright to most code.
Linus is not known for decisions hostile to the users. Google is.
Linux doesn’t really rely on Linus for coding anymore…
It does on Intel, AMD and a bunch of other huge corps though
Which is not the same as one single, hostile corp.
I do agree that each company's influence in case of the kernel is much lower, than Google's relevance in Android, but there are other big-ish players in the space as well, like Samsung.
Graphene OS exists because Google lets it. You can't rely on competitors that can only exist in this manner
Similar to how Valve is managing the transition from Windows to Linux.
it'd be cool if they made Steam Phone.. it could be to Steam Deck as iPhone was to iPod Touch.
Well if you rely on running Android apps, you still rely on Android.
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.
> I think the easiest way to do that would be to run Android in a VM.
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.
You can go the waydroid style with namespacing, or native containers if using the linux kernel. No need to do a full vm
You could, but using containers requires that your kernel directly provide and secure Android-compatible functionality, such as binder. A VM gives you more options for abstracting that functionality.
If you expect to be "essentially android, but a little different", containers make sense. If you want to build an entirely different mobile OS, but provide Android compatibility, I think a VM is much more likely to give you the flexibility to not defer to Android design decisions.
Has no one mentioned not using a smartphone as an option?
How do you run WhatsApp or Signal without a smartphone? Pretty hard.
If your answer is "don't use them", then you're not living in a country where the vast majority of communications are done on WhatsApp or Signal, good for you I guess.
Yes that's fair. I have a an old iPhone without a sim that I use as my master for those apps, but I keep it in a drawer since the desktop apps work fine. Funny enough the phone the app is installed on doesn't have to be the same phone you use to register by number, so the number I registered with is my flip phone
Access to Signal and Bitwarden are the only two apps I really need daily that keep me on a smartphone. I have tried using a feature phone in the last couple years, but honestly I might as well just not have a phone at that point as almost all my communication is via Signal.
> then you're not living in a country where the vast majority of communications are done on WhatsApp or Signal
I live in the USA and use Signal for, like, 3 friends that I also can call or text, and I've never used WhatsApp in my life.
So, if you live in the USA, you can absolutely get by without those two.
But there are likely other apps that would be more difficult to do without. Not impossible, mind you, just more effort.
I tell you that if you live in a country where most communications happen on WhatsApp or Signal, then it's difficult not to use WhatsApp or Signal.
And your answer is to give me an example of a country that is irrelevant to my point? How does that help?
Signal can be used without a phone using signal-cli. You can sign up with it and either attach your account to signal-desktop or keep using signal-cli
"You don't need a smartphone, you can just carry a laptop with you" :-)
You don't have to be available on instant messaging 24/7.
It is a convenience or inconvenience you decides to have or not.
"You don't need to connect to the Internet at all".
How is that an answer to someone saying that they don't see how they can stay connected without having a smartphone?
Well honestly that's part of the flip phone lifestyle, if someone doesn't want to call me, that's fine, they can send me an email. We don't have to bring Google or Apple into this relationship, it's a choice people make because the prefer texting and being available to everyone they ever met 24/7
> We don't have to bring Google or Apple into this relationship, it's a choice people make because the prefer texting and being available to everyone they ever met 24/7
You're changing the discussion now.
The original point is this: Given that people want to be able to text with their friends in what is perceived as a normal way, how can they do it without a smartphone?
If you change the rules ("Given that people are fine being disconnected"), of course it changes everything.
I don't think that 24/7 availability is universally perceived as "a normal way". A large number of my contacts will answer several days after a message. In my experience it is usually only inside the nuclear family that people expect answer within 2 hours and these are the kind of people who can always choose to call instead of text if they know their child/sibling/parent is not usually text available.
I don't know how many time I would have to repeat it, so I'll do it one last time.
The beginning was:
> what would it take to escape the Apple/Google duopoly?
To which someone answered:
> Has no one mentioned not using a smartphone as an option?
To which I answered that in a ton of situations this is just not an option.
And yet I keep getting answers that give examples of when it is an option. Sure, sometimes it is an option. Now for the majority of normal people who don't consider "not having a smartphone" as an option, I was saying that it is very, very hard to escape Apple/Google.
I am NOT saying that most people would die on the stop if they suddenly did not have access to a smartphone. I am saying that there is no solution to that that most people would consider viable.
> I don't think that 24/7 availability is universally perceived as "a normal way".
I never said 24/7 availability. I said "not having access to WhatsApp/Signal [in one's pocket, some of the time]". The part in brackets was implicit because we were talking about smartphone operating systems.
Doesn't really make sense in a conversation about security (the HN post was referencing security).
Traditional desktop OSes (Windows, MacOS, traditional Linux distros) are just at an entirely different level than modern mobile OSes (Android OSes, iOS) and ChromeOS. They also often run on less secure hardware, especially compared to a Pixel.
It's not really an option. Beside various communication tools, many many banks require you to have a smartphone as their 2FA option.
They don't publicize it because they'd rather sell all the data they don't have already through your payments and bank movements but many still send you a dedicated device if you mention you don't have a smartphone.
You can escape the duopoly by using a GNI/Linux phone, Librem 5 or Pinephone, but don't expect any support from Google or Apple for them. I'm using the former as a daily driver.
I would not trust any of these. They are a security disaster, lacking even basic features for securing your device against tampering and hacking.
There is a reason GrapheneOS is number one and a reason why they only run on Pixels (for now).
> security disaster, lacking even basic features for securing your device against tampering and hacking
Indeed the GrapheneOS community is known for attacking the GNU/Linux mobile with false claims, https://news.ycombinator.com/item?id=45562484.
Security is a meaningless word without defining a threat model. Try to defend your GrapheneOS against Google, especially these two problems: https://news.ycombinator.com/item?id=45208925 and https://news.ycombinator.com/item?id=45017028.
See also good replies by other people here comparing GOS with Pinephone: https://news.ycombinator.com/item?id=32496220
GrapheneOS doesnt really proactively attack GNU/Linux. What happens is that there are posts on the internet about GrapheneOS or mentioning GrapheneOS in which or under which completely wrong comparisons between GrapheneOS and GNU/Linux get posted. It makes sense that you care to clarify or correct if you spot people are talking about your project and are (intentionally or unintentionally) spreading wrong information about it by making comparisons based on misconceptions or falsehoods.
The thing you link about restricting network traffic doesnt make much sense. GrapheneOS has a proper network permission which other OSes dont have. The outbound traffic restrictions to certain destinations which are being referred to are just a bad approach. You can send the traffic to one server and just process it there and send out to other servers.
You also say :
> Also, if I explicitly don't trust Google with anything, GOS is extraordinarily insecure for me until a new vendor
If thats the case, dont opt for GNU/Linux either given the large code contributions made by Google. Also avoid any software built with LLVM, written in Go, written in Flutter, using Angular, ...
The two "problems" you link arent really huge security issues. How is GrapheneOS having access to the embargoed patches and being able to ship them a security issue? Also the planned sideloading restrictions dont even apply to GrapheneOS. It would only apply to certified OS that license Google Mobile Services. Also, that isnt even a security issue. Its a freedom issue.
> completely wrong comparisons between GrapheneOS and GNU/Linux get posted
Can you be more specific here? I don't see anything like that in my links.
> dont opt for GNU/Linux either given the large code contributions made by Google
You're trolling again, with no reasonable arguments. You can find a reply here: https://news.ycombinator.com/item?id=46176660
> How is GrapheneOS having access to the embargoed patches and being able to ship them a security issue?
This is not the actual issue. The actual issue is that existing patches for a known vulnerability become unavailable, because Google decided so, making GOS potentially insecure. Patches without the source code shouldn't be trusted.
> It would only apply to certified OS that license Google Mobile Services.
Until Google alters the deal.
> Also, that isnt even a security issue. Its a freedom issue.
There is no security without freedom. If you're protected by a steel door, but you don't have the key, you aren't safe: You're imprisoned. You can't protect yourself from Google without having freedom to run what you want on "your" device.
> Can you be more specific here? I don't see anything like that in my links.
You made a general statement about attacks from GOS on GNU/Linux. I replied that this happens in the context of wrong comparisons being made.
> You're trolling again, with no reasonable arguments. You can find a reply here: https://news.ycombinator.com/item?id=46176660
Im not trolling. You say you dont trust Google at all. Thats your position. Then my argument is to not trust their code, regardless of which project its submitted to. How is that unreasonable. Your argument is the unreasonable one. You somehow think contributions by other companies to Linux would balance out or erase your trust issues with the Google code? Why would that make any difference.
> This is not the actual issue. The actual issue is that existing patches for a known vulnerability become unavailable, because Google decided so, making GOS potentially insecure. Patches without the source code shouldn't be trusted.
The issue gets patched. Whether the code is published doesnt change the code... People can also sti reverse engineer the code. Its not a black box. Its often just Java code. You can easily decompile Java, bytecode maps easily to the source code. Its an effort you have to do, yes, but so is reading and properly auditing the source code as well. You seem to think publishing the code somehow magically makes it more secure. While that isnt true. People would still need to properly audit it. It barely happens in practice. And it can also perfectly be done with compiled code.
> Until Google alters the deal
If Google were to put the restriction in AOSP, GOS can simply remove it from the code... And if its not in AOSP than it doesnt impact GOS.
> There is no security without freedom. If you're protected by a steel door, but you don't have the key, you aren't safe: You're imprisoned. You can't protect yourself from Google without having freedom to run what you want on "your" device.
This metaphor doenst make any sense in relation to the planned sideloading restrictions. I suggest reading the blogposts from Google about what the process will look like.
> You made a general statement about attacks from GOS on GNU/Linux.
No, I provided two specific examples, one quoted and another linked to. None of them happend in the context of wrong comparisons being made.
> You say you dont trust Google at all. Thats your position. Then my argument is to not trust their code, regardless of which project its submitted to. How is that unreasonable.
Your argument is completely unreasonable. Google has full control over Android and therefore GrapheneOS. It has very little control over Linux. All their contributions to Linux are carefully verified by many independent parties and suspicious things not accepted by community are rejected. The latter doesn't happen in Android, see my examples above.
> The issue gets patched. Whether the code is published doesnt change the code...
Only if you 100% trust Google. I see you do and promote them. I wonder why you would defend a trillion-dollar, monoppolistic megacorp hostile to its users.
> People can also sti reverse engineer the code.
This takes huge effort and time. One can't rely on it to be secure.
> If Google were to put the restriction in AOSP, GOS can simply remove it from the code...
The effort to keep a hard Android fork up-to-date will grow exponentially. I don't expect that GOS team will manage to do it for long.
> This metaphor doenst make any sense in relation to the planned sideloading restrictions.
This is exactly what is happening with Android right now. Users are constantly loosing their control over the device in the name of the false sense of security.
> I suggest reading the blogposts from Google about what the process will look like.
This is not even funny. Are you working at Google? I suggest you to read blog posts by a non-profit instead: https://eff.org.
> No, I provided two specific examples, one quoted and another linked to. None of them happend in the context of wrong comparisons being made.
You made a general statement here ("being known for"). You put a link there indeed with a quoted example and another link.
You have to look at the parent replies of what you link. Read the thead properly, please. Like I said , "What happens is that there are posts on the internet about GrapheneOS or mentioning GrapheneOS in which or under which completely wrong comparisons between GrapheneOS and GNU/Linux get posted". Replies that were literally mentioning GrapheneOS got a reaction. Thats not an unfounded attack. The statements that those other options are less secure are clearly backed up with technical information.> All their contributions to Linux are carefully verified by many independent parties and suspicious things not accepted by community are rejected. The latter doesn't happen in Android, see my examples above.
That's really not how it works in practice. There is a ridiculius amoumt of code and code changes. Systematic proper exhaustive auditing doesnt happen. Also, you distrust Google and think they are malicious. Google can do their best to hide bad stuff in their code so quick reviews wont notice it. Do you think malware developers write functions called doTheBadStuff()?
> I see you do and promote them. I wonder why you would defend a trillion-dollar, monoppolistic megacorp hostile to its users.
I am not promoting Google. I am just countering your posts critizing Google using bad arguments. Google is a multi-faceted compamy some of the things they do are good for end users, some aren't, most things will be liked by some and disliked by others.
> This takes huge effort and time. One can't rely on it to be secure.
Reading and properly understanding source code also takes huge effort and time. And like I said, if you dont trust the devs, you cant trust function names, variables names and code comments to give a faithful portrayal of functionality anyway. So do you really lose that much if you decompile Java bytecode and mainly just miss naming and comments? It can even be argued it will remove preconceptions and let you read the code with a more open mind. Its a hurdle and annoying for sure, though. I would prefer Google to lower the embargo as well. But, public source availability just isnt the magic silver bullet you think it is.
> The effort to keep a hard Android fork up-to-date will grow exponentially. I don't expect that GOS team will manage to do it for long.
You dont need a hard fork for that. If the sideload restriction were to be put in AOSP you can remove that in a soft fork.
> This is exactly what is happening with Android right now. Users are constantly loosing their control over the device in the name of the false sense of security.
I agree Googles plans arent a good approach. But it isnt a false sense of security either. Registering app IDs and associated public keys is a usefil thing. There are other, begger approaches though, tbat dont have the downsides of what they planned.
> This is not even funny. Are you working at Google? I suggest you to read blog posts by a non-profit instead: https://eff.org.
Based on what you were saying and your bad metaphor it is just clear you arent accurately informed or up to date about what the sideloading restrictions will be. The best place to read what the procedures will be is in Google's blog posts and documentation. I am not saying you have to go read that to make a value judgement on the merits. You just need to read that to understand what is actually being talked about. I dont like Google's plans either but I am aware of what they are.
Something being a non-profit doenst automatically mean all posts they write are of good quality. EFF does many good things but I dont see why their posts about things are somehow automatically good and authoritative because of their non-profit model. Best to judge individual posts on their merit.
Depends on your threat model, but yes.
GOS fits into pretty much any threat model where you remotely care about privacy or security
No, it doesn't. It obeys Google's long-term development strategy for the OS. Google and privacy are absolutely incompatible. See: https://news.ycombinator.com/item?id=29502439
Google has implemented lots of privacy and security features in AOSP over time. The app sandbox and permission model has evolved a lot, in a good direction. The codebase is also modernized with the increasing adoption of memory safe code. At least Google seemes to have a thought out development strategy to enhance security and privacy, contrary to the projects you mentioned elsewhere in this Hacker News thread.
Also, what you link doesnt prove what you think it does. Manifest V3 is a very good thing for privacy and security. It restricts and controls the access of extensions much more. With MV2 you have much less control over your data.
Every reasonable, independent organization confirms that Manifest V3 is the end of privacy for Chrom(ium) users, e.g.,
https://news.ycombinator.com/item?id=29502439
https://news.ycombinator.com/item?id=41871873
https://news.ycombinator.com/item?id=44543660
> It restricts and controls the access of extensions much more.
You mean, it restricts users even more and gives to websites the freedom to track you? I won't engage in further discussion with you, you're just trolling.
You link three things, that doesnt equate to "every independent organization". One of your links is a post by Brave and Brave isnt independent in this. The unsubstantiated fear of people for MV3 is beneficial for them, it could grow their userbase because they keep the support for MV2.
Content blocking (ad and "tracker" blocking) are convenience features, they dont foundationally improve security. Defining what a tracker is is difficult and you cant list them exhaustively. Also smart businesses and organisations can just shift to sending all data to the main domain and handling it server side to send it onwards to other domains, including third-party domains. If you dont trust a site to not send data to third party domains directly, why do you trust it to not send it indirectly?
No, I meam it restricts extensions because it does. Vouching for MV2 is like vouching for an Android OS without a proper permission model. MV3 helps against tracking, its good for privacy and security. If you want the convience of content blocking, uBlock Lite still works good enoough for many people. Though, you still lose on security and meaningful privacy (again, define a tracker and list them all, impossible) because extensions in general hurt site isolation and increase your fingerpint.
> You link three things, that doesnt equate to "every independent organization".
Seriouslu, is this the only counter-argument you could invent? I didn't have the goal to list all independent organizations in the world. Now, you have to find one saying the opposite to EFF.
> If you dont trust a site to not send data to third party domains directly, why do you trust it to not send it indirectly?
Because there were examples when 3rd-party ads delivered malware to clients: https://www.networkworld.com/article/946902/forbes-malware-a...
Also, because FBI recommends it: https://www.pcmag.com/news/fbi-recommends-installing-an-ad-b...
> MV3 helps against tracking
Against tracking by whom? By FLOSS add-ons intentionally installed by user and verified by the community? In contrast to random, untrusted websites running megabytes of proprietary JS?
This is true.
Many more care about neither,
or intermittently care about neither,
than most take into account.
You might also be interested in Jolla Phone https://news.ycombinator.com/item?id=46162368
If you're stateside and want a shipping Linux phone today, [FuriLabs](http://furilabs.com) is another option.
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.
> Stateside - being in, going to, coming from, or characteristic of the 48 conterminous states of the U.S.
In case others, like me, weren't aware.
I admit to being shocked that such a common phrase isn’t widely understood, but this site has plenty of international traffic so I can only say thanks for the context comment. :)
Yeah, it's funny how our contexts shapes what we believe to be universal :) I had the same experience with "ground floor" and "first floor", where seemingly every country has a different understanding and way they use those. Or even what "Caravan" actually is seems to differ too. Language is fun :)
Thanks! I had no idea that this existed. Unfortunately, the specs aren't great, especially when compared to Jolla's offering. Oh well.
I'm quite enthusiastic about Graphene's OEM partnership,though.
I share your enthusiasm re: Graphene OEM partnerships. I think it's fantastic what they've managed to pull off so far.
Re: the FuriLabs phone, yeah, it's rough - but it's definitely usable for early adopters who want to contribute and help build.
> but still I'd like to choose my hardware and software separately interoperating via standards
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.
The success of an OS is inevitably linked to the availability of apps. A "smart" phone today is basically useless if it can't run either iOS or Android apps. Projects like Waydroid can make Linux phones viable, but since there are approximately zero native Linux apps for phones, you might as well use Android as a FOSS base. This is precisely what Graphene and Lineage do.
What kind of Linux phone setup do you have, and what kind of experience has it been? I want to make the leap sometime, but not quite there yet.
I have an Xperia with Sailfish OS. The Android app support ironically ends up what makes it usable, but the new patch isn’t released with kernel support that actually makes the IO work properly. Its own app selection is pretty small. It would be cool if all desktop Linux didn’t need an entirely new skin to work at this form factor, else I could get what I needed. I also use Nix to smooth over some of the repository shortcomings.
Sailfish OS just takes the wrong approach, to be honest. It makes more sense to have the more secure OS at the host (Android) and the less secure as a guest for compatability (traditional Linux distro). Its also problematic that the app compatability delivered via the Anseood support uses an outdated Android version etc.
Pixel phones currently have the additional benefit of a full Debian OS running via AVP. This is (imo) on par with or better than having Termux on a rooted device. It's still fairly off-the radar which makes it a really good time to be exploring it's uses.
I agree, it has been lots of fun testing around in the KVM. Recently a GrapheneOS update even included the Button to attach to the "screen" of the VM. It also has GPU passthrough iirc?
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
Keep me/us updated!
Totally agree. Pixel devices are probably still the best Android offering, but I originally got into the ecosystem because it was less confined and that appears to be changing. While I'm likely not representative of most consumers, I would love it if I could choose both the right device and right software for my particular needs .
Even if google breaks compatibility, still using some compatibillity mode it's possible to run such apps right ?
I’ve been an iPhone user from the beginning but this would really tempt me.
We will see how that goes. I love GrapheneOS, I've used it for years, but the details matter. An OEM partnership might promise a lot at the start, but a lot can change between now and delivery.
Worst case scenario we still have Google Pixels.
I wonder if a real OEM supports graphene if that would solve device attestation for things like banking apps.
Non-Google attestation is still a bad thing.
I'd much rather GrapheneOS continue to get popular enough that banking apps are forced to support phones without attestation.
What do you mean? Graphene OS devices DO support Hardware-based attestation (AOSP standard), they just don't support STRONG or DEVICE Play integrity checks.
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.
Will never happen. Banks will not support this unless insurance companies include that. And that will never happen because they will never support something that a large company doesn't committ to.
Some do. Don't want to give out names, but it's slowly happening.
I'm writing this on a grapheneos pixel 5. I have the app for very-large-USbank and a few others. With 'exploit protection compatibility toggle' enabled they works fine. In what regard this applies to device attestation I couldn't say.
It doesn't. The app likely uses one of the others, dumb methods of detection.
Never underestimate stupid, especially for that sector.
Safety net is a joke and google only has it to milk as much as they can from OEM manufactures and gives false sense of security
GrapheneOS has device attestation support on Pixel devices, i.e. it passes SafetyNet. It's just that some apps (e.g. Google Pay) explicitly exclude it.
This is really cool, but, longer term, what happens if Google makes android closed source? I feel this is a very real risk.
Not sure if the big manufacturers would want to depend on a proprietary Google OS. Samsung does make a lot of changes to the OS, for instance.
> Not sure if the big manufacturers would want to depend on a proprietary Google OS.
They already do; Google's flavour of Android adds plenty of proprietary components on top of AOSP.
They depend on the Play Service and Play Store, that's for sure. But I'm pretty sure they know it's a risk already.
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.
What exactly are they going to do? Support GNU/Linux?
If Google goes proprietary with AOSP? They could fork AOSP, or go with their own proprietary system (like Huawei is successfully doing).
Linux distros (including non-GNU/Linux distros, e.g. busybox/Linux distros) are way behind for smartphones. I don't think they would switch to that.
They could still be given the sources, for a hefty license fee.
Pretty sure that Google sells the Android licence for as much as they think they can. Make it too expensive and the manufacturers will try to move away.
"Not sure if the big manufacturers"
thats the thing, they would supply android os to these major manufacturer, but for the rest??? need vetted applications
What's the alternative? I doubt even someone as big as Samsung will be willing or able to develop their own alternative OS (atleast one that can actually grab marketshare enough that critical apps get ported), and I can't imagine them wanting to hitch their wagon to the Linux alternatives.
> I doubt even someone as big as Samsung will be willing or able to develop their own alternative OS
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)
Huawei has a whole-ass Chinese government behind it with quite a lot of incentives to move away from Google. Samsung does not. Heck, China's making its own GPUs and x86 CPUs. They're not great, but when the incentives over there are that strong, the market forces are clearly in a whole different universe compared to the rest of the world.
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.
> Huawei has a whole-ass Chinese government behind it
I don't like how Chinese companies systematically get reduced to "it's because the government can help them". The US TooBigTech get a ton of help from the US government, starting with political pressures when other countries want to regulate them.
Huawei have really good technology and very competent engineers. It's not the Chinese government that does the engineering.
DJI is years ahead of everybody else technologically, and that's again not the Chinese government doing the engineering. Let's stop believing that the US are superior in every single way and that someone else doing better means that they must be cheating.
Equally lets not forget that china sees this as a key strategic necessity for a forced reunification attempt on taiwan, both for national security and the ability to produce chips solo.
Two things can be true. They can have great engineers and government money. Theyre not mutually exclusive.
Governments all over the world try to support their economies. It's not just a Chinese thing. How much does the western world invest in LLMs? But for some reason, we only call it "cheating" when China does it and is more successful than us.
What an outburst lol. I didnt call it cheating. Its just as worth noting as when it happens elsewhere. Perhaps you should stop reading what isnt there.
Where did I say you called it cheating? From where I stand, you're reading what isn't there.
Why would they be forced to develop their own OS? They could just license this theoretical future proprietary Android OS.
The comment I responded to was:
> 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.
They won't because they literally control the mobile market by having Android open source.
Now that their market is established, I don't think open-source is a requirement anymore. They would of course share with hardware vendors strategically.
True. All the big OEMs are in too deep with Android now, there's no going back. They could easily make it code share under NDA instead of open source.
Huawei proved that they can move away from Android... unfortunately they did not go for a hard fork of AOSP but for a proprietary, new OS.
"they can move away from Android"
nah, it still android
Since 2024, it isn't
https://en.wikipedia.org/wiki/HarmonyOS_NEXT
[flagged]
Looks like HarmonyOS no longer uses the Linux kernel, and removed all Android code.
Pretty different from Android then.
You don't know what you're talking about.
Those OEMs are responsible for the Android lock-in situation, and they do profit off it. They have the power to break that dependency easily with any alternative platform of choice.
Consider a GNU flavored Linux distro (includes busybox+musl also) or a BSD as an example. The difficulty that their devs face on smartphones is the driver set. Everything above it is open and free for anyone to implement any functionality without the need for any reverse engineering. All that the OEMs need to make them work is to release the hardware drivers for the platform - especially of the RF baseband. Open source drivers are preferable, but even proprietary driver blobs work to some extend (like the nvidia proprietary drivers on PCs).
But if the OEMs do that, then people would do a lot more with their smartphones. No more OEM blot/malware, infinite customizability and app options and the biggest of all - endless updates. People would use them till something in it dies, and then use it for something else that doesn't need the dead part. For example, how many smartphones are thrown out because their screens died? How many kubernetes clusters could you build with them? Naturally, that would affect the phone sales and OEMs certainly don't want that.
So then, what happens instead? Have you noticed how Graphene and Lineage struggle to support devices that already run Android? Obviously the drivers for AOSP exist. Google and the OEMs enter into a direct partnership where Google supplies the Android part with all its proprietary and play components, while OEMs convert it into the final blobs after adding their drivers and malware. The only way an external party is going to get those drivers is if somebody manages to extract them from those blobs. The OEMs supply updates for them for a few years and conveniently drop them after that. The consumer is forced to buy a new phone eventually, because their software becomes hopelessly outdated.
In addition to this, similar restrictions are imposed by manufacturers of subsystems like SoCs and RF baseband. Make no mistake about it. No matter how open any of it seems, the entire group of companies involved in this is a racket that's out to squeeze out every penny and bit of personal information from you. The OEMs are very willing participants in this scam.
What would they gain from making it closed source? There isn't any distribution of AOSP that competes with Android.
If they would close-source it, the community for sure will pick up the pieces.
GrapheneOS is the community picking up the pieces.
They're not. They're heavily dependent on Google, especially CVEs.
Who do you think runs the AOSP project or Project Zero?
What do you mean more precisely? :)
More and more functionality is locked behind closed-source play services. AOSP is basically useless at this point, it can't do much of anything without Google Play Services.
Well, in the much longer term they have usually mentioned they would like to use a more secure/private foundation (more in the direction of Qubes/Redox/Fuchsia) with a compatibility layer for Android apps if they have the resources to do so.
Then Android gets forked.
Has the OEM in question been revealed yet? Likely not one of the major OEMs because they all lock their bootloaders. I'm crossing my fingers it's Fairphone but that's because I love my FP5. The GrapheneOS devs have been pretty harsh towards Fairphone because of their slow updates.
They seem to refuse that they're working with fairphone, so it seems unlikely.
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
The most likely contenders are OnePlus, Motorola, and HMD.
> "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.
What about HTC, LG? Heck, Blackberry rising from the ashes?
I'd love for it to be Framework.
Those are no longer big these days so no. Also, they're not going to restart a whole product category just for grapheneos.
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.
> Also, they're not going to restart a whole product category just for grapheneos.
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.
> I don't think that there is any need to restart a new category. Just make your new phones...
For HTC, yes... But neither LG nor Blackberry are still making phones
BlackBerry hasn't been OEM for their last few phones - the KeyOne, 2LE, and 2 were all outsourced to TCL, who is still making handsets. This would also fit with BlackBerry's security image, and even pull in the OnwardMobility vapourware.
I'm every bit as skeptical as you are, and in no universe is BlackBerry the OEM in question, but I would like to live in my delusion until GrapheneOS proves me wrong - I want a keyboard, dammit!
Oh, I get it now!
BlackBerry has been out of the phone business for years now.
They basically sold the brand to TCL iirc
I don't remember where but heard it was Nothing
If you've run a open source project almost of any size, it's quite a task having to support it on various devices scenarios.
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.
This is excellent news. Google doesn't sell Pixels in my country for some reason. Hopefully the new phones will be easier to obtain.
Have you considered using mail forwarding, or sites like Swappa.com with forwarding built in?
Hoping this helps you get your hands on a cheap Pixel!
That's not only adding to cost but also doesn't solve the issue of why you would buy a new phone - warranty.
They just said Pixels.
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.
Damn, I just got a Pixel 10 pro XL for installing GrapheneOS. I hate how below average Pixel's hardware is and I wouldn't have minded waiting a couple of more years for this.
Pixel hardware is below average? Since when? That sounds like a flagship phone to me.
In raw cpu and gpu performance terms it is quite weak compared to other flagships.
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.
Meh good enough for everything unless you use your phone as a "gaming pc". But the extra open-ness and security is worth it for me.
No, just run a popular Roblox game on a recent Pixel or 3-4 year old Sony. The latter runs better:)
But yeah, it's my choice as well, because f** Sony software updates policy.
I guess my 8a is gonna have to do for a bit longer. This one is very exciting.
I literally just bought a pixel this week. Just my luck.
Pixel with GrapheneOS is still great. And it may take 1-2 years before GrapheneOS gets on this new device.
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 :-).
probably good timing
this will take a while and RAM prices will be out of control for a while as well
Why was it that in the early PC days, IBM was unable to keep a lid on 'IBM compatible', allowing for the PC interoperability explosion, yet today, almost every phone has closed drivers, closed and locked bootloaders, and almost complete corporate control over our devices? Why are there not yet a plethora of phones on the market that allow anyone to install their OS of choice?
Nobody gave you the actual answer. IBM was under an antitrust decree and had to openly license their technology for a nominal fee. (Supposedly about $5/PC.) So yes, they were in a hurry and used generic parts, but they still had tons of patents on it. When they got out from under this, they came up with Microchannel.
I guess antitrust is the keyword here. Something that is considerably weakened in today's USA.
IBM had/has a monopoly on mainframe systems. But they never were really dominant in midrange systems (e.g. VAX, UNIX), and Microsoft and Apple etc became huge companies in the PC market. So you can't really disagree with the rationale.
Obviously Google + Phone makers is a "trust", its frustrating the lawsuits aren't really going anywhere.
I continue to be of the opinion that many of our economic problems could be improved with more competition. (Depending on your definition of "problem" of course. The current state of affairs is fantastically profitable some.)
Oh for sure. Why are movies scattered all over oblivion? Because there's no simple marketplace for licensing movies, it's a closed market that requires doing lots of behind-the-scenes deals. Healthcare? Only specific providers can make medical equipment, tons of red tape, opaque billing structures, insurance locked out in weird ways, etc.
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.
This and also cryptography technology was not nearly as sophisticated and easily accessible as it is today, and where it existed it was pretty slow on the hardware of the time.
How much of it is cryptography? The only notable cryptographic locks are just the TPM-backed Widevine and the infamous Play Integrity, both rarely required due to how many older devices that would lock out.
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.
Secure Boot (or whatever it's called on each hardware platform) relies on trusted cryptographic keys to sign "the next step" in the boot chain, all the way back to the bootrom. This is how the higher-level SafetyNet attestations work on Android, and equivalent features on iOS, XBONE, etc.
You're getting a lot of indirect responses. If you've ever tried to mod your android phone the answer is simple. Its google play services and hardware attestation for things like banking websites.
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
Yeah but lots of phones you can't get ROMs for from a reputable source, and I sure as heck don't have the know how or time to build one, even if possible, which a lot of times is not due to locking down bootloaders, drivers, etc.
But that has the same cause.
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.
For me the bank app was working, but the electric scooter app didn't and that was it for me :( Damn e-scooters, can't live without them.
But I still haven't contacted the support to ask them to verify phones in another way.
Be sure to leave them a one-star review, and maybe name them here so others can do the same.
Anyone who does that sort of crap deserves at least that tiny bit of punishment for it.
The thing is they are the best e-scooters provider in town. They have fantastic support, few times agreed to my feature requests. They have very forgiving policy for when you forgot to lock the scooter and so on. I really believe that if I messaged them off season (when they work on the app, like now in winter), and suggested changing the way they attest phones, they would consider using the attestation that GOS can pass.
I think you're not asking for enough here. A scooter rental app does not need to attest phones. It doesn't even have a bad excuse for wanting to attest phones since payment information is surely stored server-side and it would be surprising if the scooters didn't have their own network connections and GPS trackers.
You cant rate it without google play app playstore lol
You can if you have a Google account; Play Store has a web version.
Would they even allow you to rate an app that you have never installed?
Looks like it won't.
Naming it publicly would allow those who have a Google-blessed Android device to rate it though.
Years ago I used to love playing around with roms on my phone on XDA and it worked OK. I don't know what folks use these days. But as recently as a few years ago I merely rooted my phone and I couldn't use a lot of apps, not just banking, but even some games.
It's crazy how locked down the ecosystem is.
There are tools to make your device appear to every app as running in a non-rooted environment. Here[1] is a tutorial on how to bypass Google/Samsung Wallet detections. There are threads for different apps and it will quickly turn into a cat and mouse play when Playstore app itself updates, but as the phone is rooted, someone will continue to find a way to bypass attestations and will post a comment on Reddit or XDA explaining how to do it.
[1] https://old.reddit.com/r/Magisk/comments/1lxbdpw/tutorial_ge...
Thanks! I'll look into that next time I decide to root my phone.
This just shows that the barrier of entry of a new phone OS is more than $0. You can pay app developers to port their apps off of play services, you can pay developers to add support for your attestation keys. Considering how many billions of dollars Android makes for Google, there is a room for a return on investment for an alternate OS to enable investments into a new OS.
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
I think that is pretty different than what is happening here because:
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.
Amazon and BlackBerry both tried the whole “you can upload your same APK to our AppStore approach”.
And well, when’s the last time you used the Amazon android AppStore?
That's akin to creating a new browser and pay site owners to support your client. You can do it for a few dozen sites but that can't be your primary strategy.
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.
How much do you want to pay? Who will be paying? Big companies will probably laugh such an effort out of the room, nay, they will not even let you into the room to talk with them.
$10 million dollars per app. The creator of the new OS will pay. If you offer enough cash they will stop laughing.
Have you ever tried to pay a bank to do something for you ?
Trying to get some scale, you're hypothesizing about giving 10 millions to HSBC to make business with your startup, when they're throwing away 500+ millions every year just to cover their money laundering.
https://www.investopedia.com/stock-analysis/2013/investing-n...
And we're discussing doing this for basically every major banks.
But what what I'm asking for is only a small amount of engineering time to add 1 line to their gradle and change 1 line in their app's code. This isn't a deal spanning many engineering years doing on going work and having to measure how effective things are. It's a small change plus the overhead of making a deal and getting through the beurocracy.
The issue is to have them do anything at all.
I see it akin to the proverbial "not getting out of bed for less than XXXXX". You're getting out of bed every day, for free. But having someone make you do it for a specific reason will be an exponentially harder proposition.
> 1 line in their app
Aren't you asking them to maintain compatibility outside of Play Services and be on available on your platform ? That's a whole project, including their (or their contracting shop's) validating the whole new stack from a security and technical perspective, and a legal and business check on what that actually means to them.
Perhaps we can look at it from a darker perspective: if a random guy came to the bank to ask them support for their parralel phone ecosystem, the bank would at least want to know what they're getting into and what's in it for them. Especially if they're offered 10 millions for allegedly one line of code.
>not getting out of bed for less than XXXXX
I just made up the figure. Perhaps 10 billion dollars is more enticing. Perhaps you have to purchase the company outright and then dictate they add support. My point is that it's not impossible to get the apps people need to work on an alternate Android OS. It is a matter of funding conpatibility. You can find a niche audience of people to start out with to make a competitive OS for them. And then overtime expand that audience more and more.
>Aren't you asking them to maintain compatibility
Typically the complaints about banks is that they use the Play Integrity library which doesn't trust other operating systems. So the ask is to support the Android API for integrity and to trust the key of the OS provider. This would be done via a new library to make integration easier and more foolproof.
> It is a matter of funding conpatibility.
Key clients requesting support for the alternative OS will be a way faster route IMHO. The same way nobody bribed banks to support android, they saw the market share and potential and decided by themselves it was a worth doing. Which is why it came so late.
I understand you're offering a way to get around the chicken and egg problem, I'm saying dealing with the supply part is crazy hard. Somewhat paying users to buy into your ecosystem despite the lack of support could be a better use of money (I'm thinking about Meta subsidizing Occulus until it got some traction, and I assume it's still in the red after so many years)
> the Android API
People loosely explain the lack of technical challenge, but from the institution's POV you're asking them to expand their trust from Google, a US company which will be solely responsible if anything critical happens...to potentially each single phone maker, whoever happens to be selling the device to your clients ?
If Google didn't exist that's what they'd do. But Play Services is a thing. The more I think about the less I see an incentive for any established player to do that move until customers are actively clamoring for it. There's just no upside otherwise.
You do understand that buying the rest of society so they can make apps for your open platform is not really feasible, right?
Where do you think the creators will get this money from? Look at existing ones, they are cash strapped as they are, paying a million to get an app over beyond their budget, let alone 10 million
Investors. Trying to become a new competitor in an established industry often takes a large amount of capital. If you tried to create a business to compete in another industry, you'd also need to find investors or other forms of financing if you are cash strapped.
Investors are not dumb. The current duopoly is entrenched and merely asking for money to create an alternative os won't give you investment. Microsoft and Nokia among others failed big time even though they had plenty of money and competing operating systems. Investors give you money if they think you will be successful and return a multiple of that investment within a reasonable timeframe.
You need to solve the 3 player problem before you even ask for money: getting device manufacturers in even though you have no operating system, no devs and no users, getting devs even though you have no operating system, no devs, no users and no devices, getting users even though you have no device, no operating, no devs and no apps.
You need an MVP that shows promise towards all the above if you seek money.
This is like taxi on demand app business or the takeaway delivery business but with more players and with a higher minimum funds requirement. Plus the fact that unlike taxi apps or takeaway apps, choosing an operating system is a zero sum game so you are competing in the most direct way against well known and well established brands like iOs and Android who are funded by the richest companies on earth. Unlike Uber vs Lyft, where a user can install both and use both, your battlefield only has one victor. And given that other companies with more funding that you will ever see in your lifetime still failed, you have a virtually impossible task of explaining (before they even consider giving you a single cent) how you are going to be able to capture market share with your own solution to the 3 player problem.
Nokia and Microsoft only understood this right at the end: to avoid losing in the mobile os market, you need an ecosystem. Miss any of the elements and it all crumbles. Read Elop's memorable Burning Ship note on the final days of Nokia.
do you think Valve could do it, with modified Steam Deck and SteamOS?
> how you are going to be able to capture market share
gaming
> Why are there not yet a plethora of phones on the market that allow anyone to install their OS of choice?
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.
Most ARM devices don't have UEFI or a standardized hardware abstraction layer as x86/x64 does, a prerequisite for having a choice of OSes.
I don't believe that's the true problem. Booting operating system is not a problem. There's no standardized hardware abstraction layer in PC either, every OS brings their own set of drivers.
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.
> My guess is that modern hardware is too complicated for one hacker to write reliable 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.
https://youtu.be/36myc8wQhLo
Excellent and scary video that I share myself all the time.
In the ARM world, there isn't even a standard way to boot, and there are no standard hardware interfaces - except maybe the interrupt controller, since it's part of the CPU and only ARM designs the CPUs.
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.
I worked with ARM boards, I know a bit about it. Booting into Linux is never hard, it's all about using uboot, sometimes with tiny patches on top. I think it's actually even easier with android phones, as you don't have access to the low level bootloader, you just use fastboot stuff.
Having basic framebuffer in BIOS/UEFI is neat for toy OSes, but not very relevant for something practical. You gotta need proper driver for GPU. And if you're just starting, UART console is actually more preferable way to interact with board, IMO.
Booting into a mainline Linux kernel on your average junk-level SBC with all the hardware working (without simply sticking to an Android-like downstream/proprietary BSP) is quite hard, and that's what you need in order to make a phone usable as a daily driver. That's really the root issue; mobile phones are built as embedded devices, with no consideration for running a generic OS kernel. This isn't even an Android issue, OpenMoko was the same deal. If anything, Android was the first mobile platform to even loosely approach any kind of PC-like openness.
It all comes down to available drivers.
If drivers are available and you just need to write DTS to configure the driver, that's not a big issue. I don't think anyone thinks that Raspberry Pi has terrible Linux support, despite lack of UEFI, ACPI and all that stuff. Plenty of Linux distros support it well.
I generally agree, but as a caveat sometimes it's cheaper, more robust and more efficient to build an integrated system without having to worry about interoperability. BYD's electric vehicle chasis for example, seems to greatly cut manufacturing costs, even if it makes swap-in repairs harder down the road.
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.
> So why would a company, in this new environment, invest resources in making their hardware compatible with competing software environments?
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.
> Hardware attestation needs to be an antitrust violation
Yes!! Absolutely agree. This needs to be made illegal.
Some of the funnest work, if you could get it, was swapping ssds out of laptops coming through customs for high value targets.
Which is another reason we need to strip this hardware attestation stuff out of the hardware. It either needs to use exclusively keys the user loaded into the device themselves or the keys aren't on the device whatsoever and then the "high value targets" verify the contents of the drive from a known-clean machine once they get it back from the adversarial foreign officials before putting it back into service. Or better yet, keep a separate laptop on each side of the border and then sync the data over the internet instead of losing physical control over the device at an adversarial border.
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.
These are new machines before users get a chance to load anything. Thus the customs part.
Are they also putting malware on all the drives in every random retail store or what stops someone from just buying one when they get there?
Can you expand a bit? They didn’t notice the ssd swapped? Which country? Customs as in sending deliveries or passing a border with a laptop?
A company buys laptops for its employees and they get shipped from outside the US, and before they get delivered nice changes have been made.
Any specific individual that is high value will walk into a store and buy from stock.
Ok and buys the laptop with malware? How the customs knows that high value target will buy that specific laptop they swapped the ssd? And what they do exactly? Put malware to steal his data?
You are working inside freaking customs and know where it is being delivered. Read between the lines.
The only thing proprietary in the early PC architecture was the BIOS. Everything else was pre-existing architecture from third parties, there was nothing to keep a lid on.
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”.
Even the batteries are not interchangeable on phones. You'd think all phones should have the same exact battery, that this kind of standardization is beneficial for phone manufacturers as it helps them bargain with their parts suppliers but no for whatever reason we can't have that.
Edit: I am not saying just user replaceable. I mean standardized so the same cells in a 2024 phone also works on 2025...
Why, of all parts on a phone, would you expect the battery to be the one that's already good enough that it should never need to be upgraded?
"Battery capacity" is like the one thing phone manufacturers still try to improve.
The interfaces and the external dimensions can remain the same even as the internals change though, right? And you can have more or fewer cells. The cells don't have to be cylinders, either. They can be flat.
They are usually shaped to fit in exactly the space available to maximize capacity. Standard cell sizes wastes space.
Besides it's pretty easy to get custom battery pouches made.
Who will make these custom battery pouches for old phones though? Think my old Poco x3 pro, not the iPhone 17. I am sure there are tons of people willing to make batteries for the iPhone 17 but I feel like the interest wanes as the phone gets older?
For older phones, the batteries we buy are likely also old stock left over if we can find some in stock anyway, right?
> Why was it that in the early PC days, IBM was unable to keep a lid on 'IBM compatible', allowing for the PC interoperability explosion
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.
IBM was in a hurry.
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
https://youtu.be/_cMtZFwqPHc
“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.
Cory Doctorow answers this in his book “The Internet Con”. IBM fought with DoJ for years. Today, it’s a felony to mess with anything locked down (anti circumvention)
I don't think it's a felony to root/jailbreak one's own phone.
https://www.eff.org/deeplinks/2019/06/felony-contempt-busine...
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.
The problem is doing it as a company. IBM wasn't defeated by hobbyists building their own PCs. They were defeated by other companies reverse engineering their BIOS and selling their own IBM compatible systems. This isn't possible anymore. It just means you get buried in lawsuits until you go bankrupt.
It is. 17 U.S. Code § 1201 - Circumvention of copyright protection systems
Well actually, it isn’t for individuals and certain groups, technically.
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...
https://www.eff.org/issues/dmca-rulemaking
You’re breaking the TOS which is a felony according to the CFAA
Sounds like FUD to me. All of the cases I’m familiar with actually say that violating TOS isn’t against CFAA.
https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act
Familiar with the Aaron Swartz case?
Yes, I’m familiar with the case. He was caught interfering with equipment on the MIT campus in order to additionally violate TOS of JSTOR, wasn’t he? He shouldn’t have expected to prevail in court, and I’m saddened by his decision to end his own life. That said, he did a whole lot more besides violating TOS, so I’m not sure how applicable his case is to the topic under discussion, strictly speaking.
The charge of computer fraud was based on the breaking of TOS for MIT and JSTOR
The systems and software were vastly less complex and powerful in the 8088 days.
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.
Other companies saw that IBM effectively lost control over their platform (and thus lost a large revenue stream), and are determined to not make the same mistake.
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.
> Why are there not yet a plethora of phones on the market that allow anyone to install their OS of choice?
Here you go: https://puri.sm/products/librem-5 and https://pine64.com/product-category/pinephone/
Well, back in the day many of the people making buying decisions were tech enthusiasts who like the idea of upgradeability, etc. Computers were quite expensive, and people didn't want to waste money on a box which can only do one thing.
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
The hardware was evolving way faster 40 years ago and in much consequent ways than these days. Plus number of users grew exponentially. So a company spending too much efforts on software could loose its edge on the hardware side. And locking hardware would be counterproductive since as it would limit new users.
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.
Because the original IBM PC was designed to be cheap and built in a hurry. IBM had a mandate for the original PC to use off the shelf components as much as possible. They also neglected to secure an exclusive license from Microsoft for DOS. 95% of building an IBM PC clone was buying the same parts and getting a DOS license from Microsoft (which they were very happy to sell you). Everyone saw what happened to IBM and just didn't do it that way again.
You can actually look at history and see what happens when IBM tries to wrest control of the PC platform back with the PS/2, which was a flop with consumers because it wasn't backwards compatible enough with IBM's own previous PCs or the wider PC market that developed. A bunch of PC clone manufacturers got together and came up with the EISA bus standard so they wouldn't have to pay IBM license fees for MCA, and made it backwards-compatible with ISA cards people already had. It was successful enough that IBM ended up adopting EISA for some of their PCs.
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.
The company making a device that is licensed by the FCC has to do everything that they can to mitigate the risk of an unlicensed broadcast on their devices.
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.
I see people saying things like this all the time and then when I ask them for the specific text requiring them not to e.g. publish source code, nobody has been able to show me.
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.
> The company making a device that is licensed by the FCC has to do everything that they can to mitigate the risk of an unlicensed broadcast on their devices.
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".
SDR for listening does not require a license. For transmission, depending on the power and frequency may require a broadcast license.
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.
Well, I sit corrected. Thanks for digging all that up.
The business world learned from their mistake.
Obviously this situation can't go on.
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?
One comment mentioned Jolla. Another currently available option is [FuriLabs](http://furilabs.com). It runs atop Hallium/etc but you are effectively still able to daily drive a mobile Linux shell and contribute to the ecosystem if you want to see it grow.
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.
Furilabs was just in the news here because they discontinued their device models from a few years ago, and released a new device for a big price bump with _significantly worse_ hardware.
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.
Yeah... I don't care.
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.
> 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.
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.
Take a look at Jolla and Sailfish OS.
https://news.ycombinator.com/item?id=46162368
https://sailfishos.org
FWIW, Jolla just announced a new phone: https://commerce.jolla.com/products/jolla-phone-preorder
It was discussed here when it was announced. I believe it was determined the hardware is an ultra-low-budget Aliexpress design that normally retails for ~$100 that they had custom built with a mic cutoff switch added to it (probably the cause of a large portion of the hardware price increase). I dont remember the specifics, but even thr most optimistic were pretty sure it won't get hardware vendor support for even a full year based on the specific processor it contains.
Replying to myself: Apparently I was mixing up the new Furilabs FLX1s and new Jolla phone. The FLX1s that's a major downgrade from the prior FLX1 and some people were reporting are based on a design that's really cheap on Aliexpress and using very old hardware but with a custom spin to add some physical switches to it.
The new Jolla actually does look really good compared to all the other avaiaobale Linix phone hardware options.
What phone with OLED, 12GB RAM, 256GB storage, and user replaceable battery is $100 on Aliexpress?
Can you please refer to the source of the Aliexpress design claim?
I looked through https://news.ycombinator.com/item?id=46162368 and there was nothing like that mentioned.
https://liberux.net/ looks promising as well.
WARNING: This is a Kickstarter device still, and needed funding to even create a proof of concept device last time it was discussed (extensively). It's a Flagship phone device and price, but with only the oldest of pans on how it's actually going to deliver some on of the promises.
GNU/Linux phones exist and can be used as daily drivers, if you put enough effort in it. Sent from my Librem 5.
Understaffed gift product wants 1 week cycles.
OEMs want 2-4 month cycles.
This is a perfect representation of the state of the software industry.
I don't think that's a fair comparison.
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.
> I don't think that's a fair comparison.
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.
Android CTS and VTS are open source so we can and do use those. They're filled with flaky and badly made tests along with enforcing anti-privacy and anti-security design decisions though, so not everything is supposed to pass. Google likes to enforce that OEMs aren't allowed to make certain kinds of privacy and security improvements which could impact app compatibility until Google decides to do it themselves in new major Android versions with new API levels forcing app developers to deal with it.
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.
> AIUI updates are less stringent and burdensome than initial certification
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.
We'll have the same update pace for security updates and major releases with the devices we're working on with our OEM partner. That's not specific to Pixels. It will in fact be easier to support the devices with the OEM partner due to them planning on doing most of the device support work including getting MTE working properly. For Pixels, we have to do a lot of work on device support, while for non-Pixels that work is going to be done for us. Our OEM partner is actively getting what's needed from Qualcomm including getting them to fix things. We're in direct contact with Qualcomm ourselves and plan to deploy new security features they've developed which are not yet available elsewhere.
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.
Thanks for following up here. I’m glad to hear the OEM stuff is ongoing that’s going to be so big. Congrats and good luck!
Hopefully you don't mind me asking this question, but didn't you work with people who managed to do exactly what you are suggesting with a fairly small team at Essential for a few years?
Yep. And GrapheneOS's changes to the kernels of devices they ship are laughably small, 20-30 commits at most. I don't think they even do any basic CVE checks on any of the source code.
Fuzzing, actual security analysis - all those things are done by Google.
Their contributions upstream go way back, I think someone could misread this comment that they've not contributed, and that would be an unfortunate misunderstanding.
GrapheneOS has made substantial upstream contributions to the Linux kernel and Pixel drivers including vulnerability reports. Many of our kernel changes are for the out-of-tree drivers needed for Pixels which are in a separate repository from the Generic Kernel Image code from the upstream Linux kernel. We make important downstream changes including enabling many more of the upstream security features and adding important protections not yet available there. We worked with multiple upstream Linux kernel developers to get many of the changes we used to have upstream and therefore no longer need them. We have major kernel security improvements in development including more security-focused integration of hardware memory tagging, but indefinitely maintaining those downstream is not the way we try to do things.
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.
isn't that by design? for GKIs i mean
The GrapheneOS obsession with picking a fight with everyone else is the most unfortunate part of the project.
It doesn't seem to be the entire project, just one dev (afaik) that's quite outspoken and does make accusations that they don't always seem to back with evidence. Also insofar as the actual "product" remains completely untouched by any spats it shouldn't be a dealbreaker for anyone wanting to use GOS, but of course it isn't ideal to have any drama attached.
He never shows any evidence. Always accusing without any images/links. I love the project but it looks not normal.
https://news.ycombinator.com/item?id=46185361
Alright, didn't mean to make any libelous claims, it's just so it happens I never saw any evidence from your accusations. I already know these people are the worst, but it would be helpful if in any of your posts you would share some evidence like you did right now.
Where's the evidence for the accusations being made towards me? No need to answer: fabrications and spin on Kiwi Farms and 2 Kiwi Farms adjacent videos on YouTube, which are regularly referenced and directly linked to by people involved with multiple companies and open source projects in the space. Here's a very recent example of the founder of /e/ and Murena once again linking to libelous harassment/bullying content, this time on a blatant neo-nazi conspiracy site:
https://archive.is/SWXPJ
https://archive.is/n4yTO
He's done this many times before and has directly spread Kiwi Farms harassment content himself from his personal accounts along with using the /e/ and Murena accounts for similar attacks. We never picked any fight with /e/ or Murena, they spent years spreading misinformation about GrapheneOS to mislead people into buying highly insecure products and services. They're enraged by us countering that misinformation as we did here with verifiable, accurate information with third party sources you should read too from Divested Computing, Mike Kuketz, their own forum (sending sensitive data to OpenAI without consent and falsely claiming it's anonymized when questioned) and elsewhere:
https://discuss.grapheneos.org/d/24134-devices-lacking-stand...
What is it you think hasn't been adequately proven?
Our chat rooms, forum, etc. are being endlessly raided with CSAM, gore and harassment towards our team. Our team is being swatted and threatened on a regular basis. We're having endless libel and bullying directed towards us including these baseless claims that we're insane. What the people attacking us can point to is that they think our replies debunking it and defending ourselves are too verbose which somehow makes us insane and delusional. Us banning people from the Techlore and /e/ communities raiding our rooms pretending to be users initially then attacking our team with harassment or posting CSAM is somehow us being toxic rather than those communities being toxic. It's not them being targeted with harassment. It's not them having fabricated stories spread about them.
It's you folks making accusations without evidence which simply reference a bunch of harassment content proving what we're saying is true. Linking to that harassment content proves people are doing it since most people can see it for what it is: a bunch of poorly made lies and misrepresentations to target someone with harassment.
You're making libelous claims without evidence while falsely claiming that I'm doing it. This typically goes along with baseless claims that I'm insane, delusional, schizophrenic, etc. with links to extraordinarily dishonest content filled with obvious fabrications from a couple serial harassers. One of those serial harassers has an identity verified Kiwi Farms account and was the one who involved them in targeting me (kiwifarms . st/members/larossmann.132201/). We've provided a large amount of evidence. Here's the leader of Murena and /e/ linking to libelous harassment content towards me on a conspiracy site this week: https://archive.is/SWXPJ + https://archive.is/n4yTO and we have dozens more examples archived for him specifically. You target us with libelous claims, bullying and harassment then claim we're creating drama for defending ourselves from it and documenting it. If you want the 'drama' to stop then stop engaging in harassment.
Don't know if you're replying to a wrong person but my point in the comment was about many of the tweets that get passed around include claims without links to any evidence. The recent tweets I've just seen from the top of my head were in relation to accusations of /e/os and Iode having government ties, but no evidence for that was linked in the tweets. A common person isn't going to go digging where that evidence has been presented if it isn't very clearly available, if at all. It may have a hassle to include it to every tweek, but the impression stands. Also never contested any of the harassment you have received.
> many of the tweets that get passed around
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.
Rossman only ever commented on kiwi farms on a thread about himself. You are lying again, confirming the words of the parent comment.
And deserved criticism is not harassment.
People in that thread mention a GrapheneOS project member together with the worst of bigotry, slurs and death wishes. And Rossman just decides to keep replying and talking in that thread. Like its worth engaging with these people and they deserve attention.
He didn't say anything about Gos devs in there, yet they say he did. It's just not true. Do you have a Facebook account? Facebook is full of scams, are you also a scammer? Probably.
He engaged / replied to the people that were talking about both a GrapheneOS dev and an Asahi Linux dev.
Imagine the following: People in a thread made about you start posting death wishes about people you have conflicts with, make bigotted comments about them and on top of that are in general being ableist and hateful towards multiple societal groups (things akin to "I wouldnt trust the GOS dev just like I wouldnt trust a <insert horrible slur agains trans people even though completely unrelated>").
Would you think it makes sense having a friendly chat with these people, as if they are worthy conversation partners? Shouldnt they either be ignored or judged?
Do you research everybody you engage with? Are you a fed? He went there to refute some claims about himself, like a man, instead of crying behind organization brand on social media.
And stop moving the goal post. Now it's guilt by association, what's next?
He replied to the problematic bigotted messages of those people. Im not saying he talked to people that were acting problematic in other posts/threads. He engaged with problematic people saying problematic things as if they were totally fine unproblematic people worth engaging with in a friendly manner.
That's the most delusional thing I've read all month. Sometimes you must deal with problematic people. Ever heard of Daryl Davis? Be like him 1% and world will be a better place. Don't be like a reddit moderator.
That is also my feeling, at least from a part of the GrapheneOS community. I have seen them despising and bullying /e/OS, Debian, F-Droid, the Linux kernel... Too bad for this project, that is amazing, to have such toxic folks.
Open source communities should help each other, and work together, not fight.
You can't equate actions from a part of the community with actions by the project. If you would see any bigotry by a GrapheneOS community member, please report it to the moderators. Bullying, toxcity and misinfo are not allowed. Action will be taken.
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.
*There is no big conflict with Debian or Linux kernel at all.
(Typo)
“The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.”
And the unreasonable man has decades of security research under his belt and somehow you know what's best?
I think they're agreeing with you
When have they been wrong?
That's actually one of the best parts.
Not for the ones on the receiving end.
Being on the receiving end of valid, technical criticism in response to making misleading claims about GrapheneOS for falsely marketing products is their own choice. It's certainly a lot nicer than being on the GrapheneOS team heavily targeted by libel, bullying and harassment from those groups. Here's a recent example of the founder of /e/ and Murena linking to libelous harassment content on a conspiracy site, which links to a Kiwi Farms style character assassination video from someone friends with neo-nazis:
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.
The attacks on GrapheneOS from Copperhead and their supporters including within other projects were not a fight we picked. You're pushing a false narrative in support of years of libel, bullying and harassment towards us. Your project's team has regularly engaged in very underhanded attacks on ours despite us never doing anything to you. We have archives of it.
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/).
Listing a bunch of projects I've not heard of and attacking me for "supporting" them is exactly the kind of behaviour I'm talking about :P
GrapheneOS did not attack you or your project. The same goes for the people you're supporting who chose to attack us for years and then feigned being victims when we finally began defending ourselves. We'll defend ourselves from the libel from your project too. You're choosing to make manipulative attacks on it without an actual basis to try to pile on the existing ones, while feigning ignorance of all of that. The chat logs show you aren't actually ignorant of it.
No one is attacking anyone. I feel like you're talking about someone else?
You came to this thread to promote an inaccurate narrative in support of the absolutely vile attacks on us. Meanwhile, we've never done anything to you or your project beyond promoting it as one of the available options. We stopped doing that a while ago due to attacks from yourself and other project members. We haven't responded to those attacks beyond not mentioning your project anymore and removing our many past links to it.
We have chat logs archives of your rooms which can be used to prove ongoing attacks by your project members towards GrapheneOS and our team. That includes voicing support for harassment content. Is it as severe as what we can show for many others? No, but it's enough. I'm not confusing you with someone else. I'm aware of who you are and what yourself and others you work with have said over the years.
Far from attacking your project in fact I often provide support for your users there's no ill will from my side let me assure you
You regularly attack the GrapheneOS project and our team in your chat rooms including supporting libelous claims about us, as do others who work with you.
>Your project's team has regularly engaged in very underhanded attacks on ours despite us never doing anything to you. We have archives of it.
What team are you talking about? JMP/Cheogram? This is the first I've heard of this.
You can tell it's truly secure and private because the Cellebrite leak says they can't break it (one of very few!) and some governments assume you're a drug dealer if you use it. My next phone will run GrapheneOS.
Have a link to the source? And have they said they can’t break it, or haven’t yet? I’d imagine from a business perspective it would hardly be worth it
There more sources if you google, but someone leaked a Cellebrite meeting.
https://www.androidauthority.com/cellebrite-leak-google-pixe...
https://arstechnica.com/gadgets/2025/10/leaker-reveals-which...
https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju...
It could also just mean they haven't bothered try
Their marketing slides include GOS, and they have since 2021 I think was just said "can't access that".
I would imagine it's a very high priority if you have powerful targets. They're not gonna be running an off-the-shelf android phone.
Considering they mention it on their marketing materials, they definitely did bother
Marketing is known to lede a lot of bullshit. Celebrite saying "We tried our stuff and it didn't work" is very likely more about obscurity than focused effort. Unless you know that celebrite has been specifically hired to break into a GrapheneOS device and put as much effort into it as they do into standard Android and iOS and failed, it means nothing. It's like the old thing about MacOS 9 being more secure than Windows.
Does the Celebrite leak say out can break recent iOS?
Don't worry, Apple can do it themselves as they have full remote access
Source:
The source is Apple. They can access any phone if they want to. In this case, they didn't want to.
https://en.wikipedia.org/wiki/Apple%E2%80%93FBI_encryption_d...
I don't see anything written there that says Apple has a current capability to "access any phone" which I am assuming to mean personal info like SMS message contents... just a whole lot of reasoning why they haven't had that capability in years.
They are literally in PRISM you fucking idiot. But hey, go ahead. Be ignorant, believe what they say and their marketing team which has been deceiving normies since forever
Great, so this means that the only way to get an Android release that's up-to-date on security patches is a binary-only distro - either Google Pixel, or the GrapheneOS preview channel.
Just wonderful. Google should know better than this, shame on the other OEMs that forced this mess.
If it's any consolation, preview builds are reproducible at the point that the embargo ends. A bit better than the definition of binary that we're used to.
https://discuss.grapheneos.org/d/27068-grapheneos-security-p...
GrapheneOS goes even further by allowing you to opt in to pre-embargo security releases, bypassing the vulnerable window between vendor disclosure and OEM patches. Awesome!
So this is interesting, they release the patched binaries several months before anyone else does and several months before the source code of the patches is released?
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.
You can extend your thanks to Google, as what you said is also easily done with Google's own updates.
I absolutely loved my Moto X with the walnut back. I switched to an iPhone when it stopped getting security patches.
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?
I've rooted and installed a few custom ROM's on phones back on the day, nothing recent though.
Here is a good place to get started with your Moto X. https://xdaforums.com/c/moto-x.2449/
> may i ask how you obtain the source? Are you registered as an OEM at Google?
Same question, how does Graphene get patches?
They have partnership an OEM who provides them with sources.
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.
> It's quite surreal how unsafe the standard Android
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.
> Google for one updates their devices for 7 years since Pixel 6
Pixel 8 https://endoflife.date/pixel
If I don't misunderstand you, you're suggesting the Pixel 8 line is shown red/discontinued? If that's it, you're probably on a mobile browser which might cut off right after the Discontinued column. The table goes on next to that where you'll see that all Pixels since 6 are currently still supported.
Pixel 8 line:
> Ends in 4 years and 10 months (01 Oct 2030)
You misunderstood. He’s saying that Google provides 7 years of device updates only for the Pixel 8 and later. That’s true: Pixel 6 and Pixel 7 only get 5 years of updates.
Pixel 7:
> Ends in 1 year and 10 months (01 Oct 2027)
Pixel 6:
> Ends in 10 months (01 Oct 2026)
Ah, that makes more sense. Thanks for clearing that up.
Pixel 8 updates end in 2030. Or did you think the 7 years of updates didn't apply to it?
Yes. They've parterned with an OEM. In fact, they are making an official GOS phone with that OEM.
Here's the discussion forum post going over it: https://discuss.grapheneos.org/d/27068-grapheneos-security-p...
afaict it's more like "making sure <OEM>'s next flagship supports graphene"
Although I don't use it I will be supporting the project. I'm quite proud of what they've achieved so far.
As a LineageOS user, I'd be interested in the disparity between GrapheneOS and LineageOS.
If you have a Pixel -> Graphene, if not -> Lineage.
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.
Don't understand your statement about avoiding client-side scanning of text messages. I've always assumed it would be done by the apps themselves, e.g. WhatsApp, Telegram, etc..
I think they're saying the phone doesn't stop you from installing a version which doesn't do that.
That sounds amazing. I aspire to get a setup like yours. I am on a Pixel with the stock OS and I can't stand the way Google is pushing AI into everything on my phone.
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.
This depends what you mean by 'issues with NFC'. My understanding is that Google require an OS that is blessed by them for contactless payments in Google Wallet to work. That restriction applies to all alternative operating systems that aren't Google certified stock Android.
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.
I doubt contactless payments will ever work on Graphene. In any case, I don't find carrying a credit card particularly inconvenient. I prefer cash for small transactions too; it's the only means of payment that is truly anonymous.
They have different goals:
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.
that is simply wrong.
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
This is the correct response. I use both GrapheneOS and LineageOS. But LineageOS focus is on delivering newer versions of Android to many phones abandoned by their OEM. GOS exclusively focuses on security and privacy. If you want a reasonably secure phone but don't want Google or Apple inside your device, your best bet is GOS.
I am overwhelmed by the specificity of your demonstrated knowledge on this topic.
How can LOS's security be somewhat close to GOS if it's worse than OEM? LOS lacks verified boot, hardware security features, it's often behind is security patches.. With "advanced protection" enabled stock OEMs are even more secure, but GOS is even more secure still. When it comes to EOL devices, LOS may be more secure than OEM depending on your threat model.
https://eylenburg.github.io/android_comparison.htm
It very much depends on your personal threat model, if you expect targeted attacks LOS doesn't hold a candle to GOS, but at least for my threat model verified boot and hardware security features outside of my control don't have a substantial security benefit.
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.
https://eylenburg.github.io/android_comparison.htm
That comparison shows "Deblobbed? Yes" for GrapheneOS. That implies they've replaced (most of) the blobs for wifi, bluetooth, 5g chips etc.
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?
They can because they essentially support Google chipsets, which are not blobby like MediaTek or Qualcomm because Google for all its faults is still relatively open (except their recent change in release schedules is why the Pixel 10 series still only has experimental GrapheneOS support).
Here’s an example of the radio firmware and vendor blobs required for a pixel 9 pro XL build: https://github.com/TheMuppets/proprietary_vendor_google_komo...
Nobody, including Graphene, is getting away with building their own modem firmware. The reduced blobs are on userspace and some HAL components.
Yes, even Apple with its practically infinite resources took 14 years from when it acquired Infineon's mobile chipset unit to launching its C1 modem. So much of the telcos' allegedly open protocols are actually implementation-dependent that it takes a lot of testing on actual mobile networks to validate interop.
> took 14 years
It was at most 4 years. Intel was the one that bought them 14 years ago and divested most of the IP off to Apple 6 years ago: https://www.apple.com/newsroom/2019/07/apple-to-acquire-the-...
Do you claim that there's a place where I can find datasheets for peripheral devices for Google Pixel? Like GPU, etc.
No, but they used to publish the source code for the drivers as part of AOSP. Now they no longer publish the device trees. Check out GrapheneOS' other Mastodon posts for the gory details.
It's nowhere near that. Pretty sure even modules are signed by Google.
Nice! Thanks for the link. I noticed they didn't mention MOCOR OS (for the new Nokia 3210), but then I remembered that that's not an Android version. I'll see if they can add it somewhere else.
Unrelated, but this led me to find gnuclad, which may be somewhat externally maintained and is used to create the cladogragms.
This is a great resource! Thanks
If you care about security above all else and you have a Pixel, GrapheneOS should really be your only consideration.
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.
It might be important to mention, that Lineage OS is available on a number of the devices abandoned by their original vendors, so sometimes it may be a much better solution to get a Lineage OS onto their former "flagship" which stopped getting updates 18 months after the release.
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.
Just yesterday I took an old Motorola smartphone from 8 years ago (Android 9) and put LineageOS on it.
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. :(
GrapheneOS is a locked-down, security-hardened system that's good if you need absolutely maximal security (e.g. journalists, activists, folks targeted by state actors). LineageOS is a more of an open system for tinkerers who want to play outside Google's walled garden.
You can have root to control your own device on Lineage, but not Graphene.
I believe you can root GrapheneOS. It just breaks the security model, so it's not recommended to do so.
Ah, you're right: https://github.com/schnatterer/rooted-graphene
I stand corrected. Still, as you say, less point in it since it breaks their security model.
> 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
Honestly don't care for the idea of a system secured from its owner. If I wanted to use iOS, I would.
> Honestly don't care for the idea of a system secured from its owner
It's not. It's making your data secure more secure from attackers.
Not having root prevents me from taking proper backups that include app data, it prevents me from using Aegis to import TOTP codes from Authy. I get that on some abstract level it is more "secure" from any malicious software that might find its way onto the device, but the practical upshot is largely obstructing the user from using the system.
Have you ever had to work on a locked-down machine at an office? I don't need Google or Graphene to play IT department for me.
> Not having root prevents me from taking proper backups that include app data
You can handle this better without root. GrapheneOS includes SeedVault per default for example.
> Have you ever had to work on a locked-down machine at an office?
Fortunately I'm the admin at work :)
> I don't need Google or Graphene to play IT department for me.
GrapheneOS is security+privacy first and "enabling root" compromises on this. Thats why its not recommended.
As I'm sure you're aware, SeedVault won't backup app data if the app authors have opted out of it. Again, this is an example of a system serving masters other than the device's owner.
It's not really locked down. You can toggle or enable some of the more activist-orientated features. The only limitation I'm aware of is that some apps requiring the strongest Play Integrity setting (ChatGPT, some banks, very few airline apps) just won't work on GrapheneOS.
Graphene OS provides advanced security capabilities and a thorough defense-in-depth approach including a hardened supply chain. GOS aims to provide mechanisms to protect against 0day attacks. For example Celebrite can not open up GOS. GOS relys on hardware support provided by Pixels. Graphene OS works on getting their developments upstream.
For a list of security features see here [0].
[0] https://grapheneos.org/features
Here is a good comparison among the major open source android distributions
https://eylenburg.github.io/android_comparison.htm
I notice my battery life is much better switching to graphine from the stock google rom.
Yes, but keep in mind individual apps like Signal need to run in the background at all times if you want to receive timely notifications on Graphene, because they cannot rely on the Google backend for that. If you have enough such apps, you may well find that battery life is shorter than on the stock OS.
https://unifiedpush.org/ fixes this for a number of apps. Self-hostable.
Battery life is still better than stock in my case, and it's just as reliable as sandboxed Play. Highly recommend.
This is true if you opt not to install Google Play Services.
Good point, I chose not to on my main "Owner" profile to be fully Google-free. I have the sandboxed Play Services on a separate profile I hardly ever use for testing purposes.
For Google Pixel 6-9 phones only.
https://grapheneos.org/faq#device-support
The problem with custom android ROM is that the kernel is built with proprietary drivers, and porting them to other custom android is really hard
GrapheneOS doesn't have any proprietary kernel drivers. There aren't any for the supported devices. Firmware and a subset of userspace driver libraries such as the Mali GPU driver library are what's proprietary.
Graphene has really caught my eye in the last several months, but unfortunately I couldn't find a good deal for Pixel phones (>128GB storage), used or new. That's the biggest bottleneck for adoption it seems. I just finally switched from an S10E to a S25Ultra (black friday deal brought down to $820), but not being able to use Graphene in the future hurts a bit for sure.
>Graphene has really caught my eye in the last several months, but unfortunately I couldn't find a good deal for Pixel phones (>128GB storage), used or new. [...] I just finally switched from an S10E to a S25Ultra (black friday deal brought down to $820),
There are plenty of deals for pixels under $820: https://slickdeals.net/search?q=pixel&searcharea=deals&searc...
Goodness, friend, where were you looking?
A used 256GB Pixel 8 in good condition is $320. https://swappa.com/listings/google-pixel-8?carrier=unlocked&...
One caveat--you have to be certain that you get a Pixel with an unlocked bootloader. There are a lot of Pixels (mostly sold by Verizon) that are unlocked for use with any carrier, but whose bootloaders remain locked. If you have one of these ex-Verizon phones, there is no way as of now to unlock the bootloader.
This is true, and important. Thanks for the reminder.
The list linked above (and the price tag deduced from it) is restricted to unlocked phones only for this reason.
There's no way to easily tell that those phones have unlocked bootloaders, though. Ex-Verizon phones may be completely carrier unlocked, will work on any network, and still have locked bootloaders. This isn't an issue for anyone running stock Android, but will restrict those phones from being used to run GrapheneOS.
Just wait for the new OEM to drop their phones with GrapheneOS support. Pixel hardware is garbage tier.
There are millions if not billions of older devices. What we need is an OS that support those.
That would become a meaningless effort security wise as time goes on. The drivers and firmware will become outdated. OS updates are necessary but not sufficient. I get the e-waste / enviromental argument, and I think its very warranted to criticize OEMs for not providing long support times in the past. Apple and Google do this well in recent years, luckily.
This is long needed! a lot of big tech giants, even some authorities are trying to convert mobile phones into a spying gadget.
who is the android oem they are partnering with
Not yet disclosed. We know its a top 10 Android OEM though that cares about security for their future devices!
which pixel model is best for grephene? I strongly prefer long battery life.
will other phones be supported? why only pixel?
The OS is not very relevant to the Pixel. Compare the Pixels you like that are new (GrapheneOS drops support as models become older flagships, I think for security reasons) and get that one. IIRC, currently only Pixel is allowed, because the bootloader can be opened without rooting the device.
https://grapheneos.org/faq#device-support
Unrelated to bootloader or rooting. Pixels are the only phones that adhere to the device requirements that are listed in the FAQ.
https://grapheneos.org/faq#future-devices
https://grapheneos.org/faq#recommended-devices
damn, an upgrade path from my pixel 5.
AI can't work if the OS isn't secure... lol... I'm doomed.
Is this supposed to be a joke? The best security of GrapheneOS is useless to people who don't own Don't-be-evil-hardware.
It is sadly not a joke. Its sad that OEMs outside Google and Apple currently dont make hardware and firmware with reasonable security.
Samsung Androids are not safe? Big surprise there! /s
Given what they choose to ship with their phones in some regions, id say that Samsung absolutely doesn't care about the security of their customers of they can get away with it.
[flagged]
Hacker News Guidelines [1]:
> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.
> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
[1] https://news.ycombinator.com/newsguidelines.html
I won't be silent to the obvious honeypotting and mob tactics to silence people around here.
Apparently I'm a downvote bot, a honeypot and member of a mob. My life is much more exciting than I realized!
Your repeated unsubstantiated claims about GrapheneOS just don't ring true with my experience as a user across multiple devices for years. It is an excellent AOSP fork, and has numerous security and privacy enhancements. Every time I've asked you to explain your position, you fall back on, "do your own research." I've done plenty and it's why I switched to GrapheneOS and remain on it.
LineageOS is great for its purpose: supporting a long tail of legacy devices. But as a result it is less secure than stock AOSP. Switching a recent Pixel from GrapheneOS to LineageOS is a baffling proposal for all but the tiniest of edge cases.
Then don't be. Go email the mods.
> Lest alone to use a distro with opaque financing sources that fully endorses government developed/sponsored platforms such as Signal and Tor.
So you're against Signal, Tor, and Graphene, and suggest to instead use.. Lineage?
Don't get me wrong, I love Lineage, it was my first custom ROM, but this seems a little tinfoil
It's inaccurate that GrapheneOS fully endorses Signal and Tor. The GrapheneOS founder was blocked by Moxie (when they were still leading the project) for criticising their approach. They have also warned countless times about the limitations and weaknesses of Tor.
What is your suggestion then, genius?
> Please consider saner options such as LineageOS or Replicant which support dozens and dozens of different device types.
... maybe, but it also drops support pretty fast, and not supported on most phones :-(
It supports devices just as long as the OEM does, which for modern Pixels is now 7 years, which is more than what Apple advertises for the iPhone. Considering people upgrade phones every 2 or 3 years, this is over double the amount of time of support than one would use the phone for. I disagree the support is for a short period of time.
An important motivation for a FOSS OS for phones is not having to buy a new phone just to have up-to-date software.
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.
Reducing waste is very important, but I think this is something you need to take up with the Android OEMs. GrapheneOS can't really do anything about the fact that Android OEMs stop supporting the device and allow vulnerabilities to go unaddressed. For context in this situation, GrapheneOS is also trying to provide a best-in-class privacy/security experience for people. There were other projects that are/were dedicated to supporting abandoned hardware.
A connected world full of devices with excessively vulnerable hardware & software is also something GrapheneOS are desperate to avoid.
Pixel's design makes a good candidate for GrapheneOS or a secure OS in general.
The baseband hardware is not integrated the same way like other phones are.
I don't think that is a consideration for the project. Their OEM partnership also includes supporting a current generation Snapdragon SoC which seems to feature an integrated modem.
>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.
from https://grapheneos.org/faq#baseband-isolation
i like graphite its nice and blcack and conductive