Regulation should prevent Google from subsidising manufacturers to use Android. Arguably the recent antitrust legislation [2] applies in this case because they're effectively paying manufacturers to place that horrendous and impossible to remove search bar on the home screen.
[1] https://www.androidauthority.com/graphene-os-major-android-o... [2] https://www.justice.gov/opa/pr/department-justice-wins-signi...
I get that this is in the name of security hardening. And you can make a build that has limited root access and is officially supported. But GrapheneOS isn't the end-all solution to computing freedom. Although hopefully on those devices you will be able to install custom OSes (root capable build of Graphene or otherwise).
Implementing a more flexible permission model + sandbox would probably involve too much work for them.
Hopefully AVF might make things a little better if we'd be able to run Android VMs on Android - so you'd be able to run a rooted VM inside GrapheneOS.. but this depends on Google keeping Android open source, yet QPR1 was not released.
Modifying the official builds by replacing part of the core OS with Magisk and then using that to modify the rest of the OS dynamically is what's not officially supported and strongly discouraged. That doesn't mean there isn't official support for root, which is available in userdebug builds without the same massive negative impact to the security model of the OS.
Is it possible to get some help on this? Posted some messages to the #general and #development channels on Discord (you mentioned in your very helpful comment at https://news.ycombinator.com/item?id=42536302 that's the go-to for support) but am not getting any response. I'd even be happy to make a fat donation or pay for some support here.
Also out of curiosity, have you guys considered providing an official release that is configured this way, perhaps gated behind a giant "Proceed at your own risk" banner? Is your reasoning here influenced by a perception that providing root access without enough friction might weaken your bid for Play Integrity recognition or your chances of individual app developers like banks treating your OS on equally trusted footing as Google's?
GrapheneOS doesn't make any connections to Google or Qualcomm by default, unlike all the other other Android-based systems. https://grapheneos.org/faq#default-connections
See https://eylenburg.github.io/android_comparison.htm
As previously mentioned, GrapheneOS hosts a proxy for the Qualcomm SUPL service. In addition, it removes unique device identifiers from the requests, that would normally be present.
GrapheneOS supports the Pixel tool for provisioning eSIMs, but it's fully sandboxed and doesn't share any data with Google.
Devices built to officially support GrapheneOS MUST include first class support for using an alternate OS that's not the official GrapheneOS, which is part of our requirements at https://grapheneos.org/faq#future-devices. These requirements apply to official GrapheneOS devices in the same way as devices using a Google Mobile Services stock OS. Combined with the OS being open source, that's what gives people the freedom to legally and practically use/make forks of it with arbitrary changes.
Userdebug builds of GrapheneOS are officially supported, although we don't recommend using them on a production device. Setting ro.adb.secure=1 for a userdebug build does preserve most of the security as long as ADB isn't used, but not all of it. It still downgrades security when ADB isn't used since the changes to accommodate having root access and other debug features via ADB have an impact beyond when it's actually used. It doesn't destroy the overall security model in the way people typically integrate root access where a huge portion of the OS has it and it's accessible to apps in a persistent way.
I'm secretly hoping that this will be Framework or Nothing.
You will lose DRM-based apps (e.g. Netflix), Payment apps, and bank apps though.
There are societies today (I live in one) where some businesses are starting to accept payment only through a banking or payment app, no cash, no card, nothing else. And these apps will only function in the very narrow circumstances of "I bought a device which runs software from one of two American tech monopolies and follow all their frequently changing rules for using various software that's unrelated to the payment I need to make." This limitation is mostly in place due to the banks believing it will make things more secure. Security is important, but not important enough that you get to start denying innocent people the ability to make payments or exile them from the banking system because they had some kind of dispute with Apple or Google. Governments need to step in with access mandates here, otherwise this problem WILL come to a jurisdiction near you sooner or later.
The argument that this is actually a security benefit is a farce. It doesn't do anything. If the device is compromised then it's going to capture your password and send it to the attacker without attempting any attestation. So the only time the attestation is attempted is when the device isn't compromised.
It's clearly not about real security. It is about control. You follow the rules and get Google's blessing or no SafetyNet for you. These rules include things like ensuring that the user can't access their own data without the controlling app's permission.
Let me offer another perspective. The OS vendor actually has significant control over your device. They could plant backdoors in different layers of the OS.
Therefore, in their defense, if the OS doesn't come from a trusted source (in the bank's or Google's point of view), your bank's credentials are essentially compromised.
You could argue that there are backdoors either way. They are just controlling which party gets to plant the backdoors, after all.
"Compromised" means that someone has them who will use them for unauthorized activity. When your device is infected with malware because it's running the same version of Android it came with that hasn't received a security update in several years, entering your credentials into that device will cause them to be compromised. When your device has a custom ROM that isn't sending your credentials to anyone it isn't supposed to, they are not compromised.
But the first device passes attestation and the second one doesn't. Moreover, that is the common case -- the version of Android that came with the device is likely to be older and have more vulnerabilities than a custom version installed later. Which means that passing attestation isn't just uncorrelated with uncompromised devices, it's actually anti-correlated with them. Requiring it is forcing users to keep and use the older OS with known vulnerabilities on that device.
The new attestation system Google introduced recently (which I think also more strongly forces hardware-based attestation for phones that support it and is therefore more difficult to bypass) actually does that – the very highest attestation level requires running a security update not older than one year if I remember correctly.
What remains to be seen how much that'll get used in practice – users with rooted phones or custom ROMs are rare enough that a lot of vendors seemingly have no qualms excluding them, whereas users with outdated phones are probably a somewhat more sizeable number.
I managed to get a US refubished Pixel 2 somehow with a fuselocked bootloader here in Ireland. I bought it second hand but I've no idea how it got that way. But I'm suck on the Pixel image and I wanted to use it for ROM testing etc.
The reality is however that if you look at active current projects being able to use digital IDs to access fundamental freedoms like communication without child safety rails in Europe is going to require Apple or Google's permission because politicians like it that way.
You can think things should happen in a way all you like, but they are not going to, because governments have vested interests in the opposite direction.
Yes some banks still allow classic clunky 2FA(sms, card readers, sometimes SIM generators) but it'll all eventually go away in favor of "locked and favored" os unless legislation fights against it.
Fortunately, they backed off and decided to abandon the proposal after massive backlash. But we don't know when we will see a 2.0 version of that.
Other manufacturers do the same, where you have to wait a period of like 45 days before being able to unlock, and then have to ask permission on their website to unlock your bootloader.
wandering the web to find an exploit is way beyond my spare time.
iiuc the OG Verizon Pixel has an unlockable bootloader, but the operating system doesn't let you unlock it, meaning root access should allow unlocking the bootloader.
some devices have a legitimately locked bootloader, which means you're SOL.
> as well as those now using push MFA with their apps for every large purchase.
Our banks use SMS OTP (not required for mobile app) for all operations - I assume otherwise the amount of fraud would be exorbitant.
> Recently I needed to install an app from the UK government to prove my identity via camera to renew my driving license, and that doesn't work in GrapheneOS either. I can do it in person (for now) but there is an extra fee.
Interesting that the government relies on a proprietary, foreign platform.
For example, you can't relock the bootloader on any device except pixels. Why? No reason. Just fuck you, I guess.
That's a huge security hole that they're creating, intentionally.
What's going on is they are hoping that if you do use other software that you get malware or get scammed. They are literally, actually, undermining their own device's security just to send a message.
These people are psychotic.
[0] https://droidian.org/ [1] https://www.notebookcheck.net/Lenovo-ThinkPhone-by-Motorola-...
No contention that Graphene is safe, but categorizing other OSes as "pretty bad when it comes to security" because they don't copy Graphene is a bit of a stretch.
Operating systems lagging far behind on privacy and security patches are definitely quite bad when it comes to security. For example, the official releases of /e/ for the Pixel 7 are still based on Android 13 and do not include any of the Pixel kernel, driver of firmware patches released from October 2023 and later. Eylenburg's table doesn't put much emphasis on this since it's contained within a couple rows which do not adequately communicate how delayed the updates are and how much that matters.
In addition to the official Android and OEM privacy/security patches, there are also major privacy and security improvements in each major Android release. Android also doesn't backport most Moderate and Low severity patches which are no longer given CVE assignments. Most privacy patches are considered Moderate or Low severity if at all. Many privacy improvements also aren't considered to be bug fixes since they're improvements to the intended design of the system. Only bug fixes considered to have a High or Critical severity security impact are backported. The comparison table could cover a bunch of standard Android privacy/security improvements to emphasize the importance of keeping up with the only actual LTS branch.
Interesting position. It is a valid criticism but brings its own problems.
Pixel 7 is a fully supported device with Android 16 QPR1 available for it via the stock OS. /e/ is on Android 13 on the Pixel 7 without the kernel, driver and firmware updates released for it from the Android 14 launch and later. /e/ is a fork of LineageOS with drastically worse privacy and security.
LineageOS rolls back the security model and features a fair bit but does it far less than /e. LineageOS doesn't implement major privacy and security enhancements so a comparison of non-standard improvements in those areas is going to show that. LineageOS lags behind on providing the AOSP and vendor security patches, but far less than /e/.
The table covers the patch delays for both AOSP patches and device patches. It's showing how far behind they are on kernel, driver and firmware patches released for a device, not anything to do with end-of-life devices. Being multiple years behind on those patches for the Pixel 7 on /e/ has nothing to do with supporting an old device as long as possible.
None of the operating systems listed in the comparison include app accessible root access. Giving unconstrained root access to a huge portion of the OS including the application layer including a GUI application for managing firewall rules is not a good approach to implementing it. Managing firewall rules is entirely possible to implement while following the principle of least privilege and not substantially reducing OS security. In fact, Android has standard support for it.
RethinkDNS is a good example of an app providing support for local filtering via the VPN service app feature without losing the ability to use a VPN. RethinkDNS supports using a WireGuard VPN or even multiple chained WireGuard VPNs while doing local filtering of both DNS and arbitrary connections. It can filter connections based on the results of filtered DNS resolution. That's the approach that's used by Android so that's inherited by every OS in the comparison.
GrapheneOS is the only OS that's listed fixing all of the leaks for standard VPN lockdown feature which is needed to prevent leaks for firewall apps including RethinkDNS based on the VPN service app feature. That's not listed by the table, although it could be and it would make sense for someone to file an issue proposing listing it. Many GrapheneOS privacy and features are not listed by Eylenburg's comparison and a lot of what's listed are under huge categories such as "Hardened system components".
For the Android comparison, GrapheneOS is the only privacy and security hardened OS included in the comparison. DivestOS used to be included before it was discontinued. An OS not including Google Mobile Services and branding itself as private based on that is a much different thing than a privacy and security hardened OS. Which other Android-based hardened OS could be included in the comparison?
None of the operating systems listed in the comparison include app accessible root access. Giving unconstrained root access to a huge portion of the OS including the application layer including a GUI application for managing firewall rules is not a well secured to implementing it. Managing firewall rules is entirely possible to implement while following the principle of least privilege and not substantially reducing OS security. In fact, Android has standard support for it and all of the operating systems included in his comparison rely on it if you want to do fine-grained traffic filtering.
RethinkDNS is a good example of an app providing support for local filtering via the VPN service app feature without losing the ability to use a VPN. RethinkDNS supports using a WireGuard VPN or even multiple chained WireGuard VPNs while doing local filtering of both DNS and arbitrary connections. It can filter connections based on the results of filtered DNS resolution. That's the approach that's used by Android so that's inherited by every OS in the comparison.
GrapheneOS is the only OS that's listed fixing all of the leaks for standard VPN lockdown feature which is needed to prevent leaks for firewall apps including RethinkDNS based on the VPN service app feature. That's not listed by the table, although it could be and it would make sense for someone to file an issue proposing listing it. Many GrapheneOS privacy and features are not listed by Eylenburg's comparison and a lot of what's listed are under huge categories such as "Hardened system components".
I was arguing on the other axis. It's got good coverage of OS options, but the list of features is indistinguishable from someone saying "okay, this is what GOS does; how do others compare to each of its selling points?"
> None of the operating systems listed in the comparison include app accessible root access.
There is a difference between not shipping something by default, and being actively hostile to it.
> Giving unconstrained root access to a huge portion of the OS including the application layer including a GUI application for managing firewall rules is not a well secured to implementing it.
Agreed, that would be foolish. Thankfully, nobody is suggesting that. Just use a permission prompt, like every android root solution has for... over a decade? I don't think I've ever seen anyone not putting root behind a permission prompt, actually.
> RethinkDNS is a good example of an app providing support for local filtering via the VPN service app feature without losing the ability to use a VPN. RethinkDNS supports using a WireGuard VPN or even multiple chained WireGuard VPNs while doing local filtering of both DNS and arbitrary connections.
AFAICT, RethinkDNS demonstrates the problem quite nicely. On, say, my laptop, I can configure arbitrary VPNs and firewall rules, and I can configure them independently. Android conflates them such that - if not using root to work around the official way - your firewall app and your VPN app must be the same app. It's nice that RethinkDNS has specifically added wireguard support to its firewall app, but the fact that they needed to is a symptom of a poor design.
That's not what they're doing. Their focus is privacy and security, but they've only included a single OS in the comparison aligned with that focus. They don't want to include less known operating systems such as forks of GrapheneOS.
> There is a difference between not shipping something by default, and being actively hostile to it.
GrapheneOS doesn't do anything that's hostile towards users having root access. It provides official support for it in userdebug builds, which we recommend doing with ro.adb.secure set to 1 rather than using the default Android userdebug configuration.
> Agreed, that would be foolish. Thankfully, nobody is suggesting that. Just use a permission prompt, like every android root solution has for... over a decade? I don't think I've ever seen anyone not putting root behind a permission prompt, actually.
That's not addressing what was said. Having a permission prompt to grant unconstrained root access to apps still involves giving root access to a massive portion of the OS, greatly harming the security model and losing a bunch of the security features. It inherently regresses security in an enormous way which having user-accessible root access alone does not. Making it accessible to apps through the high level OS UI is a far different thing from having a very well protected way for users to have root access.
> On, say, my laptop, I can configure arbitrary VPNs and firewall rules, and I can configure them independently.
There are major issues with VPN leaks without these things tightly tied together and having multiple things configuring firewall rules is going to cause major conflicts. Android provides support for having a per-profile VPN with built-in leak blocking where the OS takes on most of the responsibility for it and can properly integrate it everywhere that's required.
> Android conflates them such that - if not using root to work around the official way - your firewall app and your VPN app must be the same app.
No, it does not have to be the same app. It's a choice the app developers are making to not provide an extensible system interoperable with other apps but rather to do everything themselves. It's also not a conflation of these things but rather it needs to be implemented as an OS API to do it properly.
> It's nice that RethinkDNS has specifically added wireguard support to its firewall app, but the fact that they needed to is a symptom of a poor design.
It's not a poor design but rather a much better design which avoids the very broken approach of multiple applications including VPNs trying to configure firewall rules. It's impossible to get right without all of those applications closely coordinating which is not what happens. Having VPN support built into the OS with a well defined API for apps to implement it with leak blocking support built into the OS is a far better approach which can be done correctly instead of the mess on laptops/desktops you're talking about. Android doesn't have a great implementation of all this upstream but the high level design approach is a far better one. It needs a major overhaul to heavily use network namespaces instead of the current messy approach built on a legacy design. That does not change that providing the VPN leak blocking within the OS and an API for VPN implementations is definitely a better approach. Built-in WireGuard support would be nice too but should be done properly.
Giving root access to a huge portion of the OS including the high level application layer and to actual apps running on top is always an insecure approach to this. It's a lazy shortcut to skip having to implement a proper system following the principle of least privilege where the GUI portion of the OS does not simply have unconstrained root access to manage everything at a low level in incorrect, racy ways. The correct place for firewall management is netd with user-facing interfaces which end up controlling what's done by netd. netd has CAP_NET_ADMIN and is in fact contained by SELinux without access to much more than networking configuration. Giving unconstrained root access to the GUI portion of the OS where minor UI bugs can give permanent root access to an attacker where there's no way to revoke it if they want to stop it is definitely not the right approach to implementing more user-facing firewall controls.
Why would you make essential security features illegal? Do you want to fly on a plane where the flight control software was maybe overwritten?
>So if you buy a device with CPU and writable memory, you should be able to load your own program and manufacturer may not use technical measures to stop you.
The problem is Google and Apple locking down their Operating System, this is not a technical limitation on hardware.
I don't understand it. Whoever owns the place can replace any part of it, including computers. So being able to overwrite software doesn't change it. Furthermore, plane computers are not a consumer hardware.
You could make a better example with patched car software.
> The problem is Google and Apple locking down their Operating System, this is not a technical limitation on hardware.
The initial ROM bootloader contains hard-coded signature which prevents you from replacing Apple/Google software.
No need to strip out every wall, we just have to think about the problem and put doors at necessary places so we can enjoy both freedom AND security.
Except regulations are now moving in the opposite direction: to mandate device locking.
You can buy a refurbished Pixel 5 for less than 200$. Great screen, great camera, 5G, the works. It's definitely not an "outdated" device, and it runs Graphene or Lineage with minimal hassle.
You can also use 2 SIMs on a Pixel by using an eSIM.
Also, the basic premise is that you can buy a decent Pixel phone for an affordable price, not that it has the very best price/value out of any device. I would also wager that the Pixel 8 has massively better cameras than a Samsung A16, so not apples to oranges.
More seriously: I believe many refurbished resellers do swap a new battery on the higher quality tiers.
The Pixel 8 and 8a aren't that expensive either. And keep in mind that they are supported until 2030 and 2031 respectively. [1] They not only receive security updates for 7 years, instead of the 5 years for previous Pixel generations, but also have stronger hardware security, by implementing the ARM memory tagging extension. [2]
https://wiki.lineageos.org/devices/#motorola
For family, I just got a used Edge 30 Neo for ~100$ and put LineageOS on it, and it works like a charm. Phones like the Moto g84 go for even less and still can be bought new for a decent price.
Xiaomi would be even cheaper, but I would highly discourage getting one because the unlock process is plain ridiculous nowadays.
And as others have already noted, if you don't mind getting a phone that's a few years old, a used Pixel 5 is not expensive (still happily using a Pixel 4a and don't see why I would need to upgrade).
great for playing around with or if you want to install something like GrapheneOS.
The solution, I think, would be a regulation that forbids manufacturers of any chip or device CPU from making obstacles to reprogramming the device (using fuses, digital signatures, encryption etc). So if you buy a device with CPU and writable memory, you should be able to load your own program and manufacturer may not use technical measures to stop you. The goal of regulation would be preventing of creating digital waste, vendor locks and allow reusing the hardware.
Of course, features like theft prevention won't work, so the user should be able to waive this right.