[rst]

Chain of trust won't reduce the attack surface, but adopting memory corruption mitigations and replacing C code with something with stronger memory-protection guarantees would -- and while some kinds of memory protection can be bolted on later with minimal disruption, minimizing C is best done from the start.

[letstrynvm]

That sounds reasonable, but here we are with Android's endless security disaster and all their apps written in not-Java from the beginning.

The most cancerous aspects of Android are by design, that you cannot control network exfiltration from apps, you cannot update or modify the OS pieces at will, and the apps are monetizing everything you do and everything they can find against you. Librem will answer these.

[strcat]

> that you cannot control network exfiltration from apps

GrapheneOS has a Network permission toggle, which is one of the features already restored from the past work on the project. There are many other privacy and security features that still need to be ported to the latest release, although a lot of them have become standard features especially in Android Q. https://gist.github.com/thestinger/e4bb344dcc545d2ee00dcc22f... is an overview of the Android Q privacy improvements(not security improvements, just privacy) in the context of GrapheneOS. To conserve development resources, the past features that are becoming standard aren't going to be ported over rather than just waiting for the standard implementations being released around August. Some of them will need to be adjusted to make them a bit more aggressive when it comes to apps targeting the legacy API level, but that's a lot less work than maintaining downstream implementations of all of this.

> you cannot update or modify the OS pieces at will

Having a well-defined base OS with verified boot and proper atomic updates with automatic rollback on failure is a strength, not a weakness. It's the same update system (update_engine) as ChromeOS. The update system is not the problem with the broader Android ecosystem with lack of updates to vendor forks. The migration towards everything being apk components that can be separated updated rather than moving more towards the ChromeOS design is a negative thing in terms of GrapheneOS and it's one of the things that has to be changed downstream to improve verified boot.

> Librem will answer these.

That's nonsense. First of all, that's hardware, and also moving to a far less secure software stack with non-existent privacy and security, an inferior update system and no verified boot is not a solution to these problems. The solution to privacy and security problems is not completely throwing away privacy and security...

[bubblethink]

>The migration towards everything being apk components that can be separated updated rather than moving more towards the ChromeOS design is a negative thing in terms of GrapheneOS

Doesn't stuff like fs-verity help with stuff like this instead of just a block based RO partition that can be verified ? Overall, for the android ecosystem, it seems like a net gain if google moves more and more stuff out of band away from OEMs as OEMs are not incentivized to do anything other than sell devices. That is, as long as everything is still pushed to AOSP.

[eeZah7Ux]

> not security improvements, just privacy

Privacy is security!

[pjmlp]

Large majority of Android security exploits are in C and C++ written drivers, hence why with each release the amount of freedom with native code gets further locked down.

Android Q has another round of such measures.

https://android-developers.googleblog.com/2019/05/queue-hard...

[mpol]

Those may be security exploits, but the real malware is what gets installed through Google Play.

[maroonedanchor]

Hence a Play Store free alternative like GrapheneOS.

[pjmlp]

Nothing can be done to prevent stupid users to install everything that shines.

Even HNers do curl | sh without thinking twice about it.