For anyone who's interested in a technical writeup of the implementation, I did one here: https://mjg59.dreamwidth.org/66791.html https://mjg59.dreamwidth.org/6

For anyone who's interested in a technical writeup of the implementation, I did one here: https://mjg59.dreamwidth.org/66791.html https://mjg59.dreamwidth.org/66791.html . There's code in the iOS app that would mitigate the MITM issue, but would also restrict users to only being able to read encrypted DMs on a single device, and it seems like they decided functionality was more important than security in this respect (which is not an unreasonable tradeoff, as long as it's well-communicated to users). Group conversations are also unsupported in the deployed codebase, so the concerns I had there may end up handled in some other way (though it's going to be difficult to manage that and also retain reasonable user experience). The perils of reviewing code before you can actually test the feature. Overall I think my original conclusion still holds. If you're going to use Twitter DMs, turning on encryption is better than not doing so. But right now it's protecting against someone with opportunistic access to the Twitter prod databases, not an advanced attacker or someone with subpoena powers, and if you have to worry about that you should definitely use Signal instead. (Edit: someone asked whether working on fruitflies would have been more relaxing than reverse engineering weird encryption, and I wrote this reply, but they'd deleted the comment. You get the reply anyway: Reverse engineering fruitflies means reverse engineering something that's almost entirely undocumented, what documentation does exist is frequently wrong, that has almost 4 billion years of tech debt, that relies on self-modifying code, executed on a series of components that aren't fully deterministic, that can only be bootstrapped from existing fruitflies, that has no debugger, that had no functional specification, that has an instruction set where the behaviour of an instruction can depend on the three dimensional structure of the encoding of those instructions and so be influenced by instructions that are several thousand (if not million) instructions away in what looks like an entirely separate compilation unit, and if you change the temperature or humidity or any number of other apparently irrelevant factors will just behave entirely differently. And, if you fuck up, you suddenly have a room full of fruitflies. So, yes, reverse engineering Java is definitely more relaxing.)