Hacker Newsnew | past | comments | ask | show | jobs | submit | gradeless's commentslogin

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.


Moving the goalposts to "it's not their fault that it doesn't work" doesn't really change it doesn't work.


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.


Can you name such devices? Precursor?


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

The issue is more that GrapheneOS still allows apps to view OS attestation information[0], which is similar how Play Integrity API attempts to prevent you from running on your own OS. The specific feature I'm referring to which is the problem is the Play Protect API which allows apps to inspect the host system bootloader/TPM state essentially. The problems with giving any apps(even webapps) access to this sort of attestation information are well documented[1] as it encourages app developers to lock out legitimate users who want to run unofficial operating systems. Effectively breaking this app verification capability is what is needed to prevent app developers from enforcing arbitrary security requirements on the host OS. Essentially GrapheneOS just wants app developers to trust their keys in the same way Google wants you to trust theirs(using the Play Integrity API).

[0] https://grapheneos.org/articles/attestation-compatibility-gu...

[1] https://en.wikipedia.org/wiki/Web_Environment_Integrity#Rece...


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


Apps mainly avoid it because their most privacy invasive features are tied to their functionality and their own servers. They can share with third party server side and mainly do that. Client side stuff is mainly far less important analytics, telemetry, crash reporting, etc. If the app or SDK wants to evade filtering client side, they just need to do their own DNS resolution via DoH using a hard-wired IP whether it's 1.1.1.1 or their own server. Facebook has IP fallbacks in several of their apps.


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?


I mean case in point, this is exactly what a Yubikey does for people.


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.


> Here is a recent report of widespread advanced malware looking to see if a device is rooted

Okay? I do actually think that should be blocked (good root is invisible), but I'm not seeing a problem.

> Here is a report of malware using root

To quote the article:

> In addition to collecting the messages using the Accessibility Services, if root access is available, the spyware steals the WhatsApp database files by copying them from WhatsApp’s private storage.

Note that it already uses a11y features to do the same thing regardless, but also this is another case of conveniently skipping all the important details. Seriously - "if root access is available, the spyware steals" - how did it get root access? If the "vulnerability" is that the malware asks the user for root access and the user gives it, that is not a vulnerability. A system where malware needs permission to do bad things is perfectly fine.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: