Before buying a smartphone I tried to find an inexpensive model that supports open source OS, but I couldn't. What open OS support is ether expensive Pixels, or outdated models.
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.
Looks like GrapheneOS will be available on another "major Android OEM” soon [1].
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...
GrapheneOS is in some ways not an open OS. The official builds don't provide root access. So for example apps are able to hold your data hostage from you.
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).
People can modify GrapheneOS however they want including making their own builds with the officially supported userdebug root support enabled. Open and free doesn't mean catering to power users with the official setup at the expense of everyone else. It doesn't mean sacrificing substantial privacy and security for niche aesthetic customization and other power user features. Defining freedom for devices as software providing more customization options for power users is strange. The freedom is from it being open source and any OS being permitted on the devices.
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.
GrapheneOS is all about security, not privacy or freedom. You coincidentally get privacy and freedom benefits, but only where they don't conflict with security.
That's untrue. The main focus of GrapheneOS has always been privacy. This level of privacy is enabled through good security. GrapheneOS goes above and beyond in regards to privacy. No other custom Android OS hosts its own time server, proxies for PSDS and SUPL, captive portal, Wi-Fi positioning proxy, Widevine provisioning proxy, etc.
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.
People have the freedom to modify GrapheneOS in any way they want and run it on their device instead of the official releases. Freedom doesn't mean GrapheneOS going out of the way to provide all kinds of power user with major downsides. As an unrelated example, GNOME isn't less free than KDE because it's more minimal and doesn't have extensive configuration.
Root access doesn't magically make an OS "open". You can disable System Integrity Protection on macOS and get full root access. That doesn't make it an open OS in any way. Root access fundamentally breaks the security model of Android. It's totally unsuitable for production environments. See https://madaidans-insecurities.github.io/android.html#rootin...
Raw root access isn't what I'd want apps to have.. it's that the Android permission system deliberately limits what the user can consent to, the rest is for "system apps" and to install those you need to unlock bootloader and start the whole "journey" while saying goodbye to banking apps.
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.
I agree that a powerful permission model is a great feature. But that doesn't obsolete the option to have the "root permission" that you can give when required. Sure, for my specific gripe a "full filesystem access" permission would be sufficient and better. But there are going to be other use cases that require other permissions. So it is always going to be useful to have that backup root permission that you can assign to very specific apps when required.
Root access isn't available by default, but it takes about 120 seconds (including waiting for it to reboot) to add it.
Last I checked the situation was similar to what it is in Calyx, which is that it's not officially supported and you have to keep manually reapplying the root after every update.
Userdebug builds of GrapheneOS with ADB root access are officially supported. We recommend setting ro.adb.secure=1 rather than making a standard userdebug build with always-on unauthenticated ADB if it's not solely for development.
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.
I've been trying to make a UserDebug build for the last few days by following the official instructions at https://grapheneos.org/build, and am running into some trouble which I suspect are due to minor steps in the documentation that are missing or incorrect.
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?
Oh yep, forgot about that. I barely ever update so I only have to re-root 2-3x a year.
> Looks like GrapheneOS will be available on another "major Android OEM” soon.
I'm secretly hoping that this will be Framework or Nothing.
Could either of those be considered a major Android OEM? I was thinking Motorola.
True. Or maybe resurrect HTC.
On my samsung phone, I just tested, the search bar was as easy to remove as any other widget.
I just wish they had two sizes, a pocket version please. I have small Trumpian hands.
Not sure what exactly you mean with "open source OS" and if Lineage counts as one in your book: it supports quite a few cheap and also fairly recent Motorola phones, which are also easy to unlock:
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).
Most vendors (at some level) allow flashing custom distributions, as long as you didn't buy that device from carrier: https://github.com/zenfyrdev/bootloader-unlock-wall-of-shame...
You will lose DRM-based apps (e.g. Netflix), Payment apps, and bank apps though.
This is the place where I think lawmakers needs to be involved. Bearing in mind that laws aren't engineering specs, being able to pay for things and use a bank are about as close to fundamental rights as anything is for participants in society. If you have to buy a second device to use Netflix, so be it, but we need laws that guarantee people can make digital payments without Apple or Google's permission.
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.
> Security is important
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.
Yes, if it was a measure of device security they would revoke attestation of devices that are behind on security updates. But no, a 5 year old device that never got security updates is A-OK according to Google but a completely up to date custom ROM is not.
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.
> Yes, if it was a measure of device security they would revoke attestation of devices that are behind on security updates.
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 think you are right that it is about control.
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.
> 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.
"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.
> If you have to buy a second device to use Netflix, so be it, but we need laws that guarantee people can make digital payments without Apple or Google's permission.
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.
Secure boot and OEM bootloader unlock should be able to work with images so you can lock a phone after the upgrade again.
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.
You can relock the bootloader but it still fails the SafetyNet check since it's not running an "official" OS signed with the manufacturer's keys.
yup it will, but this is where some legislation might help to get certified 3rd party ROM images that will pass. Its a tricky topic though.
This is outside of my area of expertise. I know there are i.e. banking apps that will disable themselves if you're running some unofficial 3rd party Android derivative like LineageOS. Are you saying those apps would work again if you perform some kind of secure boot locking procedure?
It does vary. TWRP/Magisk can enable apps, but its case by case.
Even phones from Motorola require you to literally ask permission to unlock your bootloader via a form on their website, which they then unlock remotely or you enter some generated code.
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.
And good lock unlocking anything over 5 years old because the updated website doesn't support what you've got. Been there, it sucks.
To be fair, for "anything over 5 years old" you can probably find a privilege escalation exploit.
Do tell me when you find one for unlocking the bootloader of an LG G6, been looking for one for a few years now :)
A 1st gen Verizon Moto X bootloader unlock would be nice as well.
the question is not "being able to", the question is "being able to with a reasonable effort".
wandering the web to find an exploit is way beyond my spare time.
That might get you root but not a bootloader unlock.
Many of them are actually not bootloader locked.
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.
There are privilege escalation CVEs in bootloader code too. I remember unlocking some very early locked bootloaders this way in the early days of android.
So much rarer now. Its getting more and more locked down unfortunately.
A lack of security vulnerabilities isn't really a matter of being "locked down" but rather "not broken"
iiuc that is because malicious actors were buying phones in bulk, flashing them with backdoored/malicious operating systems, then re-selling them to people.
Not in markets without significant Huawei and Xiaomi presence. Local banks (Czech Republic) are not using integrity APIs to keep being usable for most clients.
Most DRM / banking apps work fine for me through the browser and you can add them to your home screen. Android / Samsung Pay will stop working, but if you have a Garmin watch, you can still pay with that.
But this is changing. Already in multiple countries(and soon possibly EU wide) there will be only play integrity(strong verdicts) to enforce availability of many services(if not using ios, which is the same locked in syndrome).
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.
Only for now. Google did push the Web Environment Integrity API, which is basically "Play Integrity API for Chrome," that helps websites check if the OS, browser, or installed extensions are "safe".
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.
That small little caveat already makes it a non-option
Android and said manufacturers purposefully do everything in their power to make this as awful as possible.
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.
Bank apps work fine (at least UK ones) on Graphene OS installed via the play store.
I wouldn't want the bank to access my phone, so it doesn't matter that the app doesn't work, and in a weird case where you urgently need to transfer your money to scammers while not being at home, you can use bank's web app.
There are at least a couple of banks or credit card companies in the UK now that only offer mobile apps, as well as those now using push MFA with their apps for every large purchase. 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.
All the banks I use, have a web app, although it can be somewhat limited, but I don't need any advanced functions anyway.
> 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.
Banks are all moving to MFA through an app, which then needs play protect, which then maybe need TWRP/Magisk.
All the Fairphone Versions support e/OS/ as far as I know. I have the Fairphone 5 with the current e/OS/ version completely un-googled. But you also have the option to allow partial google-fication in e/OS/ so you don't miss out on most of the features and paid-apps you had.
> a regulation that forbids manufacturers of any chip or device CPU from making obstacles to reprogramming the device
Except regulations are now moving in the opposite direction: to mandate device locking.
> Before buying a smartphone I tried to find an inexpensive model that supports open source OS, but I couldn't. What open OS support is ether expensive Pixels, or outdated models.
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.
The Pixel 5 isn't supported anymore. The Pixel 6a still has a little less than 2 years of support left. These have become pretty cheap.
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]
[1] https://grapheneos.org/faq#device-lifetime
[2] https://grapheneos.org/faq#recommended-devices
The battery probably lost its capacity in 3-4 years since release.
If only things could be made so parts that wear out can be swapped at a repair shop...
More seriously: I believe many refurbished resellers do swap a new battery on the higher quality tiers.
You can get a new Pixel 8 for ~500$, I would say that has a very decent price to value, and will be supported for longer.
It's hard to find. Pixel 8 costs $670 here, and the cheapest Pixel is 9a for $470. At this price, it is overpriced. Pixel 8 has 8 GB RAM, Samsung A16 with 8 GB costs just $230. It's almost 3 times cheaper. And Samsung supports 2 SIM cards, unlike Pixel, so you can have, for example, one SIM for Internet and another for calls.
As mentioned, second-hand is also an option. But my price was actually from Hungary with world-record VAT included, so not sure if you really couldn't find/order it for around that price.
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.
Used or refurbished devices are typically much cheaper. It's what I would recommend.
You can also use 2 SIMs on a Pixel by using an eSIM.
I snagged a Pixel 8A for around 200 on ebay.
you can also snag refurb'd Pixel 7s for $170 off eBay atm
Droidian[0] currently supports a relatively new Motorola phone[1]. A Snapdragon 8+ gen 1 device, so the performance isn't bad, and most features seem to work, including Waydroid. I've noticed incoming phone calls causing a glitch where the call can't be answered, but other than that, daily drivable. Just like a PinePhone, only more powerful. In my region it can be had for ~€250 brand new.
[0] https://droidian.org/ [1] https://www.notebookcheck.net/Lenovo-ThinkPhone-by-Motorola-...
Did you check the stuff murena has on offer? Most if not all of their phones come with an unlockable bootloader and the OS they come with isn't that bad to start with either.
They are pretty bad when it comes to security:
https://eylenburg.github.io/android_comparison.htm
Does it? If it looks equivalent to "stock" Android but you can do what you want with is, including removing bloatware, then it's arguably more secure and thus a better alternative than most. It might not be the most secure but it's already a step.
Hmm... that looks like a pretty skewed comparison. It's as if somebody took the security features that make Graphene stand apart and compared everything else to them.
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.
Eylenburg's site is focused on privacy and security for the comparisons. GrapheneOS is the only privacy and security hardened OS included in the Android-based OS comparison. None of the other operating systems listed in that comparison keep up with Android privacy/security patches or provide significant OS level privacy or security improvements. Many GrapheneOS features aren't listed by the table or are grouped in huge generic categories such as "Hardened system components". An example of a major privacy feature not listed by the table is closing the leaks in Android's standard VPN lockdown mode. GrapheneOS fixes all 5 of the known outbound leaks in VPN lockdown mode, CalyxOS partially fixes 1 of them and the others don't touch this since that's not their focus. It's a privacy and security focused site comparing an OS focused on improving those in the OS layer to ones which mostly aren't.
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.
So, what you are saying is that Lineage has bad security because they are doing their best to support old devices as long as possible?
Interesting position. It is a valid criticism but brings its own problems.
No, that's not at all what was said.
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.
I'm going to echo the sibling comment that this comparison conveniently centers on GrapheneOS while conveniently ignoring anything they don't do; for example, a firewall using root is useful, but since they've decided user's can't be trusted with control of their devices that's right out.
Eylenburg's site has comparisons between a bunch of different types of software and services with a significant focus on privacy and security rather than aesthetic customization features, etc.
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".
> 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?
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.
> 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?"
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.
Indeed, and starting at 360€ for a CMF Phone 1 with OS already installed, no tinkering, feels relatively affordable and easy to try.
fyi you can buy refurb'd pixel 7's off eBay for like ~$170
great for playing around with or if you want to install something like GrapheneOS.
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]
[1] https://grapheneos.org/faq#device-lifetime
[2] https://grapheneos.org/faq#recommended-devices
Every few years or so we collectively rediscover that general computing devices should be general and repeat the same mistake every time new format is released. We're all a bunch of reactive losers and that will never change it seems.
We just had a thread about this on https://news.ycombinator.com/item?id=45740383.
Many of those devices are closed exactly due to regulations.
>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).
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.
> Do you want to fly on a plane where the flight control software was maybe overwritten?
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.
On pixel devices you can add your own signature to be checked and thus can use secure boot with a custom OS - that's how GrapheneOS works.
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.
Security only works if you can control what software is trustworthy. If some software has been proven to be untrustworthy, it is worthwhile to prevent all software that the producer has ever made from working at scale. Adding some nominal process and fee to make it too expensive to create a lot of accounts prevents them from creating hundreds of alternative aliases. There is a lot of precedence for why this is a good idea and works. I think if there was another company involved with performing the audit which folks trusted it might now seem so scary.
Do you understand that you are advocating for a world in which two corporations are the sole determinator of the livelihood of all mobile software developers? A career in software development should not be at the complete mercy of Apple and Google, or I suppose if you had your way Microsoft for PC gatekeeping as well.