> You know, they're Secure(TM)! Against Threats(TM)! This is thought provoking because I get your sentiment against half-baked ideas of "secure" and "threat",

> You know, they're Secure(TM)! Against Threats(TM)! This is thought provoking because I get your sentiment against half-baked ideas of "secure" and "threat", but then you start talking about cameras, fingerprint readers and boot processes... These have nothing to do with phones as I see them. For me a secure phone is the minimum viable device to make a voice communication (and perhaps short text messages at a stretch). So what's going on here is woolly ideas about function. If we define a "phone" as a multi-purpose personal computer, address book, secure storage device, video player, film camera etc, then it's going to have very different security parameters than a simple "telephone". So we can't talk about threats and security until we have talked about function. As we define (or rather fail to define) a 'phone' today it has almost no functional boundaries, and so there's no model around which to define security. The minimal RISC-V device outlined in the article looks like the kind of thing that could be customised to constrain functionality in such a way as to add security. It obtains that possibility by giving control to the end user around what not to include.