With Rust development surpassing C++ in the Android platform in 2025, we can start making reliable comparisons across a number of important metrics, such as developer velocity and overall quality of changes.
Lots of great data in here, including rollback rates, code review latency, vulnerability density, and a CVE with a twist.
https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html
Open up your Android phone’s Settings app and you’ll find dozens of different options with little guidance on what those options do. Some of these settings have a serious impact on your privacy and security, altering what data gets shared automatically with apps, data brokers, and Google itself. What sorts...
📰 Risky Biz News: The EU will make vendors liable for bugs
https://news.risky.biz/risky-biz-news-the-eu-will-make-vendors-liable-for-bugs/
One of my coworkers listened in and had some interesting takeaways:
1. The practicality of the Android team in tackling a problem: working incrementally right away without trying to solve for everything, and how that's almost always the right approach when you're doing big changes like this.
2. The shift away from being attacker focused: how that's applicable to more of security than just memory safety. I.e., don't focus on making the attacker's life harder by constraining yourself to their playing field, but rather focus on making the defender's life easier by focusing on the things that we control
3. It's more expensive to clean up a mess than to prevent the mess: It doesn't follow directly from the blogpost, but it's essentially the difference between "build something in a MSL" (developer-focused) or "build something in an unsafe language, and go and tack on a bunch of mitigations afterwards" (attacker-focused)
I joined @durumcrustulum and @tqbf on the Security Cryptography Whatever podcast to talk about our latest blogpost:
https://securitycryptographywhatever.com/2024/10/15/a-little-bit-of-rust-goes-a-long-way/
https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html
Something that Thomas said in the podcast really stood out to me. He said “the blog post undersells it. …. This is a lot more interesting than it looks like on the tin.”
I agree with this. It feels like we discovered a game-changer not just in memory safety, but in security more generally - that doing something very practical results in major security improvements for non-obvious reasons. Focusing on new code is disproportionately effective, exponentially.
Thomas also said “And that observation about the half life of vulnerabilities, if that’s true, says something pretty profound about what the work looks like to shift to a memory safe future.”
Or as Deidre said: “You can get really big bang for your buck, which is if you have something new, just write it in the Rust or another memory safe language and make it interop with the rest of your project and you will in fact, get really good returns on mitigating your memory safe vulnerabilities, which is the majority of your vulnerabilities, period.”
Agreed. We’re already prioritizing differently based on this data. It was a fun conversation, and we believe that it applies to a lot more than just memory safety.
I’m super excited about this blogpost. The approach is so counterintuitive, and yet the results are so much better than anything else that we’ve tried for memory safety. We finally understand why. https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html
I’m super excited about this blogpost. The approach is so counterintuitive, and yet the results are so much better than anything else that we’ve tried for memory safety. We finally understand why.
https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html
Bram Bonné
Electronic Frontier Foundation
Joe Groff (1M Context)
Risky Business® Media
Alex Rebert
Wendy Nather