3 ms·

You are expecting and hoping that it will act the same as desktop environments do. Desktop environments can't/don't because there is an inherent expectation of

You are expecting and hoping that it will act the same as desktop environments do. Desktop environments can't/don't because there is an inherent expectation of users that they should work a certain way and they are built upon decades of neglectful security practices. Mobile OSes are the attempt to change that and provide better security models from the ground up. AOSP being open-source is what gives you the actual control to modify your platform as you see fit, not having runtime root access exposed to the user. The idea of "control" that you are describing is illusory and only serves to actually undermine your real control. If you expose root access in that way, you have a much lower guarantee that the rules and permissions that you set are going to be able to be enforced by the system, because you have allowed the system to be modified. If something malicious gains that access, you have lost that guarantee.

TeMPOraL 6d ago
> You are expecting and hoping that it will act the same as desktop environments do. Pretty much. > Desktop environments can't/don't because there is an inherent expectation of users that they should work a certain way Yes, and many of those expectations are exactly how computers are supposed to behave in general. > and they are built upon decades of neglectful security practices. That is true, but: > Mobile OSes are the attempt to change that and provide better security models from the ground up I strongly disagree with unqualified "better" here. Better for whom is what matters, and mobile OSes are security-maxxing in the direction that's - IMO - bad for users. They're optimizing for market ecosystem. > AOSP being open-source is what gives you the actual control to modify your platform as you see fit, not having runtime root access exposed to the user. That I vehemently disagree with, in two dimensions: - Open-source as panacea to everything is a bullshit belief techies overindex on. OSS has long been defeated, SaaS killed it. Whether code is open source or not is immaterial, what matters whether this particular code executing on this particular machine I use is open to me, which is not - and I can't even guarantee it's the same code that's supposedly "open" on some repository somewhere. - "having runtime root access exposed to the user" is precisely what freedom of computing means. That is the one thing that matters. > If you expose root access in that way, you have a much lower guarantee that the rules and permissions that you set are going to be able to be enforced by the system, because you have allowed the system to be modified. If something malicious gains that access, you have lost that guarantee. Wrong. I have a much higher guarantee, because the alternative is that I cannot set any rules at all. Per basic math, "very little" is still greater than 0.
- skorp01 6d ago
  The expectations of desktop platforms to behave the way they do is a holdover of early computing not giving much regard to malicious actors. Having a system where you can run a binary and grant it admin/superuser permissions, giving it widespread and dangerous access across the entire system, isn't how I personally want to do my computing. You seem to be conflating the ecosystems (which I concede are largely profit-driven), and the platform architecture. The security models that include sandboxing, MAC/SELinux, Verified Boot, and many more; are unequivocally pro-user. I get it seems like we're speaking of totally different things but hopefully I can bridge that. You having "freedom" to have runtime root access means that any malicious actor, rogue binary, etc. also has that freedom to run amok on your machine and that access cannot be so easily taken back. I don't know how to respond to your comment about rules other than to say that it's incredibly easy to demonstrate being wrong. Mobile OSes like AOSP have a much better ability for you to set rules. Access permissions for microphone, camera, other sensors, network, filesystem, are HEAVILY gated by the system which enforces the rules that you choose to set. Desktop platforms are largely ill-equipped to handle this and are highly permissive. In fact, desktop OSes are frantically trying to copy mobile OS architecture: MacOS SIP, flatpak, Wayland, Windows Virtualization based security, the list goes on and on. Runtime root access would allow a malicious app to silently bypass every rule that you think you've set. It does the exact opposite of guaranteeing those rules.

TeMPOraL 6d ago

> You are expecting and hoping that it will act the same as desktop environments do. Pretty much. > Desktop environments can't/don't because there is an inherent expectation of users that they should work a certain way Yes, and many of those expectations are exactly how computers are supposed to behave in general. > and they are built upon decades of neglectful security practices. That is true, but: > Mobile OSes are the attempt to change that and provide better security models from the ground up I strongly disagree with unqualified "better" here. Better for whom is what matters, and mobile OSes are security-maxxing in the direction that's - IMO - bad for users. They're optimizing for market ecosystem. > AOSP being open-source is what gives you the actual control to modify your platform as you see fit, not having runtime root access exposed to the user. That I vehemently disagree with, in two dimensions: - Open-source as panacea to everything is a bullshit belief techies overindex on. OSS has long been defeated, SaaS killed it. Whether code is open source or not is immaterial, what matters whether this particular code executing on this particular machine I use is open to me, which is not - and I can't even guarantee it's the same code that's supposedly "open" on some repository somewhere. - "having runtime root access exposed to the user" is precisely what freedom of computing means. That is the one thing that matters. > If you expose root access in that way, you have a much lower guarantee that the rules and permissions that you set are going to be able to be enforced by the system, because you have allowed the system to be modified. If something malicious gains that access, you have lost that guarantee. Wrong. I have a much higher guarantee, because the alternative is that I cannot set any rules at all. Per basic math, "very little" is still greater than 0.

skorp01 6d ago
The expectations of desktop platforms to behave the way they do is a holdover of early computing not giving much regard to malicious actors. Having a system where you can run a binary and grant it admin/superuser permissions, giving it widespread and dangerous access across the entire system, isn't how I personally want to do my computing. You seem to be conflating the ecosystems (which I concede are largely profit-driven), and the platform architecture. The security models that include sandboxing, MAC/SELinux, Verified Boot, and many more; are unequivocally pro-user. I get it seems like we're speaking of totally different things but hopefully I can bridge that. You having "freedom" to have runtime root access means that any malicious actor, rogue binary, etc. also has that freedom to run amok on your machine and that access cannot be so easily taken back. I don't know how to respond to your comment about rules other than to say that it's incredibly easy to demonstrate being wrong. Mobile OSes like AOSP have a much better ability for you to set rules. Access permissions for microphone, camera, other sensors, network, filesystem, are HEAVILY gated by the system which enforces the rules that you choose to set. Desktop platforms are largely ill-equipped to handle this and are highly permissive. In fact, desktop OSes are frantically trying to copy mobile OS architecture: MacOS SIP, flatpak, Wayland, Windows Virtualization based security, the list goes on and on. Runtime root access would allow a malicious app to silently bypass every rule that you think you've set. It does the exact opposite of guaranteeing those rules.