As an author of an old root for Android, and of a modern generic custom ROMs, and other Android OS stuff:
The title is, and forever will be wrong. When we say you're root in Android, you're actually root. You can actually do whatever you want [1]. Magisk (the now modern "root" for Android) now includes stuff to even "edit" Java code, so even if it's hidden deep somewhere, you should still be able to access it. (Even if somehow it moves from Java to native code, we'll still find ways, don't worry)
The fact that the author didn't manage to do it doesn't mean it's not possible. I could guess what's the author issue (I have two ideas in mind: 1. it requires stop;start to restart zygote, because zygote cached CAs, 2. it needs to switch to correct mount namespace before doing the commands), but I won't try it, I got tired of working on closed-source Android stuff.
> More investigation is required and it's hard to know the full implications of that now, but for the many forks of Android like GrapheneOS & LineageOS, and for advanced device configuration tools like Magisk and its many modules, it probably spells trouble.
I just don't understand this. GrapheneOS and LineageOS team have full source-code access. They can do whatever they please with it. (The limitation being that Google breaks stuff at an incredible rate, and following is a bit annoying)
Anyway, I hope that Android becoming more and more user-hostile (and more specifically in this case power-user-hostile) will move more and more people to custom ROMs. (In my dreams I make a "OwnerDroid", an Android fork where the security model doesn't have the first line saying "the user is an enemy", but even though I developed some tiny bricks of it, the overall project would take a huge amount of work)
[1] Except for some kernel-level protections, but GKI reduces that risk.
The crux is that previously any user could modify these certs directly, even on vanilla OS images from Google themselves, without installing any tools at all - just by writing to disk - and that's both widely used and included in the setup guides for lots & lots of tools.
Now, you can't do that.
Of course, with full source code access anything is _possible_. You can absolutely build your own Android system images from scratch disabling all these modules to work around this, and it's certainly possible for GrapheneOS/LineageOS to handle that too - but it will create a bunch of new work, and diverging from Android's implementations of core components may mean more work in future. And for most affected users "first, build your own system image" is significantly beyond their comfort zone and level of time commitment.
There will be other solutions eventually - it may be possible by digging through the namespacing and modifying the mounts of target processes individually to disable this, or there might be a way to somehow build & install your own APEX modules in a way that Android will trust, to replace the system module and thereby modify this directory, or who knows what else. There will certainly be per-process fixes possible with Frida, with hooks targeted to individual applications. More ideas welcome too :-D
Despite all that though, it's still going to be a major problem that makes it harder for users to fully control their own devices.
> The crux is that previously any user could modify these certs directly, even on vanilla OS images from Google themselves, without installing any tools at all - just by writing to disk - and that's both widely used and included in the setup guides for lots & lots of tools.
"Just by writing to disk" omits the part where you needed to unlock the bootloader (wiping data), flash a custom recovery, install a superuser implementation and remount /system as writable (or used an overlay do fake it). The only thing that seems to be changing is where and how these certs are stored, so the procedure will be exactly the same apart from the last step, which was never the hard part. By the time you set up a phone for root access, needing one extra app or overlay to add CAs is barely an inconvenience.
> The crux is that previously any user could modify these certs directly, even on vanilla OS images from Google themselves, without installing any tools at all - just by writing to disk - and that's both widely used and included in the setup guides for lots & lots of tools.
Yes, and that was used for some horrifying security/privacy breaches that made this whole site preach about buying iPhones.
> Anyway, I hope that Android becoming more and more user-hostile (and more specifically in this case power-user-hostile) will move more and more people to custom ROMs.
What about people who kinda gave up tinkering with custom ROMs because the state of the stuff that matters (root checks by your mandatory banking app, some Google stuff) is either not documented (good luck finding an overlap of "phone model" + "your local bank app" + custom ROM" as a tested and known-good thing).
I'm all for freedom and choice, but I don't think unless you're willing to go through a couple of phones, a couple of days of work, or are a specialist in the first place, this is a reasonable way of action for average phone users. I know you said "power users", but I'm a power user with computers, my phones could be a lot dumber if I had my way - but it won't happen if we have to increasingly use them as MFA devices or be at the whim of corporations with a better lever (i.e. banks, I'm not changing my bank account 3 times until I find one with an app that works on a rooted phone...)
Magisk and Shamiko together have been working well for me to hide root from Google Pay/my bank app for the past year or so (fingers crossed, ymmv). Highly recommend the experience of having a rooted phone though, it's a nice feeling controlling your device, especially being able to control the traffic and just like... run unix utilities natively. I really wish it was something I didn't have to spend so much effort achieving but it has been worth it. I find the experience of using a device I don't have full control over beyond irritating.
Armchairing here, but from a quick gloss over the article it seems like it should be quite easy to stub out:
> this new approach reads certificates from /apex/com.android.conscrypt/cacerts, when it exists.
Much like the how the current work arounds for safetynet, hiding root, and hiding magisk work, it should be possible to hide /apex/com.android.conscrypt/cacerts from select processes as needed to make it fail over to the old way.
Sorry for your experience and thank you for all the work you did in this domain. But I'm afraid that custom roms will never be a mainstream thing no matter how much Google (or Apple) misbehaves. That's a hackers only thing and then only a very small fraction of the hackers.
> Anyway, I hope that Android becoming more and more user-hostile (and more specifically in this case power-user-hostile) will move more and more people to custom ROMs.
Indeed, Android 5.0 has been that release for me. The redesign left the UI in a state of inconsistent mess, took away dark mode, made my otherwise perfectly performant Nexus 4 sluggish, broke apps...
Custom ROMs were unfortunately not the answer, at least not for me - and TBH I doubt less technical users will appreciate the trade-offs. I've tried SailfishOS, been on Cyanongen/Lineage for a while, but ultimately if you want a device that just works, and works well...
Everything is a compromise, might as well choose Apple.
> Android becoming more and more user-hostile (and more specifically in this case power-user-hostile) will move more and more people to custom ROMs
I never owned a phone supported by any of the custom ROMs I investigated.
Samsung Galaxy S2, Sony Xperia X Compact, Samsung A40.
Except the first one, which was huge by the time and tiny nowadays, I buy the smallest phone I can find. Apparently no ROM developer is interested in those phones.
You can run custom ROM on it (the suupport is provided by Sony themselves), though maybe you need to actually build it yourself (which yeah not great, but you don't have to write the drivers, the build scripts and everything related yourself)
> Samsung A40.
You can run custom ROM on it (using Generic System Images)
> I buy the smallest phone I can find. Apparently no ROM developer is interested in those phones.
Well, I am interested in those phones :P. I currently daily driver Asus Zenfone 9 (compact in nowadays standards, but not really compact), and Qin 3 Ultra (actually compact, usable one-handed). And I definitely run custom ROMs on it.
> I hope that Android becoming more and more user-hostile (and more specifically in this case power-user-hostile) will move more and more people to custom ROMs.
I 100% share your desire but this is wishful thinking imo. People tend to comply when given no other options.
init could chose to launch every process in a new mount namespace, which would break this. I have no idea whether it does that, it probably doesn't, but my point is that as long as it's not released and open source, it's not worth looking at.
> Anyway, I hope that Android becoming more and more user-hostile (and more specifically in this case power-user-hostile) will move more and more people to custom ROMs.
Or even ditch closed platforms for good. In other words: "Oh, PinePhone 2, where art thou?"
So many good comments here, but I keep thinking about how thankful I am that PCs don't work like smartphones, and it's sad it's regressed to this point.
Android has so thoroughly defeated itself, that I feel crazy to say I'm thankful that microsoft doesn't run the PC world like google runs the smartphone world.
Windows itself is a bastion of stability and sanity compared to android. Things do not need to be upgraded prior to the hardware actually breaking of old age.
Beyond that, just like google, microsoft doesnt control the entire hardware-software pipeline. But just like google, microsoft is in a place of power where they could have made it incredibly inconvenient to own your PC, by dictating norms through a store, or discouraging any deviation of environment by safetynet.
My memory is bad here, but did this sort of thing ever end in antitrust lawsuits for microsoft in the past? And, when can we look forward to the same for google?
Windows has had regular CA updates for about two decade now. If anything, Android works more like Windows at this point.
Microsoft has also added tons of DRM to Windows (which they later broke). Remote attestation is built into the OS as well.
Google has inconvenienced Android developers by altering the Android internals you weren't supposed to rely on anyway; Microsoft does this all the time as well.
We may need to wait a few weeks for an updated Magisk module. Honestly, it's really notm that bad. Just don't click the update button on the five or six devices that will receive Android 14 before then.
People forget that Microsoft tried to go the iOS route and control everything by signing everything from boot to executables which one would only get from the Microsoft app store. This is what spooked Valve into developing Steam Machines and Steam OS; I'm grateful for Proton, but it was necessitated by Microsoft aggressively closed designs.
It's a super soft requirement. I have secure boot and tpm disabled on my pc and win 11 doesn't care.
Why? Because I can't set my prefered GPU with uefi enabled (which is required for secure boot), and I occasionally passthrough my windows disk to a VM when I'm dual booted into my Linux OS (so naturally windows can't use the tpm).
Lets talk when You will have to go out of your way to even get access to privileged account in Windows.
Right now comparing restrictions of TPM to android having majority of their api (and functionallity) gated is just laughable
I can kind of see how this could be a win for users though. I've heard that some 3rd world countries demand users to install the country CA so they can MitM all connections. By making this very hard, it becomes unfeasible to get users to disable their privacy.
That kinda presumes that those countries will be understanding. Call me cynical, but it seems more likely that having an Android 14 device will be considered as implicitly wanting to not install the country CA.
I'm daily driving a Pinephone Pro. Interesting note out there: Chase.com tries really, really, really hard to block you from using non-standard browsers (like Librewolf) as well as phone/tablet browsers (it will try to force you to use the mobile application.)
At least until WEI becomes mandatory, this isn't really a serious problem, since these braindead measures are all easily bypassed. However, I am interested if there is any potential legal avenue to pursue given that Chase is a bank. My first guess would be ADA compliance, but I'm not sure. At this point, I'm so fed up that I am not sure if it is an empty threat anymore to say that I'm interested in filing lawsuits over this.
(I realize this is a tangent, but it's relevant because it underscores yet another facet of how leaving the oligopoly of mobile phone operating systems is damn near impossible. Android will just keep getting worse, probably even if the Linux phone niche miraculously grows to a couple percentage points; we need something.)
We are going to have an age of digital serfdom. You will use a device provided to you by some "benevolent" corporation. They will own every aspect of that device and you will only be allowed to drive it if you give them money (pay your access fee today!).
They will lock down most other avenues, general computing will be reserved for "corporate" use only, and while there will be a "free web", it will be fairly technical and user hostile, and the vast majority of marketplaces (ex: anything that touches money) will avoid it like the plague.
None of us individually can fix the problem we're faced with, but I'll tell you what we can do: Be the biggest possible pains in the ass about it, and that's exactly what I intend to do. I'm planning on digging my heels as deep as they go and just causing as much trouble for everyone. Believe me, if my browser gets blocked based on user agent, the owners will hear about it. I will bypass it. (I am bypassing it in many cases.) If you try to push me to a mobile app, I'm either going to find a way to use your website, or I'm taking my business elsewhere at basically any cost necessary. For me, the end of the open web is scorched earth. I intend to gain approximately nothing from this, and I don't care.
I just don't see how 'general computing' can ever be taken away from those determined to have it. Forget the latest, fastest CPUs for a moment and focus on what general computing really is.
I can build a computer from scratch from existing knowledge I have stored in my head. Computing that I'm in control of really can't really be taken away from me on a basic level.
I don't disagree though, the web itself is becoming a hellscape and I expect it to be completely and totally locked down within my lifetime. I don't think the web most people know is savable anymore.
The problem is that too many people hate tech... The people who would otherwise want unrestricted general computing now want no tech at all, or they only want tech as a platform to explore ideas, sort of an external neural enhancement, but not as an ubiquitous presence used by everyone for most daily tasks.
FOSS is falling farther and farther behind commercial tech, and people actively don't want feature parity with commercial apps, they want faithfulness to an interesting technical vision, and they want things that stay out of the way and are made of modular pieces, rather than things that do as much as possible and come with their own opinionated workflow you just learn and use.
Funny how your comment reads like my iPhone user experience (minus the "pay your access fee today!")
I personally do not have a problem with these serfdoms, as they meet a real, functional need. It does suck that there aren't as many easy alternatives for smartphones as there are for laptop computing.
By continuing to be a Chase customer, you are supporting their predatory stance, and signaling that it's okay for the rest of the industry to adopt the stance as well.
I may very well leave Chase over this issue, but unless we can convince a critical mass of people to care about this issue deeply, I think we're screwed. Me leaving Chase will do nothing, except perhaps restore a tiny bit of my dignity.
But, I do have a bigger problem: where do I go to signal that I care? "Anywhere" is an answer, but is it a good one? Who can I trust to not do this?
And in addition, if I'm going to leave over it, I'm going to at least make noise first.
Sadly I think Google has killed the open web with this. It was getting boring anyway. But it's annoying how much harder it is to live without a phone/"approved" browser, etc. now.
If there’s an accessibility feature that you need and can only get with an alternative browser, then you should contact Chase. It’s great if an expert user knows how to fix a problem by installing extra software, but it would be even better for Chase to make a change to their basic website that would help even novice users with similar needs.
I think android is - and has been - more heavy-handed than Apple here. Even when you could install and trust a new root CA, some apps can and would ignore this. Apps can use certificate pinning on both iOS and Android, but apps by default on Android just ignore user-added CAs by default on Android 7+, since 2016[1].
On iOS, the process of trusting a root CA is (rightfully) tricky, requiring you to install a profile and jump through some hoops with some scary warnings, but in my experience most apps will trust it unless they're using pinning.
I can honestly see why Google did this in Android 7. Android, being much closer to a normal computer than iOS, has a huge stalkerware problem. Stalkerware isn't stopped by prompts, weaponises backwards compatibility, and includes all manner of abuse.
On iOS it's shockingly easy to subvert your HTTPS privacy for years after you've let someone borrow your phone for five minutes.
I would love the option to actually trust CA certificates I install (especially Firefox, a fucking web browser, doesn't even opt into user certificates without a secret tap combo and hidden settings), but I don't think this feature is important enough for the dozens of techies using them day to day considering the risk to every other Android user on the planet.
In this case there's no evil Google conspiracy to thwart the plans of your local IT department, this is just a side effect of Google's excellent sandboxing improvement and long overdue CA store update mechanism.
I'm sure Magisk modules will appear to work around this problem. The existing Magisk modules will be broken for a while but that's par for the course after major Android updates. I'll write a module myself if I have to.
> On iOS it's shockingly easy to subvert your HTTPS privacy for years after you've let someone borrow your phone for five minutes.
You need a passcode to install certificates. And people casually handing over their phones would be a much bigger problem if that really is widespread behavior.
Second, can we stop using "techies" as some kind of magic word to make any technical concerns go away?
> especially Firefox, a fucking web browser, doesn't even opt into user certificates without a secret tap combo and hidden settings
Firefox uses it's own CA store and installing your own is trivial. Ever tried to just open URL with your cert? The ui for certs isn't nice, but you can still view them in 'about:certificate'
Installing into system store and then configuring Firefox to use system store is the hard way, on all supported systems.
The same is true on Android for processes with system capabilities/root, I believe, because they can bind sockets to a specific interface and bypass the VPN you use.
Isn't this just how mounts work? If you have a something mounted to /apex/whatever and each app has a separate mount namespace, then mounting over /apex/whatever in your namespace wouldn't change anything in any other mount namespace. You'd need to either just alter the filesystem directly, or enter the other apps' mount namespaces and mount your tmpfs there too.
Shared mounts might be useful here. Not sure. I'd need to take a closer look at what is going on here.
But I would say this result is probably a byproduct of whatever namespacing/containerisation Google is doing, rather than an intentional effort to prevent users from changing the root CAs even as root.
> But I would say this result is probably a byproduct of whatever namespacing/containerisation Google is doing, rather than an intentional effort to prevent users from changing the root CAs even as root.
Yes, I think in practice that's true. The end result is still a big problem though!
> Isn't this just how mounts work? If you have a something mounted to /apex/whatever and each app has a separate mount namespace, then mounting over /apex/whatever in your namespace wouldn't change anything in any other mount namespace.
The latter 'separate mount namespace' here is the surprising bit. Previously, you could open a shell, mount things into the filesystem (or just modify it directly) and apps would happily read files from those mounts.
Now, for these cacert files, that's not the case, and additionally with the new approach direct modification is impossible.
Before this change, I wasn't even aware that Android apps were using their own mount namespaces! There's very little documentation on exactly how that works and I'm not sure if there's been a case where its been clearly visible until now.
> But I would say this result is probably a byproduct of whatever namespacing/containerisation Google is doing, rather than an intentional effort to prevent users from changing the root CAs even as root.
Technology is very convenient when it's complex enough to find an excuse to fit your business objective (see manifest v3).
Left a reply to the author on Twitter, but putting it here as well in case they didn't see it.
Hi! I'm the guy who wrote the blog post about updatable certs in Android 14 that your article linked. Not sure if you're aware, but there's actually a system property you can set to bypass reading from the APEX cert directory.
I don't think that helps much unfortunately. That's a java.lang.System property (i.e. a config value set within one JVM/app) as opposed to an android.os.SystemProperties OS property (globally configurable on the device via adb). Reconfiguring the former requires modifying the app itself AFAICT.
That's useful for automated testing (which appears to be why they've added it) or for toggling settings between debug/prod builds, but not so much if you want to globally trust a CA certificate on your device. Of course, if you know a way to externally set such a property so that it applies to every app, that would indeed work great, and I'd love to hear about it!
(I'm the author btw, and I don't see any such reply on Twitter? Classic 2023 Twitter ofc)
It's been a long known issue [0] that cert providers had to account for, but apparently not anymore [1] from Android 14
> Android 14 makes root certificates updatable via Google Play
> Android's root store used to require an OTA update to add or remove root certificates. That won't be the case in Android 14.
TIL there's a workaround though [0]:
> If you use Android 7.0 or earlier, you may need to take action to ensure you can still access websites secured by Let’s Encrypt certificates. We recommend installing and using Firefox Mobile, which uses its own trust store instead of the Android OS trust store, and therefore trusts ISRG Root X1.
> What happens in 2-3 years when this version of Android is abandoned?
I had to install a Let's Encrypt certificate to get my self-hosted password manager working because Google's updates are missing an intermediate certificate Let's Encrypt uses. This is not a hypothetical down the road issue but an issue present right now. Why should Google be the final arbiter of who I trust? They clearly have their gaps.
And let's not even get started on the existing approved certificate providers that you shouldn't really be trusting since they've been shown to provide certificates to people and organizations that shouldn't have them.
My wife just had to replace her phone because of that. Apps generally don't accept user certificates and the first apps stopped working because Google cloud (or something related) updated to a newer certificate
Certificates are an APEX module now (which is the crux of authors complaints actually), which means they're updated out of band by Play Services and don't need an OS update from OEM.
Every android release I see things removed, and inconsequential things added.
It seems like iOS has been doing the opposite, such that slowly they may meet in the middle, and then iOS exceed android in every way.
Apple folk, can I get an honest opinion here: I've been using macOS lately and I hate it because it fails at really basic user experience things that've been common on windows/linux for decades. Like finder, it's just the worst.
If I were to get an iphone next generation instead of an android, would I have the same negative reaction to iOS? Would you say that iOS is a more complete, useful UX than macOS, for the smartphone use case?
I think I want to make the jump, but I also don't want to waste my time/money.
Yes and when the Appstore restriction is removed and sideloading apps becomes trivial, I literally can't think of a single thing android would have over iOS. It's such a shame since android used to be much more than just iOS but with .apk.
I don’t use my iPhone for much more than for scrolling hn during breakfast, portable audio player, looking random things up if I’m on the go, and making calls. It’s fine for that. But the user is so restricted (u can look into jailbreaking), I try to use my phone the bare min and use my desktop for everything.
For context this is also someone in the midst of dumping macOS for Linux as well
Readit News
The title is, and forever will be wrong. When we say you're root in Android, you're actually root. You can actually do whatever you want [1]. Magisk (the now modern "root" for Android) now includes stuff to even "edit" Java code, so even if it's hidden deep somewhere, you should still be able to access it. (Even if somehow it moves from Java to native code, we'll still find ways, don't worry)
The fact that the author didn't manage to do it doesn't mean it's not possible. I could guess what's the author issue (I have two ideas in mind: 1. it requires stop;start to restart zygote, because zygote cached CAs, 2. it needs to switch to correct mount namespace before doing the commands), but I won't try it, I got tired of working on closed-source Android stuff.
> More investigation is required and it's hard to know the full implications of that now, but for the many forks of Android like GrapheneOS & LineageOS, and for advanced device configuration tools like Magisk and its many modules, it probably spells trouble.
I just don't understand this. GrapheneOS and LineageOS team have full source-code access. They can do whatever they please with it. (The limitation being that Google breaks stuff at an incredible rate, and following is a bit annoying)
Anyway, I hope that Android becoming more and more user-hostile (and more specifically in this case power-user-hostile) will move more and more people to custom ROMs. (In my dreams I make a "OwnerDroid", an Android fork where the security model doesn't have the first line saying "the user is an enemy", but even though I developed some tiny bricks of it, the overall project would take a huge amount of work)
[1] Except for some kernel-level protections, but GKI reduces that risk.
Now, you can't do that.
Of course, with full source code access anything is _possible_. You can absolutely build your own Android system images from scratch disabling all these modules to work around this, and it's certainly possible for GrapheneOS/LineageOS to handle that too - but it will create a bunch of new work, and diverging from Android's implementations of core components may mean more work in future. And for most affected users "first, build your own system image" is significantly beyond their comfort zone and level of time commitment.
There will be other solutions eventually - it may be possible by digging through the namespacing and modifying the mounts of target processes individually to disable this, or there might be a way to somehow build & install your own APEX modules in a way that Android will trust, to replace the system module and thereby modify this directory, or who knows what else. There will certainly be per-process fixes possible with Frida, with hooks targeted to individual applications. More ideas welcome too :-D
Despite all that though, it's still going to be a major problem that makes it harder for users to fully control their own devices.
"Just by writing to disk" omits the part where you needed to unlock the bootloader (wiping data), flash a custom recovery, install a superuser implementation and remount /system as writable (or used an overlay do fake it). The only thing that seems to be changing is where and how these certs are stored, so the procedure will be exactly the same apart from the last step, which was never the hard part. By the time you set up a phone for root access, needing one extra app or overlay to add CAs is barely an inconvenience.
Yes, and that was used for some horrifying security/privacy breaches that made this whole site preach about buying iPhones.
What about people who kinda gave up tinkering with custom ROMs because the state of the stuff that matters (root checks by your mandatory banking app, some Google stuff) is either not documented (good luck finding an overlap of "phone model" + "your local bank app" + custom ROM" as a tested and known-good thing).
I'm all for freedom and choice, but I don't think unless you're willing to go through a couple of phones, a couple of days of work, or are a specialist in the first place, this is a reasonable way of action for average phone users. I know you said "power users", but I'm a power user with computers, my phones could be a lot dumber if I had my way - but it won't happen if we have to increasingly use them as MFA devices or be at the whim of corporations with a better lever (i.e. banks, I'm not changing my bank account 3 times until I find one with an app that works on a rooted phone...)
1. Discovered that emergency calls would crash the phone (during an emergency)
2. The LineageOS April Fools prank.
Such people should consider GNU/Linux phones, Librem 5 and Pinephone as an investment in the future.
That's a strategy to keep the competition busy just keeping up: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
If you ask "what competition (from Android forks)?", that means it's working.
> this new approach reads certificates from /apex/com.android.conscrypt/cacerts, when it exists.
Much like the how the current work arounds for safetynet, hiding root, and hiding magisk work, it should be possible to hide /apex/com.android.conscrypt/cacerts from select processes as needed to make it fail over to the old way.
Indeed, Android 5.0 has been that release for me. The redesign left the UI in a state of inconsistent mess, took away dark mode, made my otherwise perfectly performant Nexus 4 sluggish, broke apps...
Custom ROMs were unfortunately not the answer, at least not for me - and TBH I doubt less technical users will appreciate the trade-offs. I've tried SailfishOS, been on Cyanongen/Lineage for a while, but ultimately if you want a device that just works, and works well...
Everything is a compromise, might as well choose Apple.
I never owned a phone supported by any of the custom ROMs I investigated.
Samsung Galaxy S2, Sony Xperia X Compact, Samsung A40.
Except the first one, which was huge by the time and tiny nowadays, I buy the smallest phone I can find. Apparently no ROM developer is interested in those phones.
You can run custom ROM on it (the suupport is provided by Sony themselves), though maybe you need to actually build it yourself (which yeah not great, but you don't have to write the drivers, the build scripts and everything related yourself)
> Samsung A40.
You can run custom ROM on it (using Generic System Images)
> I buy the smallest phone I can find. Apparently no ROM developer is interested in those phones.
Well, I am interested in those phones :P. I currently daily driver Asus Zenfone 9 (compact in nowadays standards, but not really compact), and Qin 3 Ultra (actually compact, usable one-handed). And I definitely run custom ROMs on it.
I 100% share your desire but this is wishful thinking imo. People tend to comply when given no other options.
Or even ditch closed platforms for good. In other words: "Oh, PinePhone 2, where art thou?"
Android has so thoroughly defeated itself, that I feel crazy to say I'm thankful that microsoft doesn't run the PC world like google runs the smartphone world.
Windows itself is a bastion of stability and sanity compared to android. Things do not need to be upgraded prior to the hardware actually breaking of old age.
Beyond that, just like google, microsoft doesnt control the entire hardware-software pipeline. But just like google, microsoft is in a place of power where they could have made it incredibly inconvenient to own your PC, by dictating norms through a store, or discouraging any deviation of environment by safetynet.
My memory is bad here, but did this sort of thing ever end in antitrust lawsuits for microsoft in the past? And, when can we look forward to the same for google?
Microsoft has also added tons of DRM to Windows (which they later broke). Remote attestation is built into the OS as well.
Google has inconvenienced Android developers by altering the Android internals you weren't supposed to rely on anyway; Microsoft does this all the time as well.
We may need to wait a few weeks for an updated Magisk module. Honestly, it's really notm that bad. Just don't click the update button on the five or six devices that will receive Android 14 before then.
Why? Because I can't set my prefered GPU with uefi enabled (which is required for secure boot), and I occasionally passthrough my windows disk to a VM when I'm dual booted into my Linux OS (so naturally windows can't use the tpm).
At least until WEI becomes mandatory, this isn't really a serious problem, since these braindead measures are all easily bypassed. However, I am interested if there is any potential legal avenue to pursue given that Chase is a bank. My first guess would be ADA compliance, but I'm not sure. At this point, I'm so fed up that I am not sure if it is an empty threat anymore to say that I'm interested in filing lawsuits over this.
(I realize this is a tangent, but it's relevant because it underscores yet another facet of how leaving the oligopoly of mobile phone operating systems is damn near impossible. Android will just keep getting worse, probably even if the Linux phone niche miraculously grows to a couple percentage points; we need something.)
We are going to have an age of digital serfdom. You will use a device provided to you by some "benevolent" corporation. They will own every aspect of that device and you will only be allowed to drive it if you give them money (pay your access fee today!).
They will lock down most other avenues, general computing will be reserved for "corporate" use only, and while there will be a "free web", it will be fairly technical and user hostile, and the vast majority of marketplaces (ex: anything that touches money) will avoid it like the plague.
I can build a computer from scratch from existing knowledge I have stored in my head. Computing that I'm in control of really can't really be taken away from me on a basic level.
I don't disagree though, the web itself is becoming a hellscape and I expect it to be completely and totally locked down within my lifetime. I don't think the web most people know is savable anymore.
FOSS is falling farther and farther behind commercial tech, and people actively don't want feature parity with commercial apps, they want faithfulness to an interesting technical vision, and they want things that stay out of the way and are made of modular pieces, rather than things that do as much as possible and come with their own opinionated workflow you just learn and use.
I personally do not have a problem with these serfdoms, as they meet a real, functional need. It does suck that there aren't as many easy alternatives for smartphones as there are for laptop computing.
But, I do have a bigger problem: where do I go to signal that I care? "Anywhere" is an answer, but is it a good one? Who can I trust to not do this?
And in addition, if I'm going to leave over it, I'm going to at least make noise first.
Sadly I think Google has killed the open web with this. It was getting boring anyway. But it's annoying how much harder it is to live without a phone/"approved" browser, etc. now.
On iOS, the process of trusting a root CA is (rightfully) tricky, requiring you to install a profile and jump through some hoops with some scary warnings, but in my experience most apps will trust it unless they're using pinning.
[1]: https://android-developers.googleblog.com/2016/07/changes-to...
On iOS it's shockingly easy to subvert your HTTPS privacy for years after you've let someone borrow your phone for five minutes.
I would love the option to actually trust CA certificates I install (especially Firefox, a fucking web browser, doesn't even opt into user certificates without a secret tap combo and hidden settings), but I don't think this feature is important enough for the dozens of techies using them day to day considering the risk to every other Android user on the planet.
In this case there's no evil Google conspiracy to thwart the plans of your local IT department, this is just a side effect of Google's excellent sandboxing improvement and long overdue CA store update mechanism.
I'm sure Magisk modules will appear to work around this problem. The existing Magisk modules will be broken for a while but that's par for the course after major Android updates. I'll write a module myself if I have to.
> On iOS it's shockingly easy to subvert your HTTPS privacy for years after you've let someone borrow your phone for five minutes.
You need a passcode to install certificates. And people casually handing over their phones would be a much bigger problem if that really is widespread behavior.
Second, can we stop using "techies" as some kind of magic word to make any technical concerns go away?
Firefox uses it's own CA store and installing your own is trivial. Ever tried to just open URL with your cert? The ui for certs isn't nice, but you can still view them in 'about:certificate'
Installing into system store and then configuring Firefox to use system store is the hard way, on all supported systems.
Shared mounts might be useful here. Not sure. I'd need to take a closer look at what is going on here.
But I would say this result is probably a byproduct of whatever namespacing/containerisation Google is doing, rather than an intentional effort to prevent users from changing the root CAs even as root.
Yes, I think in practice that's true. The end result is still a big problem though!
> Isn't this just how mounts work? If you have a something mounted to /apex/whatever and each app has a separate mount namespace, then mounting over /apex/whatever in your namespace wouldn't change anything in any other mount namespace.
The latter 'separate mount namespace' here is the surprising bit. Previously, you could open a shell, mount things into the filesystem (or just modify it directly) and apps would happily read files from those mounts.
Now, for these cacert files, that's not the case, and additionally with the new approach direct modification is impossible.
Before this change, I wasn't even aware that Android apps were using their own mount namespaces! There's very little documentation on exactly how that works and I'm not sure if there's been a case where its been clearly visible until now.
Technology is very convenient when it's complex enough to find an excuse to fit your business objective (see manifest v3).
Dead Comment
Hi! I'm the guy who wrote the blog post about updatable certs in Android 14 that your article linked. Not sure if you're aware, but there's actually a system property you can set to bypass reading from the APEX cert directory.
system.certs.enabled=true
From: https://android-review.googlesource.com/c/platform/framework...
That's useful for automated testing (which appears to be why they've added it) or for toggling settings between debug/prod builds, but not so much if you want to globally trust a CA certificate on your device. Of course, if you know a way to externally set such a property so that it applies to every app, that would indeed work great, and I'd love to hear about it!
(I'm the author btw, and I don't see any such reply on Twitter? Classic 2023 Twitter ofc)
What happens in 2-3 years when this version of Android is abandoned? You pray the hardcoded certificates will last you a couple more years?
> Android 14 makes root certificates updatable via Google Play
> Android's root store used to require an OTA update to add or remove root certificates. That won't be the case in Android 14.
TIL there's a workaround though [0]:
> If you use Android 7.0 or earlier, you may need to take action to ensure you can still access websites secured by Let’s Encrypt certificates. We recommend installing and using Firefox Mobile, which uses its own trust store instead of the Android OS trust store, and therefore trusts ISRG Root X1.
[0] https://letsencrypt.org/2023/07/10/cross-sign-expiration.htm...
[1] https://www.xda-developers.com/android-14-root-certificates-...
I had to install a Let's Encrypt certificate to get my self-hosted password manager working because Google's updates are missing an intermediate certificate Let's Encrypt uses. This is not a hypothetical down the road issue but an issue present right now. Why should Google be the final arbiter of who I trust? They clearly have their gaps.
And let's not even get started on the existing approved certificate providers that you shouldn't really be trusting since they've been shown to provide certificates to people and organizations that shouldn't have them.
Apple folk, can I get an honest opinion here: I've been using macOS lately and I hate it because it fails at really basic user experience things that've been common on windows/linux for decades. Like finder, it's just the worst.
If I were to get an iphone next generation instead of an android, would I have the same negative reaction to iOS? Would you say that iOS is a more complete, useful UX than macOS, for the smartphone use case? I think I want to make the jump, but I also don't want to waste my time/money.
For context this is also someone in the midst of dumping macOS for Linux as well