
Tweaking user-hostile OSes into user-friendly ones is impressive, but not sustainable. Even worse, it slowing us down from leaving Android entirely.
Look at the AdBlocker crackdown of Google Chrome. Every single chrome-fork has shut down MV2 extensions, even Brave is about to do it, because it is impossible to maintain features that complex on a browser that Google spends >$1B/year to develop.
Same story for /e/ and GrapheneOS, the day Google pulls the plug on source code releases, god knows how long they will last. We should focus our efforts on truly open platforms.
>Even worse, it slowing us down from leaving Android entirely.
There are zero OSes that are 1/ open source 2/ appropriate for phones 3/ with good hardware support. There's absolutely nothing. Running Ubuntu Touch isn't a viable option. Neither is postmarket, librem, tizen, they're all terrible. Security wise, for something as critically important in our lives as a smartphone, I am also not trusting any new pet project that won't be stable for 10 years.
Sure, you might be a poweruser that doesn't care about your phone burning its battery in your pocket after 1 hour because you know how to SSH on it from your watch and put it in sleep, but that's not a viable option. Leaving Android is suicide. A large part of its critical underpinnings are already into the kernel anyways, just disabled. (although a distro running binder could be a fun project). APIs are reverse engineerable generally speaking, except for the server part of play services. But then, if your issue is "my bank won't let me access their app without play services attesting me", I have great news, you won't even have an app for it on your new OS anyways, so it will not work by default. There's already not enough people working on GrapheneOS _or_ on mainstream linux OSes, what makes you think the sitation won't be ten times worse for your custom made mobile OS ?
>We should focus our efforts on truly open platforms.
Android is one, and that can never be taken away. Google pulls the plug ? cool, you're stuck on Android 17, which is centuries of work ahead of literally anything else in the open source community. Hell, for all the shit that Google is doing, they're still constrained by having to work with other vendors: the system privileged notification receiver is swappable at build time, the recent app signing/verification system also is, because Samsung wouldn't let them control it all.
I do agree, mobile OSS OSes are rough. My point is that we should help them instead of helping Google's toxic relationship. It happened with Chrome/Blink, and everyone already forgot that lesson.
About hard-forking Android, no one was brave enough (pun intended) to do that for Chrome, considering the insane complexity and engineering costs (>$1B/y). (Only Apple was able to affort it with Webkit/Safari, but they are in the ad business too.)
> Google pulls the plug ? cool, you're stuck on Android 17
And you're stuck on the current hardware generation. Pretty much the only reason why Android sucks less than other mobile OSes is that hardware vendors have a pressing reason to make it work. The further the Google Android kernel diverges from its last-open version, the harder it will become to backport drivers -- and that's assuming that hardware vendors even bother to comply with the GPL when Google decides not to.
The whole notion of smartphones is designed for intrusive user surveillance, from the regulatory side to the hardware itself to the software designed for it.
We need tablet computers that don't have hostile hardware like cameras and mics and sensor suites that can be remotely controlled, under proprietary firmware, completely out of owner control.
We need radio hardware and software that is entirely under owner control, with protocols and standards based connection controls; the notion that spectrum and cellular make network connectivity magically necessary to put under the draconian gatekeeping and surveillance of cellular carriers is flaming dumpster garbage.
The carriers are a primary threat vector. The hardware is a primary threat vector. The software is a primary threat vector.
There is absolutely no way to fix the current cellular phone security status quo, every single facet is designed to be leaky and allow "good guys" backdoored access "for the right reasons" and so on, whether it's "user experience telemetry" or "we have a warrant".
Running bog standard linux with sensible security defaults and a good softphone over an internet connection would be fine. There's nothing magical about phones or UX or wtfever this month's marketing rationalization is.
Handheld tablet computers with optional hardware, or even modular hardware, are going to be the future. The current paradigm of parasitic cellular carriers, invasive governmental regulatory bodies working on behalf of all sorts of corrupt interests, and complicit hardware manufacturers are 100% all in on milking consumers for every last unearned penny or intercepted PII they can get their grubby hands on.
> you're stuck on Android 17, which is centuries of work ahead of literally anything else in the open source community.
It's far ahead, but at the same time, I think we shouldn't over-emphasise how much. Functionality at the beginning of a project's lifetime is way more important than incremental improvements (or just changes) made later, and thus while much more effort has been invested into Android, new projects primarily need to catch up when it comes to e.g. phone call support and stability, and won't have to redo a lot of the effort of e.g. implementing Material You 3 or whatever.
Which is to say that we're still years out from a viable competitor, but at the same time, there could be one five years from now, which is also not that long.
> There are zero OSes that are 1/ open source 2/ appropriate for phones 3/ with good hardware support. There's absolutely nothing
Sailfish?
FLX1s running FurioOS, a Debian variant. [0]
World would be better off if they De-Google and De-Apple! You have to pay me to use Google and Apple!
> Sure, you might be a poweruser that doesn't care about your phone burning its battery in your pocket after 1 hour
Not even the original pinephone has that poor of battery life. Hyperbole doesn't help your argument.
>critically important in our lives
This is the sad part. I've resisted that slippery slope as much as possible. In part because of ideological reasons, and in part for usability reasons. I have large hands and poor eyesight - using a phone for non-trivial tasks is tedious. I think the only thing I encounter from time to time that requires a smartphone is paying for parking. Everything else I do from a desktop, or don't do at all (doom-scrolling etc.)
I wish society would resist the smartphonification of everything for no reason. A lot of it is marketing- and surveillance-driven.
What about Sailfish OS? I heard good things about it, but didn't dare switch... yet. Does anyone have some 1st hand experience?
> you're stuck on Android 17, which is centuries of work ahead of literally anything else in the open source community
Honestly if this happens, look to China to maintain Android going forward and add new parallel implementations of Android 18+.
Right now almost all of China runs on various forks of AOSP; every phone manufacturer in China has their own AOSP fork (Xiaomi: MIUI/HyperOS, Huawei, HarmonyOS, TCL: TCLUI, etc.). Apps in China are distributed both as .apk files as well as through a bunch of different domestic app stores. They are compatible with all of these Android forks. These apps are also designed to be compatible with Google Android for Chinese folks overseas.
TBH China is much, much closer to "decentralized" development of Android than the Google-centric US ecosystem.
Granted most of those AOSP forks in China also often have spyware of sorts, but at least there are multiple active forks and a healthy app ecosystem working on all the forks.
Imagine if Boot2Gecko / FirefoxOS had someone kept going, I wonder if I'd have evolved sufficiently enough to be commercially viable?
> Tweaking user-hostile OSes into user-friendly ones is impressive, but not sustainable. Even worse, it slowing us down from leaving Android entirely.
Not sustainable as opposed to what, exactly? Developing and maintaining a completely different mobile operating system? Focusing on truly open platforms sound nice in theory, but completely falls apart the moment you consider what people want to do with their phones compared to the developing resources available.
> Every single chrome-fork has shut down MV2 extensions, even Brave is about to do it
That's just wrong, there are other forks that still support MV2 extensions right now, and at least brave has no plans of shutting down MV2 extensions even after Google removes MV2 from upstream completely. It will certainly add maintance effort on brave's side, but they already patch a million other things that upstream doesn't support.
(Reposting my comment from below)
Brave said they'll try to maintain temporarily limited MV2 support for only 4 specific extensions, but recommend Brave Shields as the go-to adblocker for the future. Google is about to remove most of the MV2 code from the codebase, which will explode the complexity soon.
> Developing and maintaining a completely different mobile operating system?
The cost of writing code has fallen 100x in the past 3 years, and will likely fall 100x further. So actually, yes, thanks to AI it probably actually is reasonable to launch a fully new stack from scratch.
> Not sustainable as opposed to what, exactly? Developing and maintaining a completely different mobile operating system? Focusing on truly open platforms sound nice in theory, but completely falls apart the moment you consider what people want to do with their phones compared to the developing resources available.
Multiple open source desktop/laptop operating systems are maintained.
I appreciate that there are people out there working on stuff like /e/OS, but the number one question I have when I learn about a mobile OS that isn't iOS or "Googled" Android is: will the banking and payment apps I need to operate in the modern world run on this OS?
A lot of people don't think this way because they haven't had any problems. But then one day it happens to you and you realize, ok, this is the one thing that matters - you're in a cashless store and the only way you can pay for your meal is to use Approved Apple or Approved Google operating systems.
Where I live, the app my electricity utility provides for viewing and paying my account DISABLES ITSELF FOREVER if you so much as enable USB debugging on your phone (even after you've disabled it again).
To their credit Graphene maintains a global database of which of these apps work and don't. They're the only ones I know of so a thousand upvotes to Graphene OS.
But for my banks, the records in that database are grim. They won't run on Graphene, and they don't respond to reports about it.
One of my banks just discontinued its web UI because "people don't use it anymore, they use the app only."
This is how they're going to get us, folks. This is how we're going to lose it all. Writing code alone will not solve this. It will require some kind of collective action to defend our liberties. Some parts of the world are already lost. So this situation will likely come to a jurisdiction near you eventually: to make a transaction you will need permission from Google, Apple, Visa, Mastercard, or it won't happen. Then that four company list will start to shrink.
> the app my electricity utility provides for viewing and paying my account DISABLES ITSELF FOREVER if you so much as enable USB debugging on your phone (even after you've disabled it again).
These are self-inflicted problems by these apps. Nothing to do with the OS. These apps simply don't work. Complain to the companies that push these broken apps to you.
Would you buy a microwave oven that kills itself if you play the wrong kind of music in your kitchen?
I promise your electric company accepts payments outside of an app on your phone. I further promise that other banks are available that don't have terrible apps. These problems are way more surmountable than you're painting them here.
> Tweaking user-hostile OSes into user-friendly ones is impressive, but not sustainable. Even worse, it slowing us down from leaving Android entirely.
I would say we need both a sustainable free mobile OS in the long term, and a "less worse Android" today in the meantime.
Initiatives like FairPhone paying someone to upstream device support in the mainline kernel / postmarketOS are interesting for both approaches at the same time (but extra effort would be needed, the FairPhone 5 almost working under postmarketOS [1] is kinda irritating, I hope it reaches full support before Lineage OS stops being updated for this device).
Ignoring hardware support, Linux mobile OSes are quite usable now.
Hardware support is the next step, and only then we can imagine the proprietary apps we are forced to use to work there (though Waydroid provides some answer to this as well).
Another way of helping the cause would be, I suppose, lobbying for laws that forbid the dependency on an stock Google or Apple mobile OS. Or, maybe we can dream a bit, mandatory open source releases for those apps and standard APIs.
[1] https://wiki.postmarketos.org/wiki/Fairphone_5_(fairphone-fp...
> that Google spends >$1B/year to develop.
Let's see...
https://www.techpolicy.press/the-true-cost-of-browser-innova...
* Most of the personnel involved in developing web technologies are engineers, but they also include product managers, sales, marketing, legal, customer support, and other functions.
* Given the complexity of Chrome and web technologies, the engineering teams skew towards higher levels of seniority. Assume that Staff Software Engineer is the most common engineering level represented across the web technologies teams, which is towards the more senior end of Google’s software engineering job ladder.
* The average base salary for Google employees working on web technologies is $240k and the average annual take-home pay is $500k, including salary, bonuses, and stock payments. These estimates are close to the current average base salary and take-home pay for Google Staff Software Engineers listed on industry salary data sites.
* Google has approximately 2000 staff working on web technologies.
Using the above assumptions, the estimated personnel cost for web technologies is 2000 * $596k = $1.2B. Of course there are additional costs associated with these businesses. Based on this sketch, it seems fair to assume that Google spends at least $1-2B annually on Chrome, Chromium, and the evolution of the web platform.
>> that Google spends >$1B/year to develop.
Isn't this downright crazy when you think about it? Seems like we need to start from scratch. Create a minimal bytecode (like webasm or whatever) that writes to a virtual frame-buffer of sorts, and has keyboard/mouse inputs. Then content is distributed as compiled byte-code apps. All the fancy stuff you want in your app has to be provided by the app creator, and not essentially using the browser as a library.
I don't get what's so user-hostile about Android. Everything negative about the ecosystem is mostly Google Play and the legacy of every OEM forking Android for the better part of a decade. Sure, file pickers are inconsistent, filesystem is chaotic but it's performing quite well on most hardware, runs on phones, TVs, laptops, tablets and mini PCs and AOSP doesn't contain any hooks for Google to siphon off data. GrapheneOS isn't so much undoing evil Google stuff but extending upon their work and improving memory protection and adds security features that can be easily toggled based on assumed threat models of the user.
Google's ownership of Android is definitely headed towards user hostility though, I'm not arguing against that. But just the source that GrapheneOS is based off of doesn't contain too much stuff that shouldn't be there, to my knowledge.
> Even worse, it slowing us down from leaving Android entirely.
I appreciate the vibes where this is coming from, but does it really? I think that assumes that everyone that works on this would work on a true open source OS otherwise, and that if they did, that would result in us breaking free from Android where we otherwise wouldn't. I'm not confident about either of those assumptions.
Meanwhile I'll keep complaining to orgs that don't allow me to work through their website, and tell them that their app won't work on my phone.
> Every single chrome-fork has shut down MV2 extensions, even Brave is about to do it
Source?
Brave said they'll try to maintain limited support for MV2 for only 4 specific extensions, but recommend Brave Shields as the go-to adblocker for the future. Google is about to remove most of the MV2 code from the codebase, which will explode the complexity soon.
At this point it is very difficult to develop truly open OSs for mobiles because so much of the hardware depends on undocumented binary blobs.
As I see it, the only options is to go for a drastically simpler design of the hardware - which means, we have to tone down our expectations especially when it comes to things like gaming performance, camera performance etc.
Over time even these things can be improved but it is going to take a few years.
In the meantime, I am not sure many people are willing to make those compromises to have a truly open hardware and OS though.
I wouldn't call Android user hostile. What makes most Android phones user hostile is Google Play Services.
I can call Android user hostile. Most Banks and gov apps require play services nowadays, and Google is about to ban app installation outside of their store. Cherry on top, the play store is mostly adware junk. My parents phones are full of adware, bloatware, notification spam, it's almost worse than windows 11.
Oh, is this the deal with GrapheneOS too? Damn, I was excited about the Moto GrapheneOS collaboration.
So far its working pretty great. Very happy with GrapheneOS. And currently Android AOSP source code is still regularly released. If that changes it becomes a problem then.
It's not sustainable but it is better than the alternative. For the moment there is no alternative for a phone os that will start from zero
There are multiple Linux shells that work on mobile today… They could become usable with some investment.
The main issue is Android apps that require certified devices, which would also be a problem for truly stripped down Android.
> Every single chrome-fork has shut down MV2 extensions
Ungoogled chromium still supports MV2, and uBlock origin extension works fine.
The day AOSP sources aren't relased, Google will just lose control over Android and it will be managed by a Chinese consortium instead.
8 of the 10 top smartphone manufacturers are Chinese, there's no going back from that.
>Tweaking user-hostile OSes into user-friendly ones is impressive, but not sustainable. Even worse, it slowing us down from leaving Android entirely.
To what?
Helium still allows MV2
The irony of this is that when using Firefox to browse to /e/OS url to check for compatible devices:
https://e.foundation/installer/
I get a pop-up telling me that my browser is not compatible, and I should use Edge, Opera or Chrome. See [1]
Yes fortunately we have browser alternatives.
But on mobile, my bank and my government force me to use the Android/iOS duopoly.
Chrome is just an example. Google stopped pretending Android is a general purpose OS and started cracking down on what is possible without Google’s approval. See developer verification, everything within Google services, etc.
>We should focus our efforts on truly open platforms.
De-Googled Android was/is a truly open platform. Same result. You're pointing out maintenance issues.
How many developers do we have to maintain this or any other platform without pay? That problem applies to a de-Googled fork of Android, or a complete bottom up build of a new platform.
The benefit of using an Android fork is the labor savings on what's already built.
Maintenance is not going away just because we build a new OS.
> even Brave is about to do it
Why anyone ever gave that browser a second of trust is beyond be. The damn thing was built on hijacking ad revenue into some imaginary IOU crypto thing, and built by a creep.
I think this is a false dichotomy.
Basically what you’re implying is that all the people working on Android derivatives like Lineage, Graphene, and /e/ coming together and working instead on a fully open source OS like a Linux mobile distribution would result in better outcomes and actually get us closer to a daily driveable open source environment phone operating system.
That’s analogous to saying that an automotive tuning shop that puts turbochargers and body kits on Toyota Corollas shouldn’t waste their time, and they should instead design and mass produce their own sports car.
The level of effort difference between AOSP derivatives and a fully open source OS is massive.
The day Google pulls the plug on source code releases is the day the open source community forks the last release...
Not sure what this fatalism is about but it's a hysterical take.
Yes and that seems not very realistic considering they would need to replace the Linux kernel because of the GPLv2 license not allowing that.
It would be a giant undertaking akin to rebuilding the whole OS from scratch considering they have build thousands of hard and software dependencies over two decades. Reminds me of "just rebuild windows" lol
"Tweaking user-hostile OSes into user-friendly ones is impressive, but not sustainable."
Not sure about the first claim but the second is obvious. Yet peculiarly ignored
The OS literally comes from Google. As such, the term "de-Googled" is quite strange. Another recent HN front page item about the other project mentioned recently used the phrase "break free from Google" and currently only runs on Google hardware
AFAICT, the most significant issue with Android is "phoning home". Unwanted data transfer to third party. This is embedded in the OS. Google is the third party. Google operates as if it should be trusted as if it was a first party (why)
IMO, a user-friendly (cf. user-hostile) mobile OS would be one that does not phone home. But at times it seems like these projects are OK with the idea of phoning home to third party, as long as it isn't Google
Users will never have a mobile OS that does everything Android does, with the same polish, that isn't attached to a trillion dollar corporation. That "goal" results in projects where the majority of the Google-sourced code is unchanged instead of user-controlled source code
It isn't _that_ difficult to stop Android, i.e., system, pre-installed and user-installed "apps", from successfully phoning home (cf. trying to phone home) over WiFi. For example, this can be done by changing gateway and DNS settings. If the user installs an app that can forward ports nd use the the built-in VPN support, successfully phoning home over cellular data can be stopped, too
But a corporate-sourced OS like Android can change at any time for any reason. It changes often. Users have no control
I see some HN comments are starting to acknowledge the idea that control can be more important than performance. IMO, it can also be more important than "features"
Only if a user can embrace this idea can he begin to truly "break free" from the trillion dollar surveillance advertising company. Otherwise, sacrificing control for "performance", "features", etc., will always leave the user tethered to the company
With the corportate-sourced OS users have no control over performance, features, etc. anyway. The corporation controls them
Until there is a user-controlled, open source mobile OS like other form factors (HN commenters often claim this is not going to happen for good reasons), then, IMHO, "mobile" sucks
Generally, we all have to use mobile, as least for some purposes, e.g., it's replaced residential landlines, paper maps, and so on. But none of this means it is a good choice for for so-called "general purpose computing". It's not a computer the user can control
Chrome did not crack down on adblockers in Chrome. In fact the chromium team worked together with adblockers on mv3.
>it is impossible to maintain features that complex on a browser
While Chromium is complex, it is modularized which does make it possible for teams to maintain features.
[dead]
> We should focus our efforts on truly open platforms.
But currently AOSP is very much open. That's also what the GrapheneOS devs say and why they want to continue using Android. Until it becomes clear that they will completely stop releasing the source code under a free software license i dont see why one should not use Android.
AOSP dev went private, and Google is slower and slower at releasing the source, now twice a year. Worse, many stock apps like the Dialer and Gallery went closed-source years ago.
But the source isn't the point, it's the governance. Just like Chrome, having the source is not enough to guarantee an open platform. Sure you can disable telemetry flags. But you cannot afford to maintain an important feature Google wants to remove, like MV2.
https://arstechnica.com/gadgets/2025/03/google-makes-android... https://www.androidauthority.com/android-16-qpr1-source-code...
Extensions prior to MV3 were notoriously insecure and granted extension developers a very wide attack surface. Assuming that Google only has a sinister reason to switch to a better standard in an ecosystem riddled with ill-intentioned actors is a bit too cynical.
> very wide attack surface.
Do you have details of specific realistic attacks that were possible under MV2 and now impossible under MV3?
No, it's not. They could easily have solved the problems without introducing changes to cripple ad blockers, but they decided their investors need some more cash. Actions speak.
Google will only ever push major updates that are neutral or beneficial to their ad revenue. I do not believe they killed MV3 due to ad blockers, but it's the type of proposal that can survive at Google.
The irony of advertising a privacy-enabled de-googled system, and then telling me that my Firefox browser is not support, and that I should use Edge, Opera or Chrome instead....
Browsing:
https://e.foundation/installer/
Reply:
This is related to Firefox unwilling to add support for WebUSB because, I suppose, they believe that a browser is not a general purpose application launcher and the scope of what it can do should be limited. As such, it should not be allowed to e.g. control peripherals like the USB devices.
Which is in my opinion a fairly reasonable take.
But given the current situation, I would assume that the companies providing WebUSB tools like installers would also spend a few moments to create e.g. a Python script that would do the same thing but locally. So that anyone unwilling to use WebUSB within their browser can have a vetted and transparent way to get the same thing done.
> Firefox unwilling to add support for WebUSB because, I suppose, they believe that a browser is not a general purpose application launcher
No, it's security concern.
And, to counter the arguments that "the site tells you that you need WebUSB support": you get to the https://e.foundation/installer/ when you click "Check device compatibility" on the main page. Personally, I'd expect either a check that works in any browser or a simple compatible device list. Why would I need a special browser just to check if I can use this OS?
This is especially strange considering they have the list of supported devices in their docs https://doc.e.foundation/devices
So I think the issue is that the button on the main page is poorly named
What I currently see:
main page -> download and try! -> browse supported devices
lands on https://doc.e.foundation/devices which is a list of models, while
main page -> download and try! -> check device compatibility
lands on https://e.foundation/installer/ the chromium-only webusb page. It could be a better page; instead of showing a scary "navigator not suppored" modal demanding you install a particular browser, it could say the automated compatibility tester requires one of these browsers and your phone plugged in with USB, otherwise here's the device finder page
Hmmm, It seems to require the WebUSB API: https://caniuse.com/?search=webusb
If the site can detect that it can't use WebUSB, it can give you instructions on how to download and flash the mobile OS, not tell you to fuck off.
Same here, they advertise with the duckduckgo browser app on the above page, but it's not supported checking compatibility.
e/OS is not degoogled, only some of the functionality has been rewritten in microG (eg not implementing security checks but instead spoofing them), but still uses Google play sdk and libraries.
Additionally it runs in the privileged mode, so any exploit on that, well, means back luck.
same for grapheneos. only difference maybe that you can choose to also manually install it without WebUSB
There's absolutely no reason to use /e/ when GrapheneOS exists.
But GrapheneOS doesn't exist. It works only on a few devices created by Google, so their claim of being degoogled is a bit funny.
Google's hardware is just hardware. It is not locked down like the hardware of many other manufacturers. Moreover, it's the only such hardware which also allows you, the user, to lock it down for your own security. GrapheneOS is not just focused around avoiding Google, it's more accurately focused around security and user choice.
The goal is to give you the option to avoid needing to rely on Google's spying or services while not having to compromise on security.
None of these other solutions regularly get included in Celebrite's documentation as being an explicit benchmark of their software's ability to break into phones. And that's almost certainly due to the fact that unless you leverage hardware security features like what GrapheneOS (and stock Android on a Pixel, and iOS on an iPhone) utilises, you have no chance of going against any actual adversaries.
And I'm not just talking about state actors here, even drive-by opportunistic attacks are likelier on a random other phone running some other Android build.
So yeah, you are running Google hardware, that doesn't make you "googled". It's just a sad reflection on the reality of the hardware landscape. If you want the same security as what GrapheneOS offers, you will currently need to use a Pixel.
I'd be curious to see what comes out of their Motorola partnership though.
I must agree, you are right, GOS is only on Pixel phones.
But we have to keep in mind that /e/ has a lot of problems, the only one solved is sending data to Google. The security aspect of the OS is problematic and some key elements of a privacy seem questioning (AI integration, commercial collaborations, ...).
Fix: IA => AI typo and various English errors.
/e/OS is Android, meaning it's still critically dependent on goodwill of Google to continue releasing their work as part of AOSP.
So if you're trying to be a silly purist, then /e/OS doesn't fit either. If you're not, getting a Pixel will significantly enhance your safety since they're better supported for security patches and better designed in hardware when it comes to security.
Literally announced today partnership with Motorola to bring it to their devices.
GOS is degoogled in all the ways that I care about - it's about the data they can gather. Among all the smartphone options that I consider usable day to day (leaving only Android and iOS at the moment), GOS is the most private and secure.
> their claim of being degoogled is a bit funny.
I don't think they use this term anywhere.
It also now works on Motorola devices, it's on my HN feed literally right above this post.
The post about Graphene partnering with Motorola is right about this one, currently, (Lenovo bought Motorola from Google in 2014.), so that point will no longer be valid as soon as they ship something.
As someone who switched from FP4 with /e/OS to GrapheneOS - absolutely not true.
My reason for switching was a bug where the phone calls didn't display the caller number. So I switched to GOS in hope it would be better... and it is, but not in all areas. For example their insistence on not supporting MicroG leads to poor UX, because let's face it, you can't trust Google services, even sandboxed, to not syphon tons of data into the cloud. MicroG was easybto use for privacy. They also seem to be very opinionated about (not) using a firewall for privacy, like NetGuard, instead recommending some weird alternatives like DNS firewalls. And don't get me started on their icons - I don't mind ugly-ish icons, but they are taking the ugliness to a whole new level.
GrapheneOS is not a bad OS, but it is very opinionated, and they (heavily) prioritize security over privacy. When I turn FP4 on, I still like it way better than GOS. Still, I like seeing who is calling, so I'm not going back... Ymmv.
That's strange, I have exactly the same combo and I can see the caller numbers just fine...
Doesn't seem a universal bug.
I am not a project member so I cannot speak for GrapheneOS, but maybe I can help clear up some misunderstandings.
>insistence on not supporting MicroG leads to poor UX,
The problem they are trying to solve is apps not working without the presence of Google Mobile Services or Google Play. They don't want to compromise by having a component with high privileges integrated in their image that involves security issues like signature spoofing.
MicroG will send less data to Google partly because it is simply an incomplete implementation of the features offered by GMS (sanboxed-google-play appp compatibility is quite a bit higher), partly because the access is more granular or there are choices offered for services like location (GrapheneOS provides non-Google location services and community support on only installing and enabling the parts you need for specific app features to work). UX is not adversely affected, but if you want to use a privileged app bypassing security checks and sending data to Google anyway then you have the freedom to compile microG with it integrated if you would like.
>They also seem to be very opinionated about (not) using a firewall for privacy, like NetGuard, instead recommending some weird alternatives like DNS firewalls
GrapheneOS tries to implement or end encourage sustainable approaches to privacy and security, and this partially means approaches that don't break if the adversary knows what you are doing.
Egress/outbound traffic filtering is fundamentally unworkable. Apps do not have to connect to known privacy a invasive third party domains to violate your privacy or expose your data to extra parties, they can simply send anything they want to their own servers and do anything they like with the data. From my understanding this is why GrapheneOS do not want to encourage the approach of blocking apps from connecting to certain domains/addresses.
Instead they tackle the problem at its source by providing a direct AND indirect network access toggle which cuts off an apps access to the outernet without letting the app know (pretends the network is down). This makes it non trivial for apps to exfiltrate data and as a side effect can provide benefits like data conservation (for capped plans).
>instead recommending some weird alternatives like DNS firewalls.
DNS based solutions are offered (not promoted) if you want more control over your DNS query resolvers or you want to improve your quality of experience by blocking advertisements and malvertising domains.
>they (heavily) prioritize security over privacy.
Can you point out another OS project with real privacy features like a network permission, sensors data access permission, contact access scopes, storage access scopes, per connection MAC randomisation and so on? https://eylenburg.github.io/android_comparison.htm They have even more plans for privacy like location scopes, anti-fingerprinting for Vanadium browser and maybe AnonymisedDNSCrypt/Oblivious DNS and probably more they haven't mentioned. If you suggest some more on their issue tracker they may get back to it when they have the resources.
Not everything have to be perfect.
For some user, /e/ is more approachable (Friendly and colorful UI)
I could not get my mother to use GrapheneOS, /e/ is a lot simpler.
Still miles better than to use a Default ROM from most OEM.
Exactly!
If you can use GrapheneOS, good for you but what /e/OS offers is:
- Usable Android with your usual Android app (banking, etc) - No data sent to Google by default - Easier interface with nearly no bloatware - Available easily on many smartphones, including older ones - Extending the life of some smartphones
The price to pay is:
- Some Murena cloud bloatware - Android security patches are sometimes delayed - Security is not on par with GrapheneOS
If your main concern is protecting your privacy from Google and extending the life of your smartphone without breaking a sweat, /e/OS is probably the best option.
If your main concern is protecting against state actors attacks or very specific threats, then GrapheneOS might be better.
/e/OS works really great for non-techie users. I’ve done it in my family.
I find it interesting that there are so many comments that are saying "Don't use this one use this one it's better!"
But what I think a lot of people are missing is what you exactly just touched on. We have options! That's a good thing. Yeah, some options are not as good as others if you wanna optimize for X. Then don't use that option! Use the option that works for you.
To me, the fact that alternatives exist on varying spectra of "degoogle-fication" is a win in my book. The fact that we're able to talk about and recommend so many alternatives is a good thing.
Same story. Also with my mother :D
There absolutely is when your concern is not only moving away from Google but also using sustainable hardware like Fairphone, which GrapheneOS doesn't support afaik.
Even on non-pixel devices, unless you really want to use the /e/ "ecosystem, there are probably better options like LineageOS for microG iodéOS.
(/e/ used to be heavily based on an outdated version of LineageOS for microG. I'm not sure what the current state is after I settled on second-hand pixel with graphene)
Unless you own some obscure phone that is not supported by GOS, Calyx or Iode, but is by /e/... Not sure how many of those exist...
is "/e/ supports my phone while graphene only supports google pixels" not a good reason?
And even if GOS doesn't support your device (due to minimum security requirements) why not use upstream LineageOS?