Android 14 blocks all modification of system certificates, even as root? | Hacker News Reader

Android 14 blocks all modification of system certificates, even as root?

httptoolkit.com

329 pointspimterry242 comments

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.

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.

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.

Yes, and that was used for some horrifying security/privacy breaches that made this whole site preach about buying iPhones.

Modifying system certificates is uncommon for the average user, but for techies and enterprise apps I imagine it's a lot more common.

It's one thing for the OS to put dangerous things behind warnings, flags and prompts. It is another to cripple the OS.

You can install root certificates, though, and they'll work on almost any app you could need in the enterprise.

But can you uninstall the root certificates of an adversarial government (i.e., your own)? Is it now necessary that the chain of trust includes entities you don't trust?

You can disable certificate authorities in the security settings, yes.

This site preaches iPhone because they make money from the Apple ecosystem.

Developers hate piracy, ad blocking and most of all users.

Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

If I understand correctly, system certificates can be modified without jailbreak or any root access on iPhones.

You can add new root certificates which is common for phones used in the enterprise.

But not aware that you can modify the core root certificates.

"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.

No - the system cert installation works out of the box on Google's own official emulators, for both AOSP & 'Play Services' editions (but not Play Store). Ditto for Genymotion, Bluestacks, etc.

Zero root setup required in those cases, until now. Create the emulator, adb shell, su, mount tmpfs, write your CA certificates.

You can script it and do the whole process in <1 second on a fresh device.

Emulators are a whole different story, I didn't realise that's what you were talking about. But emulators are a very niche use-case and they're already running modified images, so they could easily include a way to write certs. The most important (at least from my perspective) uses of custom CAs are done on real devices though, which have always needed a lot of work to modify, so little changes there.

So to sum up: skill issue.

If you can modify an init.rc then you can bind mount over the apex mount before the Zygote runs.

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.

Even if you can look at the open-source code, it's still a maintenance nightmare to try to build on top of it, it just moves too fast.

Much like any user could fork Chrome in principle and scratch their particular itch, but the sheer pain makes that not worth it except for motivated, organized teams

I'm not sure reverse-engineering some Java bytecode is even the rate-limiting step at this point, I'm more demotivated by the knowledge that everything will break again with energy-sapping frequency

I'm in the unfortunate position that I'm in this maintenance nightmare at work. Though I solved this specific issue months ago. There will be many like it to come.

> 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...)

Just use the bank's PWA, you'll be fine. Or sandboxed play services in a separate GOS user.

Outside of the USA, some banks require mobile apps. If you don't have a working attested phone in these countries, banking becomes decidedly 20th century.

It is different issue than that.

European banks are forced by EU's Payment Services Directive 2 (PSD2) to authenticate using MFA for any payment over 50 EUR.

So what is the second factor? Your phone. Once you pair the app in your phone with your account, you can authenticate your actions using that phone, even if you are otherwise banking using the web app on your computer. Most banks also insist on using their apps, they don't allow generic second factors. Since their apps require Android with SafeNet or iOS, they pretty much enforce the Google/Apple duopoly.

For now, there are other ways -- sms, which the banks are trying to phase out.

So I imagine situation elsewhere will be very similar.

I don't know where you're from, but here in austria most banks offer 'cardTAN' as an alternative to mobileTAN. I always assumed cardTAN is a thing everywhere...

edit: with cardTAN you get a OTP/TAN 'calculator' into which you put your smartcard to generate TANs on the fly.

I use it because to me this feels more like a real second factor, when I use my mobile for banking.

The DACH world is specific in many things... but I've seen cardTAN outside it. In Slovakia, Tatra banka does use this system. I guess being part of Raiffeisen explains it.

cardTAN is being rapidly phased out in Austria.

Same here in NL, for now. But: banks are pushing their apps hard, to the point where every authentication you have to manually switch - again - to indicate that you want to use the token generator and not their app (never mind cookies and so on, those are only for the marketing department, when for once they could actually use them to store your preferences).

And there will likely be a time when the bank simply cuts access to the cardTAN system and only allow their apps. Screw them because that means I have to use a smartphone, which I really do not want. The cardTAN system has been very good so far in preventing fraud, once the phone is the token it suddenly gets a lot more complicated and less secure.

Fun fact, I still have the thing here, used it for many years, but they made it obsolete. App only now. It's a German Sparkasse :(

That used to be the universal way here (Belgium) before the banks went all in with apps. I'm not sure wether typing a challange/response into a browser is inherently more secure than a phone app.

For those wondering about 2FA with these apps, factor 1 is "something you own" namely that particular phone/sim, and factor 2 is "something you know", your PIN.

You can still use cardTAN, but the app is way more convenient, especially with QR.

My French bank, CIC, sold me a Digipass scanner+pin authentication device. Adding yet another device to the usual kit bag won't make it very popular but an option independent from Google/Apple exists and I guess that its non-existence wouldn't fly for long with regulatory authorities.

https://www.onespan.com/products/transaction-signing/cronto/...

Banks have no clue about 2FA/ MFA, they will happily put the bank app and the custom TOTP generator/ "key"-app on the same phone or, as a fallback, send SMS to the same phone the bank app is on. So in reality, it's at best 1.5FA because when the phone is owned, the user already lost. And it is really hard to not have the banking app on the phone with many institutions. Some institutions now put the TOTP generation into the same app too. Oh and there are limits on the user name and password-length that make it easier for attackers to crack, in some cases (in Germany) the password can be exactly 5 characters long and the username tends to be the debit card number by default. In many ways, this is really cumbersome, not really secure and on top of everything else adding a false sense of security. Less advanced customers are either somewhat secure but then the product is barely usable or they can realistically use the service but the security is so-so.

> Banks have no clue about 2FA/ MFA, they will happily put the bank app and the custom TOTP generator/ "key"-app on the same phone or, as a fallback, send SMS to the same phone the bank app is on.

This. My bank in France, BNP, does that. Every so often, when I connect to the app on the phone, it says something similar to "in accordance with <some regulation> a strong authentication must be made every <number> of sign-ins". You're presented with only one button that says something like "ok". You press it, and you're in business.

This is after requiring me to type in my pin, which must be precisely 6 digits, and some sequences are forbidden, so you can't type 1234 or similar. It doesn't seem to interact with the secure enclave in any way.

If this number of sign-ins is reached while I'm on a PC (which is the most likely), it'll send a confirmation request on the phone, so at least it works there. When paying online, I'll also get a confirmation request on the phone app.

On my professional account, with the same bank, the situation used to be exactly the same. But a few months ago, they switched away from that to sending a confirmation code via SMS for bank transfers. Credit card payments still have the app confirmation request.

They do? My bank is very explicit about "don't ever run the front-end and the second factor on the same device". Perhaps it's a German thing, with all our Datenschutz fundamentalism that will happily consider even IP addresses PII?

My experience is with select German and Czech banks and/ or "Sparkasse" which is a kind of savings bank used very often by private citizens. These tend to have better mortgage options in some cases but are quickly inconvenient if you have an unusual (digital/ SaaS) business or any kind of special requirements, like if you want to transfer larger sums of money into other countries with a decent exchange rate.

> "don't ever run the front-end and the second factor on the same device"

This is required in some cases, probably unless you apply for the physical hardware token generator which costs extra. You must apply for the 2FA-app initialization through the banking app that you are supposed to run on the same phone. In both cases, it is basically impossible to have a backup. Also, the banking app and the banking key app are supposed to have a separate PIN/ short password or a biometric login. Of course, the biometric approach has all kinds of problems in legal challenges (e.g. something you know is protected differently to something you are). Also, something you know cannot be easily obtained while you are asleep. Also, you probably don't want to use your password manager on your mobile phone - so there you are, typing a generated password to log into the key/ 2FA app for security theater. If there wasn't the banking app right next to the key app, the bank could probably just use something like FreeOTP+ or Google Authenticator without reinventing the wheel, also enabling backups in the process and skipping sending physical mail with the initial setup tokens. But that would be too straight forward and not "enterprise" security or whatever. The situation in Czechia is more or less similar. The banks tend to belong to the same banking groups so the underlying infrastructure might be similar even though Czechia still does not have the Euro/ SEPA.

> Banks have no clue about 2FA/ MFA

Of course they do. But they need to balance security with end user experience.

And since security for a bank is about risk management they can offset this risk in other areas to compensate e.g. additional processes for activities involving larger amounts of money.

My bank wants me to type a code received in the app into a number field a little bit lower on the screen in the same app. They consider this a second factor. Of course it's nothing but busywork and security theater.

> Since their apps require Android with SafeNet or iOS, they pretty much enforce the Google/Apple duopoly.

That is positively insane. So if you don't use vanilla Android or iOS, you can't use a credit card for more than 50EUR? No phone, dumb phone, too bad?

> Just use the bank's PWA, you'll be fine.

Just over a month ago, a proposal to prevent that was posted here: https://news.ycombinator.com/item?id=36875940

The authors of the PWAs would need to opt-in to this.

We distribute LOB banking apps as PWAs to our customers. In no reality would I consider incorporating this into our tech stack. We use PWAs and avoid native apps precisely to maximize compatibility across arbitrary IT policies in our various customer installs.

I don't know if our customers want to use linux, windows, android or apple. I don't WANT to know anymore. I just want to target a common API (HTML5), add some bandaids for iOS/Safari (usually after WWDC each year) and move on with life. Throwing DRM and platform constraints into the mix sounds like I might as well go back to native (I won't).

We are one of the few vendors that will actually get into a heated argument and push back against customers over FUD security crap like this. If a prospect insists that we add some draconian DRM to our product stack, I would make it very clear to leadership that I do not think we should do business with that customer on technical grounds.

If you find yourself in a situation where you need to trust the client implicitly, then you have catastrophically failed in the rest of your design.

I appreciate what you do if you really do deliver that, but plenty of FIs are happy to mandate things like Trusteer Rapport and I would anticipate that sector to jump onto WEI just as fast as media companies will. It's going to be sold to execs as a zero operational cost lightswitch solution to preventing account hijacks.

Up until about a year ago one major core provider had been using the password 'money' for all their client accounts, many of which were domain admins since that is a 'just make it work' button and they cannot actually tell you what privs their service accounts need. When we asked the clients to press them on it, we determined via cracking that they had changed it to 'monet' as a workaround. The standards for excellence are SO LOW.

> that they had changed it to 'monet' as a workaround

> The standards for excellence are SO LOW.

I'm 99% sure I know which vendor you are referring to.

Almost everything in fintech is a hacky mess. This is our competitive advantage. Doing the barest-acceptable thing makes us look like rockstars compared to every other vendor in the space.

Check deposit and Zelle is only available in the app.

The two things that stopped me from using custom Android ROMs:

1. Discovered that emergency calls would crash the phone (during an emergency)

2. The LineageOS April Fools prank.

Presumably as an April Fools' joke, LineageOS added an undismissable notification informing users that, "You might be a victim of software counterfeiting"

Removing it requires updating to another build or rebooting into recovery and changing a setting using terminal via setprop .

instructions: Okay I finally managed to solve the LineageOS Settings"You might be a victim of counterfeiting" april fools joke. Here are the steps to how I solved it 1. Boot in to TWRP-recovery 2. Open Terminal under the advanced tap 3. Type the following "setprop persist.lineage.nofool true" in the terminal 4. Reboot the phone and voila :)

What a terrible idea...

It made me realise that these huge and reputable Android ROM developers will still treat your phone like a toy, and are therefore completely untrustworthy.

3. You can't use trusted SIM services such as e-signature with custom ROMs. I have an e-signature embedded into the cryptographic module of my SIM card, and no custom ROM can use that, because they can't provide a secure pipe from SIM to antenna, and that's a deal breaker.

Uh, that doesn't make sense to me. Could you provide some details? The point of SIM card is that there is no user-controlled software in the path between SIM card and antenna. So if the pipe from SIM to antenna was secure before custom ROM, it's still secure after it.

In my e-signature workflow, I initiate the process from outside. So, a network provider notification comes in, I accept it, check a fingerprint presented, enter PIN, and hit send. So, there are couple of screens and a keyboard is presented to me.

When I used a custom ROM, I never received the notification, IIRC. Even carrying the relevant bits from the official ROM didn’t matter. It never worked, crippling tons of things at the end.

If used or reflashed the stock ROM, things have returned to normal.

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.

> What about people who kinda gave up tinkering with custom ROMs

Such people should consider GNU/Linux phones, Librem 5 and Pinephone as an investment in the future.

Anything that isn't on standard Android that any non technical person uses, doesn't count, as that isn't what regular public uses.

> 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.

> 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?"

> 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.

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.

> 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.

> Sony Xperia X Compact

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.

> The limitation being that Google breaks stuff at an incredible rate, and following is a bit annoying

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.

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.

Microsoft tried, they just failed. For now. They are still trying. Windows 11 requires TPM and Secure Boot.

I think they were successful in obsoleting a huge amount of functioning computers, forcing my people to buy new hardware to run Windows 11.

For now, most people and businesses ignore Windows 11; they are happy with Windows 10. In 2025, once the Windows 10 support ends, it will be more interesting.

And this is part of my point: by the time microsoft kills old computers, if they even do, they'll be 10 years old, not 2 years old.

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).

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.

"S Mode" is still a thing. On top of what you listed it also enforces Edge as browser and Bing as search engine. I'm not kidding: https://support.microsoft.com/en-us/windows/windows-10-and-w...

S mode is like an ad-funded tier of a streaming service: you pay less up-front, but you are forced to watch more ads. Herding people to edge and bing is how microsoft makes sure they can present those ads.

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

Let me remind you Windows RT for ARM. Same restrictions of TPM, some screws tightened somewhat more.

>Same restrictions of TPM, some screws tightened somewhat more

Well yes, that windows was basically a direct competition to android (or tried to). Not sure what has TPM to do with anything really, but regardless;

I am not saying that Microsoft is pure hearted angel that would never dare to restrict client's freedom. Obviously they did it before many times and certainly will in the future.

What I am saying though, is that for now, Android is on completely different plane of user restriction then Windows (in it's main version) is. And even if Windows is constantly looking for opportunities to tigthen it's grip, none of the restrictions that are implemented right now can justify the conclusion, as if Windows is becoming so restrictive that it's reasonable to compare it to Android. Criticize them all you want, I will as well. But let's not bend the reality just so it's easier to say 'all corpos bad', rather then putting a small ammount of effort to distinguish between the levels of opression

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.

The update will eventually flow through to all devices sold. And these tiny shit countries don't have unlimited resources to just build their own tech like China can. They often take the extremely easy approach to censorship and then give up when it's too hard.

The last time I checked, cell companies produced custom android builds for the phone on their networks.

Presumably, they’ll just factory/ota install the malicious certificates.

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.)

Dark ages are a-coming. Seriously.

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.

Yeah - No joke, I'm right there with you.

I just don't think it will matter. There is too much money on the table, and too much pressure on the "security" front to get most of the people implementing this to just... stop. They have rational reasons for doing the things they're doing, and they're sitting in the "corporate developer" spot, which will still get the goodies like a real server that can run real code.

I'd like to see some real government regulation... my basic stance is - if I own the device, I should get a key to EVERY fucking lock it has, including all the digital ones. Which seems very sane, and completely mirrors the same stance for ownership of things like houses and cars (the owner gets all the keys).

But the government (at least in the US) has lodged the corporate phallus SO far down its fucking throat it's literally choking to death. So I don't expect any miracles.

But you don't really own the device. Since day 1 Apple has been opposed to this on all their hardware, but most especially iOS hardware. You have the right to use it as they provide, or destroy it. Ergo you own the physical device minus all firmware and software. You have no right to inspect, understand or modify the firmware or software in any way. By extension, there is no right to repair.

This highly successful paradigm is now replicated by John Deere, and Tesla. WiFi radios are being locked down.

I remember folks on HN warning of the slippery slope a decade ago, universally shot down. Security!

Sure, and this is why I utterly refuse to buy Apple hardware (note - I'm still forced to use Apple hardware by my place of employment... sort of making my point).

It's also why I've chosen to do things like selfhost my own services, run my own computing hardware (literally sitting in my basement), contribute to and fund open source initiatives, and continue arguing that the government should regulate this behavior.

Because frankly... I agree with you: it's a highly successful paradigm. If left alone and unregulated, companies that don't abuse their customers in this manner will become less and less prevalent.

I call it "the little green man" paradigm: They have a literal enforcer sitting inside your phone who only answers to them. They use that little green man to extort rent from you for services and goods that shouldn't require any sort of ongoing or recurring expense, but will... because rents * * cough * * excuse me, "subscriptions" are just wonderfully profitable.

I'm just not an optimist on this front.

You don't have to gain anything- it's called not sacrificing your principles. Something many here don't understand. If we don't like something we don't have to put up with it but it might take some sacrifice.

> Something many here don't understand.

This is a complete cop out, and a misunderstanding about how this works.

This is a principle that works right up to "Can I feed my kids" and then it doesn't work at all.

Principles are flexible. Some are more flexible than others. You NEED food in a way that you don't need general purpose computing. If you are forced to choose, I know which one people will pick.

They will just put a finger on the scale to make it more and more difficult to choose an open solution. You will start losing things like income, job opportunities, government access, etc.

They don't have to make you switch... they just have to make an environment where you are less fit. Make your life harder at every step, limit your opportunities, and wait for you to go extinct. And... you will.

I'm complaining about the users around here who will not sacrifice the smallest convenience for their stated principles.

Just wait until everyone's favorite benevolent company misses earnings for a quarter or two.

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.

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.

It's not that you won't be able to have a general purpose computer, it's that nothing that touches valuable services will be accessible to it.

You can run your toy rpi hobby server, but you won't be able to buy goods, check your bank statements, file your taxes, buy your insurance, pay your rent, check your email or message your mom.

Doing any of those things will require getting permission from the gatekeepers of those services, and your device won't get it if you have root.

In the BEST case: the government heavily regulates what those gatekeepers can do. In the worst... they "convenience fee" away absolutely all surplus productivity so a very small group of people holding digital keys gets to be stunningly rich.

> it's that nothing that touches valuable services will be accessible to it. > Doing any of those things will require getting permission from the gatekeepers of those services

I don't see how we aren't already at this point.

I can be locked out of my banking tomorrow for any reason by the bank or government, banking apps won't run on rooted phones or even many browsers, I can be banned from email providers and I can't reasonably host my own as big providers won't accept messages from my server, etc.

That's not even touching on how companies like CloudFlare are effectively already the gatekeepers of traffic to any service you would want to use.

From my perspective the future you're scared of is here already and only getting worse.

Watch what happens when the bottom finally drops out of Intel and the cloud retreats behind their own custom ARM or RISC-V server optimized SoCs. Open hardware sources will dry-up.

There are very few OSS hardware vendors that are in a position to pick up supporting the whole ecosystem enchilada. System76 is the only one that comes to mind. They seem to understand to some degree where the puck is heading.

While 'general computing' can't be taken away, what an individual or small company can support won't be able to compete with the locked down systems, especially if the upstream efforts are spread across multiple open source fronts.

>While 'general computing' can't be taken away, what an individual or small company can support won't be able to compete with the locked down systems, especially if the upstream efforts are spread across multiple open source fronts.

This is a very pessimistic view.

IBM never designed the PC to be future proof. It just happened to pick up.

RISC-V standardization extends to the boot process and the platform, facilitating a standard PC that's cleaner, simpler and better than the current incidental IBM PC derived platform, which has accumulated much baggage since 1981.

The platform standard being open and simple minimizes the effort the software side (esp. the OS) needs to spend on supporting the hardware.

I mean even if you can build a computer from scratch a few self built transistors aren't going to weigh up against advanced microchips.

Unless we have different ideas of what 'from scratch' means.

Our ideas of what it means are the same and I agree, but "general computing" doesn't mean the latest, most up to date hardware. The ability to freely compute on a basic level isn't under any threat.

I guess I'm being kind of pedantic, but I think there's a meaningful difference between being able to freely compute and being able to freely interact with systems run by other parties which is what is actually threatened.

We're in a new Gilded Age, and it's going to have to get worse before it can get better.

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.

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.

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.

People have been making a ton of noise and leaving the large predatory for-profit retail banks for years. There was a massive uptick in 2008, and again in 2011 with the Occupy Wall Street movement.

Find a local credit union. They are better in literally every conceivable way. They have stronger financial controls, better service, better fees for all their financial products, and basically every credit union is part of the STAR network which is the largest ATM network in the world.

I've seen the exact complaint of yours a few times over several social networks in the past couple weeks, so the word is definitely out there. Chase is shit, but we all knew that already. Time to move your money, and stop supporting these crooks. It's actually super simple. It takes maybe an hour to convert everything from Chase to a credit union. Open the account with the credit union first, and they'll give you everything you need to transfer everything over, even credit cards that aren't fully paid off etc. Then you walk into a Chase branch for the last time ever, and move it all.

"At least until WEI becomes mandatory"

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.

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.

[1]: https://android-developers.googleblog.com/2016/07/changes-to...

huh, but on iOS you have apps that can ignore your VPN connection... https://restoreprivacy.com/latest-ios-found-to-bypass-vpn-co...

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.

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.

> 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.

> 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'

Not on Firefox for Android, it just makes me download the file. You can do it of course; just go to Settings > About Firefox > Tap the Firefox logo seven times > Go back > Secret Settings > Toggle "Use third party CA certificates".

about:certificate shows me a bunch of buttons to export certificates, but there's no disabling or importing from that screen.

> Not on Firefox for Android, it just makes me download the file

That's... interesting. I did import my ca cert exactly this way, so they must have changed it... bummer.

In the about:certificate I can see the ca cert that was imported this way and inspect it.

It definitely used to work like this, but thst functionality broke for me when the Firefox rewrite launched (Firefox 69 I believe).

In my opinion, Firefox shouldn't need to keep a separate store for user imported certificates at all. The operating system already has this built in, with a dedicated API to listing and importing these certificates, and Firefox actually uses that if you use the secret setting to enable it (not in about:config, you're not allowed to touch about:config unless you run Beta or Nightly).

I think Firefox tries to be simple and easy like Chrome is, but just fails to in edge cases. I still can't paste an IPv6 IP address (i.e. http://[2000::5677]/) into the address bar and just visit it like I can on every other browser I've tried, and to me that's indicative of Mozilla's struggles to keep up with the mobile browser market.

First, this is utterly false:

> 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?

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.

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.

system.certs.enabled=true

From: https://android-review.googlesource.com/c/platform/framework...

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)

Finally had a chance to test it, and you're right. It's not a property that can be set via "setprop", unfortunately.

This sounds nice for security, hell for some developers but:

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?

Objective achieved : consumer buys new phone.

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

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.

[0] https://letsencrypt.org/2023/07/10/cross-sign-expiration.htm...

[1] https://www.xda-developers.com/android-14-root-certificates-...

Good ol' Firefox, keeping up its reputation as the only user-respecting major browser.

They're updatable via Google Play starting with 14, so not tied to OS updates.

But google will abandon this Android version fairly soon as we all know… what Google Play updates in 6 years?

Google already guarantees Pixel security updates for 5 years, so I'd say that's at least the baseline. When Google removed Play Services support for the 4.x series they were 9 years old at that point.

Google and guarantees in the same sentence?

https://arstechnica.com/gadgets/2023/08/google-kills-two-yea...

Random example that even has pixel in it. Not to mention the other randomly canceled services.

/shrug you do you.

Google still updates the built-in for Android 7. They don't really abandon device support for old OS versions like iOS tends to.

The current situation is that the CA bundle doesn't receive any updates from Google. If your manufacturer repackages their CA bundle and still updates your device, you'll receive a new CA bundle, but I don't believe this is guaranteed.

Furthermore, if you're still running Android 14 after six years, your issue is with the manufacturer of your device. The latest version of the CA bundle will still work of course, but you should really be at least four or five Android versions higher at that point.

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.

> 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.

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.

They have a return policy. Give it a shot with a prepaid carrier like Mint.

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

I have a private PKI I use to connect to my self-hosted software: email server, calendar provider, notes server, photo sync tool, etc.

I NEED to be able to add my root cert to the list of certified authorities.

I don't need to change anything to the system provided list. I just need to add mine. It's my device, I'd like to be able to change anything if I want to.

Same for me, but don't a lot of corporate IT policies deploy root certificates to devices too? You'd think there has to be a way to do it.

User certificates still work fine. Apps have to opt into the user CA store (many of them don't) but any app deployed by IT should be fine. Chrome works, Firefox can be made to work, and I believe the Gmail app also works with user CA certificates.

Thanks for the clarification, I was pretty confused by the article on this detail myself. Per app opt seems like a reasonable compromise for my use as long as the browser recognizes my CA, as that's the one I care about.

The biggest issue is that the developer needs to opt in, the user can't decide "my email client should trust this certificate".

I was also confused about that. I don't use an Android phone currently, but I remember you could add your own CA certificates to an Android phone -without being root, just using some option under settings- and at least applications like the web browser would trust them. And I'm not talking about long ago. So I couldn't understand if the need of rooting your device to install custom certificates was for something different.

On Android 7, Google changed the defaults for certificates. Previously, apps trusted system certificates and user certificates unless they opted out. On Android 7, apps have to opt into trusting then user certificate store.

Browsers opt in, or in the case of Firefox, can be configured through hidden settings to opt in. Many other apps don't, though.

If you're trying to intercept traffic or use apps that should opt in but don't, the system store could be altered with root access so that these apps still trusted the certificates you're trying to inject. However, most apps worth their salt implement certificate pinning, so that's hardly reliable anymore. It's Arnold workaround that works on some apps but not on most.

Furthermore, Google Chrome and derivatives require certificates to be logged publicly so malicious CAs can't mess with random domains. Your private CA isn't logged in the public record, so adding the certificate to the system store actually breaks HTTPS for many browsers. You can add the cert to both stores to make it work, but it's kind of a hack.

On iOS loading certificates is easier, but you'll still need to work around certificate pinning if you want to intercept HTTPS traffic.

Thanks for your explanation! What I remember is from an Android version more recent than 7, probably 10, but maybe the browser was Firefox so in that case there was no need to have your device rooted.

One alternative is to use public CAs on your private networks. I've been working on tooling for this at getlocalcert [1]. Side stepping the need to add a trust root makes the public on private approach a net win for some networks. I honestly wasn't expecting Android to block private CAs, but I guess here we are.

[1] https://www.getlocalcert.net/

That looks super convenient! However, some reverse engineering tasks would still require root CA certificates, for example observing app traffic.

You can install your own CA certificate in the user certificate store, and it will be trusted by Chrome and any other app which opts into user-installed CAs, which should include email and calendar apps.

What is unlikely to work is installing your own CA and using it to intercept traffic between apps and the app-makers' servers. That sucks - you should be able to inspect what your own device is doing - but your use case of using a private PKI for your self-hosted software is definitely supported.

>That sucks

It's insecure. If you are a bank app you doesn't want other people to be able to steal the users password by installing a new certificate.

Tough shit. If you are a lot of things you want or don't want a lot of things. It doesn't mean they have a right to the thing they want or don't want.

This is not the same scenario as the user installing a new certificate themselves.

Someone's company can install a certificate onto employee's work phones.

How often does this happen on phones? Why do banks still allow desktop usage then?

It doesn't matter how often it happens. It's a vulnerability that people will end up being exploited or the data will end up being stolen by another hacker.

Not all banks allow desktop usage. Some banks restrict certain functionality from the web interface since it is less secure.

It absolutely matters how often it happens. Otherwise we should start imprisoning everyone in the hopes of getting that one serial killer by the same principle. Some cures are worse than the disease.

You should also have the final say in what is NOT trusted. Not merely adding a cert to trust.

You can disable individual system certificates in the "Trusted credentials" settings panel.

HTTP Toolkit was very helpful for me to extract hidden APIs from crappy EV charging apps in Turkey, combined with Frida to prevent SSL pinning and root detection.

Then I realized, the reason they try to hide is maybe those APIs are abomination /s

I'm not sure of the implications here, so, two questions:

(1) What effect does this have on user-installed credentials, such as a certificate for OpenVPN? I used to be able to install those myself, with a few taps. They did produce the ominous message about someone monitoring my network activity, of course.

(2) Will users still be able to disable CAs in preferences? I routinely go through the list of CAs and disable anything I don't trust, mainly based on country of origin, so China, Russia, Turkey get shut off, et. al. Will this functionality still be available in Android 14?

1. No effect, as far as I can tell. User-installed credentials for other cases are unchanged, this just affects system-managed CA certificates

2. Yes - you can still manually soft-remove CAs through the Settings UI

There are several ways[1] for an Android app to trust a CA:

- by default, using the system installed CAs

- if specified in the app manifest, it can trust the user installed CAs

- included with the app, also in the manifest, it can trust any CA the author of the app decided to trust

[1] https://developer.android.com/training/articles/security-con...

I mean, you still have root and APEX packages aren't doing anything tricky specifically to stymie modifications - they're just mounted file systems. You're still going to be able to modify system certificates, it's just going to be less convenient and need something more than dropping a single file to a folder. Hell, the code is even still falling back to the old file system path if the APEX mount doesn't exist, so you could just delete the entire module and go back to the old method.

> Hell, the code is even still falling back to the old file system path if the APEX mount doesn't exist, so you could just delete the entire module and go back to the old method.

That's covered in the article - no, you can't do this. If you entirely unmount the apex module from the filesystem from a root shell, so the CA certificates aren't visible anywhere on the filesystem, apps will still read them successfully. And the OS blocks RW mounting of APEX modules so you can't delete the cacerts directory within the module either.

It looks like apps have separate namespaced mounts, managed by the OS itself from boot. Effectively they're containerized, and as part of launching all applications the OS is mounting the certs directly into the process's view of the world.

If you can find a way to modify the filesystem the apps see from a root shell, that would be great! I'd love to hear about it. But believe me that I've tried quite a few of the obvious things already.

APEX namespace membership is managed by the ld.txt config file for the dynamic linker, iirc. You can probably just remove the com.android.conscrypt line, or remove the entire conscrypt APEX package from the system and unpack the libs into /system/lib64 instead. Or patch the linker not check APEX signatures, and repack it without the CA folder. Or unmount the conscrypt APEX mount and replace it with a FUSE mount that proxies everything else the CA folder. Or...a bunch of different other methods.

How green and sustainable this approach from Google exactly is when it makes forks like LineageOS harder to maintain?

LineageOS is only way how to keep many devices up to date by security patches. Ability to have newer version of Android is just a bonus... or... uh wait.

It's a very good news for security and also for 99.99% of the Android users. But get me wrong, it would be nice to support power user, they just need to add a feature to easily add a chosen CA and it would be perfect.

Currently CA management was very dangerous because it was not updated (as stated in the article).

New CA were not added so if you kept your phone long enough you would see insecure warning popping up. People would take the habits of accepting without thinking: very problematic behaviour. One solution is to used Firefox which doesn't use the system CA unlike Chrome.

Another more problematic one: untrusted CA were not removed (the author give the example of TrustCor but they were other examples in the past like DigiNotar). Who knows what happens to private key of old untrusted CA ? If they end up in the wrong hands people could get MITM. (Personally, I had to remove DigiNotar for my old phone.)

And of course as the author said: it's also problematic for new certificate authority like Let's Encrypt which at a time needed the complex cross sign certificate to ensure the certificates work for everyone. [1][2]

[1] https://letsencrypt.org/2020/11/06/own-two-feet.html [2] https://letsencrypt.org/2020/09/17/new-root-and-intermediate...

People here just love their locked bootloaders for some reason. But once you free yourself of this silliness, and root all your devices after unboxing, you'll be good for yet a few more years.

Of course it'll only keep being this easy temporarily. Here's a scene from 2026 for your imaginative pleasure:

Door: You need to scan your COVID25 vaccine QR code to open this door.

QR App: This app will only run on a HW attested device

------

Shopkeeper: We only accept WhatsApp pay at this store.

Payment App: This app will only run on a HW attested device

------

Your friend: We can only talk on this one messaging app that everybody uses.

Messaging app: This app will only run on a HW attested device. Oh, but we promise that this encrypted blob of executable code that you can't disable is here just to ensure the safety of your E2E encryption.

------

Your custom ROM rooted Android 18 phone: Running a secure messaging app that was banned from the Play Store and has only like 2 other active users in the world.

The police: Papers please. Phone touches the scanner. Scanner beeps and turns red.

The law: You have violated the Digital Safety Act. Daily driving a non-licensed general purpose computer is illegal as this may endanger "our children".

The law: You have violated the Public Health and Safety Act. Daily driving a non-licensed general purpose computer is illegal as this may be used to circumvent your quarantine and vaccination control status checks.

------

I can go on and on. I think you get the gist of it. Once we have HW attestation fully figured out, these laws will come. Cash will go away. Your agency will go away. Etc.

... And the punchline of the ghost story? The guys coding this stuff up? They're here with us reading this thread. Commenting about the virtues of locked bootloaders for your security.

Googlers are adding attestation to web standards so you can't use escape through the browser. To be fair, Google stands to benefit from this and they get paid in Google so the incentives line up.

Everyone with two motes of influence over the browser market wants to do this: https://httptoolkit.com/blog/apple-private-access-tokens-att...

It's bad. It's especially bad on platforms where you don't get to choose which browser you run, but we should protest it everywhere.

This is just an effort by Big Outdoors to get us to go outside by giving us nothing else to do. /s

Isn’t it well known in the Android modding community how to replace and make custom APEXs? E.g. XDA has some good documentation. That seems like the right way to solve this problem.

[1] https://www.xda-developers.com/android-q-apex-biggest-thing-... [2] https://www.xda-developers.com/android-10-custom-boot-animat...

Where are the diffs of Android 13 against 14. Isn't this an "open source" project.

If Google actively prevents "rollback" to a previous version, then how does a computer owner try out the new version. Once installed, there is no going back. Even if the owner discovers the new version is unsuitable. It's Amazon with no returns. A new car without a test drive.

Reading source changes might be an easier way to review the new version than running it in an emulator and trying to figure out what changed. Is it not possible.

And recently there were discussions about browsers disallowing self-signed certs, even for local host, and going https-only, and the supposed excuse is you can edit your local root store.

Well now what?

We really need a third operating system for phones.

We had them. Nobody bought them and here's what we got. BB10, WebOS, Windows Phone

I _really really_ enjoyed WebOS but it gambled way too hard on "Web Only" for the time period, and didn't really learn the lesson from Apple's attempt at the same thing. I only gave my device up after the screen broke.

And damn, that hardware keyboard layout was fire.

Firefox OS.

There is: https://pureos.net

Do they have any relation with Purism?

It does:

> PureOS is developed by paid and volunteer members of the Purism community, and benefits from the work of its extended communities and projects.

I see. It does make me a little concerned, given the Librem drama.

There are much more reliable ways to intercept traffic than messing with the root certificates. I believe corellium has a more solid strategy where they modify the TLS library to accept certs signed from their proxy and then the certificate from the origin server is passed through as an extension on the proxy certificate.

I mean if they were willing to mess with something that was completely unbroken like the quick access tiles for WiFi/data back in Android 11 (or was it 12?) I wouldn't put it past them to mess with anything else.

Say hi to ebpf, now shipping with android kernels.

Android isn't really open. In order to have a "certified" device you need to remove user control. For example users by default aren't even allowed to access app's "private" data. That was enough to get me to move to something where I am in control.

But if you move away from a "certified" ROM then you start to fail SafetyNet (or its successors) and many apps will refuse to work. Those apps want to make sure that the user isn't in control of their devices, they want to make sure Google or a "trusted party" is.

They say this is to ensure the security of your device that logs into your bank or whatever, but I guarantee that my LineageOS updated this week is more secure than my stock Google ROM that got its last update 3 years ago. If Google really wanted to prove security with SafetyNet they would stop attesting devices that haven't been updated. But it isn't about device security, it is about ensuring that the device is controlled by a big corporation, not the user.

This banking apps requirement is laughable if you can manage you bank accounts through the internet browser. I mean there are some banks that only work with an app, but majority of banks in my country work through the browser just fine.

That being said, I have a separate phone just for bank apps and turn it on only when I need to use it for banking.

> This banking apps requirement is laughable if you can manage you bank accounts through the internet browser. I mean there are some banks that only work with an app, but majority of banks in my country work through the browser just fine.

Well, that's exacly why Google has proposed WEI - to make sure they no longer do, and the user is practically forced to have a device that has bundled Google spyware.

> WEI

Link so people don't need to go looking: https://news.ycombinator.com/item?id=36875940

Yeah, I have switched to a bank that is accessible via the web. But I fear that eventually they will all require an app.

I've always thought so too - who is banking on their phone?

And, loans aside, if I had money in a bank that forced me to change the way I live my life just to store money, I would move to a different bank and tell them that's why they lost a customer.

> I've always thought so too - who is banking on their phone?

Most people these days.

Have you never needed to transfer money when traveling or out of houseIf US, have you ever mobile deposited a check? If rest of world, have you ever sent money?

I use bank web site most of the time. But if not at home, it is really useful to use phone. It isn’t like banking is complicated that need computer and browser. Bank web sites tend to be awful on smaller screens, I don’t use it on iPad. Also, there are a lot of people that only have phone.

> Have you never needed to transfer money when traveling or out of house

No? It can wait for me to return home. Before wireless internet existed this wasn't an issue, so how has that changed things?

> If US, have you ever mobile deposited a check?

I admit this was literally the only time I used banking apps, but nobody uses checks anymore. I haven't needed to do this in years.

> If rest of world, have you ever sent money?

Yup, paypal website. Don't even need the app. Works better than venmo etc because it works internationally and various competitors that are app-only only work in 1 country anyway.

... Who isn't banking on their phone? That's how I do it 90% of the time.

> That was enough to get me to move to something where I am in control.

What smartphone OS are you referring to? Sounds interesting.

LineageOS with root enabled.

That gives you some control, but because lineage is mostly just using upstream android, and google's "contributions" to AOSP continue the overall decline of android, and the majority of apps adhere to google's behavioral demands of the play store, even lineageOS gets worse every year by way of it not being a hard fork of what was once a good OS.

Not that I have a solution to the problem. Just saying the current and foreseeable future state is that smartphones are past their glory days, and the platform defeated itself.

It is definitely not perfect. But having root does allow you to do most of what I want to do.

Unfortunately to participate in modern society you basically need iOS or Android, and iOS is far worse for user freedom. So I have taken the best option I could.

I also help "with my wallet" by preferring websites for everything that has no need to be an app. But I am sure that I am the minority.

In my opinion SafetyNet is no longer about security and is mainly DRM at this point. I think you are right on the money about the out of date devices too. I was going through my Dad's old phone collection this weekend and noticed that several old Android phones have specs that are not terrible today but are not useable due to no updates from the OEM. So now they are mostly e-waste. These are perfectly useable phones (maybe outside of an old battery) for basic tasks.

SafetyNet was always about DRM. The Play Store contains tons of malware despite SafetyNet, and malware does malware things despite SafetyNet.

Also, SafetyNet makes alternatives to Google Cloud e.g. for Backups non-viable, so win-win for Google I guess.

You are confusing SafetyNet with Play Protect. Play Protect is about protecting devices from malware. SafetyNet is about protecting services from "untrusted" devices. It is a remote attestation API that validates that the device is running a "trusted" operating system.

What backups? It's literally impossible to take backup images of an Android phone (as in: the entire thing, not just some Playstore apps and some of the settings).

The last phone I used that supported taking a backup image of the entire phone was a 2013 BlackberryOS 10 device.

You cannot even backup all of the playstore apps, tons and tons set the magic "don't backup" bit.

You are totally right in that there are basically no useful backups on android whatsoever. The closest thing is "adb backup" when you have root and developer settings enabled, which is saying a lot.

Even Firefox does this. Because of something something security.

Even adb backup isn't possible: it's been deprecated for years and I've never ever gotten it to work even with root and the right dev settings.

It starts creating an image of a couple of GB (takes a couple of hours, lol) and then just bugs out and stops. There's no error checking or anything and when it bugs out it means you have start all over again.

That makes so much sense. Back when I had a rooted device, I was once blocked from using... the Instant Pot app. Yes, a recipe app. It gave me a message saying something vague about security.

Security depends on your threat model. Your threat model and Googles are not aligned. They are protecting against threats you are happy to ignore or otherwise have other counter measures for. I think the real problem is assuming a one size fits all strategy works for everyone.

There are some ridiculous examples of apps refusing to run on rooted devices or custom ROMs. The Heathrow airport app, for example - why does an app which just shows me flight times and maps care at all?!

If an app shows maps, it usually won’t run on a ROM like LineageOS that lacks Google Play Services. This is because the API that app developers overwhelmingly use to show maps is the Play Services one, not the vanilla AOSP one. (I’m not even sure if AOSP has a map API.)

LineageOS with MicroG will run some of these apps and show a map using OpenStreetMap tiles provided by MapBox, but the functionality may still be broken because the MicroG’s maps support is not a full replacement.

In this case this isn't about lack of Play Services maps etc - the app looks for root and refuses to run if it sees it.

You want the honest answer?

Because security consultants slapped that on some checklist and Heathrow will now bugger contractors that build Android app to implement root checks.

Enterprise apps are full of this bs. I partially blame Google because it made checking for integrity so easy that every app owner now things it needs to use it.

> They say this is to ensure the security of your device that logs into your bank or whatever, but I guarantee that my LineageOS updated this week is more secure than my stock Google ROM that got its last update 3 years ago

Those are two entirely different threat models. The second clause of your sentence is about vulnerability to exploits, something that Lineage or other ROMs are at least better positioned to do than a vendor that has EOLed the device (though the amount of binary junk required by those distros puts a pretty firm cap on that promise -- they can only fix what they can patch!).

The first clause talks about the need for back end service providers to be sure that no entity is interposted between them and their users/customers. It's a desire that no extra app can sit there and sniff interaction or prompt for passwords/tokens/secrets/etc... Third party open ROMs not only fail to address this need, they actively hurt. You can trivially make a "We're Totally Your Bank We Swear" app and deploy it to a LineageOS phone that steals the money from any account that authenticates with it.

Is that a "good" security model or a "bad" one? There are arguments to be had. But prompt application of bug patches isn't one of them.

>In order to have a "certified" device you need to remove user control.

No, you don't.

>For example users by default aren't even allowed to access app's "private" data.

Which is already what Android's security model specifies. It means that other apps or other people using your phone won't be able to steal data like your 2FA app's private key.

>Those apps want to make sure that the user isn't in control of their devices, they want to make sure Google or a "trusted party" is.

Their app may benefit, or even rely on the android security model. Unverified devices have the possibility of having that security model broken.

>If Google really wanted to prove security with SafetyNet they would stop attesting devices that haven't been updated

I agree, but there is a trade off where you will cut out old devices. This is why at first Google lets app developers choose if they want to avoid devices that can just be spoofed.

> Which is already what Android's security model specifies.

Which means removing user control over that data.

> Unverified devices have the possibility of having that security model broken.

Again, this "security model" implies removing user control. The apps protect user's data from that user..

No user control is being removed. The data was managed by the app by design.

There is no way for the phone to know who owns the device, nor would it be able to know that when ownership is transferred to not show sensitive information to the new owner.

Let's not pretend to be daft. The user can prove ownership by providing a PIN. They can also delete their data before transferring ownership to a new owner. (Not to touch at all upon the fact that selling devices is really uncommon to begin with.)

Nothing about any of that requires the user to cede control of their own device as a "solution".

If the user writes down the PIN a person that is not the owner can use that PIN despite not being the owner.

The user should not write down a PIN then, or at least not write it down somewhere easily reachable by someone malicious. Attempting to hide data from the device owner is a non-solution to this problem and does nothing but frustrate and diminish the device owner's freedom.

You can't as a phone ensure that happens. The device is more secure by taking away the backdoor of using a PIN. Backdoors are a security incident waiting to happen.

the more they move towards apple levels of control, the less reason people have to sick with android.

I use android because I dislike the Apple ecosystem and UI design. They could disable all side-loading of apps and I would still use Android because I just don't use mobile as my primary driver. For me, phones are for texting and browsing Reddit while I shit.

Hah, I have exactly the opposite reaction as you: I think Android is a complete mess in terms of usability.

The big differentiator, though, is your social network. Having iMessages and FaceTime is about 95% of the value of the phone/tablet for me because my friends heavily, heavily use them.

I use Line (kind of like a Japanese/Korean whatsapp) to communicate with my wife's family (Wife, sisters in law, mother in law), I use Facebook to communicate with my parents, and I don't have any friends to communicate with on other platforms, so I don't miss iMessage (maybe I don't have friends because I don't have iMessage).

Otherwise the apps define most of the UI. Android is basically an app launcher to me.

I think it's the case of knowing what you know. IOS design language depends a lot on being familiar with iOS already - I think a lot of Android design is dictated to be understandable by people who really haven't used a phone before so things are a bit clearer and more obvious. I know when I use my wife's iPhone it's so frustrating because it feels like you should be able to do action X but there isn't any clear way on how to achieve it - I ask my wife and she shows me that it's hidden behind some invisible menu or gesture and I'm like "how were you supposed to know this???" And she just shrugs "it always worked like this". Ok, I guess, but that's really poor for discoverability.

> I just don't use mobile as my primary driver. For me, phones are for texting and browsing Reddit while I shit.

That's the reason I use an iPhone. I don't need a bunch of customization and homescreen tinkering, I just want a thing that gets the job done and is easy to troubleshoot.

I want the same thing, but which also isn't an Apple product

It really makes me think... should we all have bought into blackberry/palm/windows' smartphone efforts in the 2010s? They seemed inferior at the time but, in hindsight, it's hard to imagine anything worse than where we are now.

The Nokia Lumia 1310 was the best phone ever made. Best UI, best screen and Camera of its generation, and you could program apps in C# for UWP so they ran on Desktop or Mobile (For that reason, there are still hobbyists who sideload new apps on their Lumias since the SDK still exists and works on modern windows). Like all things, Microsoft made the best version of the product, but not the most successful version

But you don't HAVE to do those things on Android.... My Pixel is exactly that, gets the job done without problems or fuss.

not sure how typical I am, but I don't buy android for really any other reason than I can get brand new smartphone that does everything I want for under $200 and has multiple sim slots (which makes international travel much easier)

At this point apple or anyone else would have to beat the cheap android handily for me to consider switching and that seems like a tough market to beat. I'm always impressed by how well cheap androids work when compared to their 3-4x more expensive counterparts.

You can pick up second hand ( good condition ) iPhone's for not much more. I would also then argue iPhone's last longer and tend to get more updates for longer than their android counterparts.

They can support multiple ESim's now which I've had fantastic experience with when travelling abroad. Apps like Ubigi make it super easy to switch to a local sim.

The problem with used iPhones is that the hardware is still powerful enough to run modern iOS, the battery only has about a year left to live so unless you budget in a battery replacement, you're basically tethered. This may finally be clearing up, but Apple's iPhone batteries from the previous decade were abysmal and had no headroom for aging. That's why they were doing the stupid downclocking of older iPhones, because the battery could no longer deliver the power to run full bore without browning out.

Lots of people choose Android entirely unrelated to control - especially as this change apparently only affects users of rooted Android devices, which are an extremely small minority of Android users. Other reasons include price, interop with other non-Apple devices, and just a preference for the usability of Android vs iOS.

But phones are a duopoly for the average person. What would they leave android for?

I'm so sick of this.

I don't feel like I own my devices anymore.

Don't worry, you don't. Just wait until they lobby and make it illegal do to do so! This will come under one of the following guises:

1. Save The Children

2. Save The Planet

3. Save the Tax revenue

4. Anti-Terrorism

Why not buy a phone with known good LineageOS support if you're afraid Google may update your phone? You can audit and compile the entire OS yourself and disable any CA certificates you may dislike.

Or. Hear me out. Why don't these companies actually give me back the ability to control my devices? Why is the onus on me? Why don't these fuckers do the right thing. So tired of this what-aboutism bullshit.

You're buying their phones, not the phones of companies that give you full control. Most customers care more about not having to wonder about security than about having the ability to flash a new kernel.

Show companies that there's money to be made by buying devices to your liking or you'll be subject to design decisions made for the vast majority of customers. Why should companies care about your specific wishes over everyone else's if you're not putting your money where your mouth is? They exist to make money, they're no government or charity.

Everybody has been screaming at Google about how Google can't keep Android up to date since Android 2.1 launched. The geneewl comsensus is that if you wqnt updates and security, you need to buy an iPhone. They're finally fixing this problem but every step along the way the percentage of a percentage complains that they're the victim of Google's conspiracy.

Obviously governments can't have an operating system where users can do as they please, e.g. bypassing government mandated MITM certificates so they can spy on citizens.

So the groundwork is being prepared for coming things like Online Safety Bill here in the UK, where all communication will likely be under surveillance and so you won't be able to mod your phone to "opt out".

It's a shame that such resourceful company like Google bends over to some control-freak right wing governments like we have.

> It's a shame that such resourceful company like Google bends over to some control-freak right wing governments like we have.

Why wouldn't they? They obviously see an opportunity to grab even more control over the Internet than they already have.

It's strange that you jump straight to thinking the government is involved. Moving most system components to be updatable independently of the core os is a good thing. Google should be taking these steps. Not being able to update apex files makes sense as any update will quickly overwrite your changes.

This change just moves the bar for modification to be controlling the remote update source. I'm sure it will still be possible to alter that and therefore gain control. This would be similar to how you handle DNS.

Do you consider the Democrats right-wing? How about the CCP? Authoritarian, sure, but there is authoritarianism on both ends of the political spectrum.

American democrats would be considered right wing in other nations e.g. europe

Kazakhstan actually tried a government mandated CA certificate. It's causing constant "you are being watched" notifications on phones that loaded the certificate. Certificate security was increased in Andeoid and other opeeating systemsm exactly because of this threat.

Every OS except Android receives regular CA updates, including them various Linuxes. Android devices are still trusting known bad actors like Startcom exactly because there's no way to update just the CA store (and cheap Chinese brands definitely won't release full system updates for this after dropping support a year after the phone came out).

You can disable the toggle for every system CA in your phone's settings if you want. That is, unless you think the big bad UK government bugged your phone to hide the CA that's been planted there, but if that's part of your threat model, the government certificate may be hidden on your phone already

Reply on news.ycombinator.com