Had a discussion with the @White Noise team about how they could improve especially in a security and privacy standpoint. The post and article below discuss a small part of the efforts made. These provide substantial security improvements while having no added overhead or friction to the user. If your application handles media, it's important that functionality is sandboxed and designed in a memory safe language. White Noise currently isolates image decoding in this way but now this has also been expanded to animated images as well. You can find out more below. Memory tagging (MTE), a ARM hardware exploit protection used heavily by GrapheneOS and latest generation iPhones are now opted in the app manifest. This makes it unable to be disabled in GrapheneOS and also enables it for capable phones enrolled in Android's Advanced Protection. The issue tracker also now tracks working on a few improvements, including adding this sandbox for other types of attachments too. I've also discussed on a improving accessibility features.
Max's avatar Max
White Noise for Android 2026.10.27 decodes GIF and WebP animation in a permissionless worker, away from account data and group keys, and requests native heap memory tagging checks on MTE-capable phones, so a malicious animated image has far less of your private data within reach. Thank you to @npub1hxx7...g75y for the conversations that inspired this hardening. View article โ†’
View quoted note →

Replies (7)

I am strongly for more native apps for Android made with Kotlin and Compose being developed. You get the best compatibility with our security hardening and generally the best performance. You shouldn't consider what I talk about to be a direct recommendation of what you should use to communicate with someone. GrapheneOS doesn't have any apps bundled for a reason, it's down to the user to choose what's right for them.
Will it be put on Accresent?
Max's avatar Max
White Noise for Android 2026.10.27 decodes GIF and WebP animation in a permissionless worker, away from account data and group keys, and requests native heap memory tagging checks on MTE-capable phones, so a malicious animated image has far less of your private data within reach. Thank you to @npub1hxx7...g75y for the conversations that inspired this hardening. View article โ†’
View quoted note →
Sandboxing the decoders is the part that matters most. Image parsing is where a note stops being text and becomes an executable surface; libwebp, giflib and libavif all have a history of heap corruption reachable by opening one file. One caveat on MTE: it detects, it does not prevent. A stray write still happens, the process just dies instead of quietly corrupting memory. With four-bit tags, roughly one in sixteen wild pointers carries the matching tag and slips through anyway. Memory-safe parsing stays the floor, MTE is the net under it. What is left once media decoding is boxed off is the container work in front of the decoder, and that is usually the widest hole.
Yes, whatever size limit is on the blossom server will be there too. It's not really optimized for large files.
โ†‘