gradeless

Its buggy apps. Ive been using MTE for pretty much all the apps on my GrapheneOS phone for 3 years without any problems.

2 apps have C++ libraries and MTE makes these crash due to memeory bugs, so I disable MTE for these.

Very little if anything at all. Depends a bit how you draw the line between an app and the base OS. Contactless payments dont work with Google Pay - but that is due to Google using attestatiom to check if the OS is GMS lincesed (GrapheneOS is not). There are alternative contactless payment options that work fine.

Ive had MTE enabled on GrapheneOS for the past 3 years for pretty much all apps I use without any issues.

Theres a couple of apps that use C++ libraries for which I disable MTE.

Most android apps using Java or Kotalin which hugely helps with avoiding buggy apps crashing with MTE enabled.

Android can and does regularly force developers to make changes to their apps to improve privacy and security on the platform. Like theyve done with other changes they could gradually force developers to fix bugs in their apps. Maybe offer a MTE opt out for apps that use memory unsafe languages.

Think its likely Apple and Google will increasingly push forward the use of MTE in Android and iOS

Yes it will take many years. This whole thing has already played out with FSF and Replicant. They ended up stuck working on a couple of ever aging devices as many new generations of devices were launched and all the technologies in smartphones evolved.

If people want open devices they should maybe better explore open hardware. Im not talking about devices, like Librem where the schematics are open but the chips, which are the parts which do all the work, are all closed, but rather devices with open silicon.

All android devices launched with android 15 or newer need to support Android Virtualization Framework. So there will be support for VMs.

>GrapheneOS can not do anything about that.

GrapheneOS does not include any of the Google apps that implement Play Protect. You can install them, but they run in the sandbox like normal apps and so are not highly privileged. They are unable to block installation of apps, install apps or uninstall apps as they are on stock Androids

GrapheneOS recently added toggles to work around this https://grapheneos.org/releases#2025100300

Rethink DNS app provides the ability to do that. Also can use it to connect to any Wireguard VPN and also monitor connections.

There are various apps that either connect directly to an IP address or do DNS resolution themselves to sidestep this kind of blocking. Rethink lets you stop apps making these kind of connections bypassing DNS and whatever DNS filtering you have set up to control their connections

What if you truly want the security properties provided by a device which can keep keys in a way where you fully control their use but its extremely hard for anyone to extract them?

Theres been a consistent pattern of both low quality and advanced malware looking for and targeting the weakness introduced by rooting a device.

Here is a recent report of widespread advanced malware looking to see if a device is rooted - https://www.lookout.com/threat-intelligence/article/badbazaa...

Here is a report of malware using root - https://zimperium.com/blog/new-advanced-android-malware-posi...

Root does not only provide privilege escalation, it also provides attractive options for exploit persistence on a device, something which is difficult to achieve on modern Android and iOS.

Ive been using GrapheneOS for years and was in the chat rooms a fair bit, this isnt something common. Sounds like it may be hardware failing.

Having bootloader locked you get verified boot, big security benefits and automatic healing of operating system files damaged by the drive degrading.

Not sure if you've used GrapheneOS recently? If apps are heavily tied to Google Play Services you can install that and, in the vast majority of cases, get very good compatibility.

Compatibility with carriers also improved a lot a few years ago. Configurations for most carriers are pulled in from the stock Pixel OS. Some US carriers do weird things that depend upon having highly privileged apps bundled into the OS which, for security reasons, GrapheneOS doesnt include. I dont recall AT&T being one of them.

GrapheneOS is very usable and fine as a everyday phone for normal people.

Or you couod look at using an android operating system which also supports bootloader relocking, but that doesnt have a history of repeated significant delays rolling out security patches https://privsec.dev/posts/android/choosing-your-android-base...

Some apps suggest they use it when they dont. Some (most) apps use a weaker form which an android/AOSP operating system can comply with, without being registered with Google (licencing Play Services) see eg. https://grapheneos.org/usage#banking-apps Very few apps use the full strict version of safetynet that requires hardware attestation

It used to be the case that iphones were way ahead of security in android. With the efforts that have gone into improving things in the last few years and Google stepping up the quality of their hardware security with their Pixel lines that is no longer the case. iPhones also have nasty (sometimes unpatchable) vulns. Android gets ever stronger protections against malicious apps, doesnt rely so much on Malware being screened from the store (malware regularly gets through onto both Play Store and Apples App Store)

The writeup of the bug states that it was patched in the January update for Pixels, which GrapheneOS has. But previous work on applying mali patches early led to GarpheneOS having a fix earlier than stock Pixels https://github.com/GrapheneOS/os-issue-tracker/issues/1914#i...

While its likely Cellebrite make use of some known (and possibly some unknown) exploits to bypass the screen lock on some phone models and get at user data, sometimes they require the device to be unlocked and doubtlessly make use of adb to pull out user data.

Encryption on Android devices has changed over the last few years, introducing the possibility for File Based Encryption FBE, later making in mandatory. File based encryption enables apps to use keys to encrypt their data that are flushed when the screen is locked. Many security concerned apps like password managers and OTP apps make use of this.

If you feel the need you can use 'multiple users' to create an extra user or use a work profile (Island, Shelter, Insular) to keep sensitive apps and data. These have seperate encryption keys that are flushed upon switching off the work profile or restarting the phone (for multi user). You can still use the main user on the phone with the work profile/multi user encryption keys not held in memory.

Theres a lot more to the android app sandbox than just running processes as seperate users. Theoretically something similar could be implemented in some other 'typical linux system'. It would be a huge undertaking. If you are thinking about security need to consider not only malicious apps, but possible attack vectors opened up by any application. This paper is a couple of years old, it explains how it all works on Android https://arxiv.org/abs/1904.05572

There are endless launcher apps and icon packs you can get from F-Droid or elsewhere if you want to change the look of your phone. AnySoftKeyboard is the keyboard on F-Droid with the most features

Magikeyboard is a function you enable in KeepassDX. Gives you an extra 'keyboard' you can switch to just for entering passwords. Stops other apps being able to swipe your passwords from your clipboard.

This is what CopperheadOS has become. Trading off the reputation they gained from before the split.

When they were still publishing their sources they were often lagging months behind with basic AOSP security updates. Still not updated to Android 11 yet, 2 months since it was launched, which, as they support Pixels, means they now have 3 monthly updates worth of device specific security patches that can't of been applied.

GrapheneOS moved to 11 in September, not so long after it was released by Google