lol of the day -
EU warns X that it may calculate fines against X by including Elon Musk's other companies' revenue; the DSA can fine 6% of global annual revenue
Mastodon Digest
Posts
I remember some people expressing how annoyed they were with people reimplementing standard command line tools in Rust. But here is the reality of such reimplementations: https://hachyderm.io/@cliffle/113320811488346900
It isn’t just the memory safety. The reimplementations typically turn out much simpler, partly because of a more high-level language and partly because of usable dependency management.
If you have 20 times less code to maintain, you can do a lot more with it. Adding “nice to haves” like output coloring in C requires considerable effort, improving usability of these tools in Rust on the other hand is a no-brainer. That’s e.g. why duf and dust can present the output better than df and du.
And there are performance wins at almost zero cost. That’s partly due to relying on well-optimized libraries instead of own reimplementations (yes, dependency management again). But taking advantage of multi-threading and modern CPU features seems much easier in Rust as well.
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.
LinkedIn needs to come with a blood pressure warning.
Boosts
As a kid I often wondered how the Germans could allow the Holocaust to happen. In the past year I've heard all the reasons why.
- "I don't want to lose my job"
- "It will cause friction in my family"
- "Both sides are bad"
- "This isn't my issue to speak about"
- "I'm too busy"
- "I don't care about politics"
Don’t know who needs to hear this today (besides me!) but here you go :blobfoxheartcute:
