[noirscape]

A lot of mobile software is just a UI around an external web API. The main reason why Android makes it difficult to get the OS to accept an external certificate (you need root for it) is because without it, you can just do a hosts hack through a vpn/dns to redirect it to your own version of that API. Which app manufacturers want to prevent since it's a really easy way to snoop on what endpoints an app is calling and to say, build your own API clone of that app (which is desirable if you're say, selfhosting an open source server clone of said software... but all the official applications are owned by the corporate branch and don't let you self-configure the domain/reduce the experience when you point it to a selfhosted domain).

It's extremely user-hostile since Android has a separate user store for self-signed CAs, but apps are free to ignore the user store and only accept the system store. I think by default only like, Chrome accepts the user store?

[Arch-TK]

Android locking the system certificate store has nothing to do with preventing people from intercepting app traffic for the purpose of inspecting an application and everything to do with preventing people from accidentally installing a malicious certificate which allows part or all their traffic to be MITM-ed.

[thaumasiotes]

Those are literally the same thing.

[Arch-TK]

No, there are legitimate reasons to install a certificate to intercept traffic as an owner of a device. But the same tools can be abused by malware and by malicious actors to intercept traffic. Its the same in a strictly technical sense but not the same in the intent sense. The intent is to prevent malicious abuse of the feature, not justified non-malicious use. It helps make it harder to intercept application traffic but this is not the intent of the restriction, merely an unintended consequence.