One practical technical problem that also has direct "peace on earth" implications is getting software that reliably doesn't have exploits into the hands of opp

One practical technical problem that also has direct "peace on earth" implications is getting software that reliably doesn't have exploits into the hands of oppressed people (or, equivalently enough, of all people). If you're a human rights lawyer working with the Uyghur people, you should be able to use a secure end-to-end messaging app and not be hacked. We've done very well with end-to-end messaging as a cryptographic formulation - now we just need to get the vulnerabilities out of WhatsApp and the iOS kernel and similar, so you can't just get NSO's Pegasus thrown at you when someone wants to dump your clients in re-education camps. In my opinion there are two big angles here. One is memory safety, which is the primary cause of remotely exploitable vulnerabilities these days (see https://twitter.com/LazyFishBarrel https://twitter.com/LazyFishBarrel for some stats). Any evidence-based approach that reliably reduces memory unsafety bugs is productive - whether that's "rewrite it in Rust," "rewrite it in Go," "rewrite it in Python," "rewrite it in Java," "write really good C static analysis tools," etc. The other is getting software updates into people's hands for a reasonable price. If you buy a cheap Android phone, you're buying an insecure Android phone. There are few options for a cheap iOS phone, especially one that's still receiving security updates. See https://googleprojectzero.blogspot.com/2019/11/bad-binder-android-in-wild-exploit.html https://googleprojectzero.blogspot.com/2019/11/bad-binder-an... for a good analysis of a combination of these two problems, specifically weaponized in the wild by NSO Group. One part is that it's a use-after-free. The other part is that it was fixed in Linux, and it didn't make it into Linux for two years. If I had a large team of serious hackers at my disposal to solve problems for the world, I would work with some of them to fix the highest-risk code written in memory-unsafe languages and get the fixes upstream, and I would work with the rest of them to fix the various process problems that make it hard for Android vendors to upgrade to new versions of Linux and other components continually. (Note that both of these problems are really best solved by a team that can continue working on the problem indefinitely, not a strike team that delivers a thing and then declares the job done.)