Hacker News new | ask | show | jobs
by nickpsecurity 3637 days ago
Most are focused on the name, which is terrible, while only one other (so far) noticed the big problem: Electron, React, and Redux. A secure messenger needs to have strong endpoint security. Easiest way to do that is using safe, system languages with simple implementation, as few dependencies as possible, and isolation of app from rest of the system. That's one of safe C's, restricted C++, SafeD, Ada/SPARK, Component Pascal, Rust... any of those with portable code for main library plus modules for OS-specific stuff (esp GUI & filesystem). That would have a chance of surviving hackers, esp good ones.

I know almost nothing of the above frameworks. However, Google gave me front pages for each that look more complex in implementation and dependencies than a C, Ada, or Rust app. Unnecessarily so. Secure applications should follow Lean and KISS principles every chance.

Note to author: All that said, if you're just doing it for fun or learning, then that's cool. Also a good area to learn about. :) The above applies to implementations meant to be used in field.

2 comments

This was also my first reaction. The PGP part might have been audited... but what about the rest of the code? I highly doubt Electron is bullet proof.
Agreed. Although I think that the name is also a problem. It feels like most of the upvotes are coming in because of the pretty image in the readme...
I mention the name in passing as others wrote on it. A lot on it haha.

Your comment on image is possibly also true. I remember much of the press of another messenging app oriented toward privacy came because it advertised as "the beautiful messenger" with many nice pictures. It was Icelandic with .is site but I don't recall name. Versus competition, wasn't much to say in terms of implemented features or security. The U.I. was beautiful, though. ;)

Note: The Apple website takes this technique about as far as it can go outside a dedicated, high-def, image board.

Note 2: I could add Nim to my prior list if there's been any work evaluating it for security-critical applications. Particularly, how it helps or hinders expressing such things plus risk compiler brings in during transformations. Anything on that yet?

> Note 2: I could add Nim to my prior list if there's been any work evaluating it for security-critical applications. Particularly, how it helps or hinders expressing such things plus risk compiler brings in during transformations. Anything on that yet?

Afraid not. Would be awesome to see somebody that is security conscious taking a look at Nim and verifying these things :)