As someone who's spent a good amount of time hacking various devices, I have an odd split mind on security. I detest activities such as those of the NSA and more traditional malware authors and think it would be great if people could trust their computers (never mind that I like sci-fi and wonder whether we will sort this out by the time computers store people's brains and whatnot). But then there are cases like iOS where compromising the system really can be for the benefit of users... but iOS vulnerabilities can be and are used for nefarious purposes (in fact, one of the recently leaked documents mentions that the NSA once used one of my jailbreaks), and jailbreaking has become necessary for fewer and fewer use cases over the years - if I want an open system so much why don't I switch to an Android phone that I can unlock legitimately, without depending on vulnerabilities? It doesn't seem like there will be a scarcity of those in the near future... Should I feel proud of having gotten vulnerabilities fixed by using them in jailbreaks, or guilty that I attempted to maximize rather than minimize the exposure window? And then emotionally, there's a big part of me that always roots for things to be insecure, since hacking is fun and represents a fairly big part of my life. I think I should take joy in the prospect that I might become obsolete (especially since that won't happen for a long time no matter what I do :p), but it's hard to actually feel that way.

Anyway, there are a few recent developments which make me feel somewhat anxious, which I guess means they're good. Among them are Rust and seL4.

Rust, which I'm quite enthusiastic about when not in a hacking mindset, could be one of a few languages that can get rid of the assumption that fast/small/light tools have to be written in C or C++ and thus memory unsafe. To name a particularly egregious case, it strikes me as ridiculous that OpenBSD's ntpd feels the need to include a privilege separation feature, despite being a low-thousands-of-lines implementation of a tiny protocol; I mean, there are probably no vulnerabilities in that particular codebase anyway, and given a danger, being paranoid is a good thing - but in the context of the complexity of something like NTP, we have so many CPU cycles to spare that programs simply should not be a typo away from magically turning malformed input into arbitrary code execution. (To be fair, high-level languages have their own vulnerability classes which might allow the same, but at least you're not constantly teetering on the edge of the cliff. Well, unless the language is bash :) And of course Rust is aimed at far more performance critical scenarios - they aim to build a whole browser which is competitive with existing ones performance-wise while being mostly safe code.

seL4 as a product is overhyped: the kernel they verified is tiny, and the proof enormous. It will be a long, long time before a significant fraction of the code running on a production system will be formally verified. However, whereas before there was always a hope of finding a critical bug in even the innermost low level bits of every system... well, now there is one system where that's theoretically impossible. That's a step. Perhaps, slowly but surely, there will be more steps, more places created where bugs (even logic errors, panics, and other types not caught by languages like Rust) cannot lurk. In the long run, that's certainly the type of software I want running my brain!