:::: MENU ::::

Be Open or be insecure – Hemlis must choose

Hemlis

The beautiful and secure messenger?

Today Hemlis, a proposal for a new encrypted mobile messaging app, received $125,000 in crowdfunding. It’s wonderful to see ambitious new software projects get support from the community, especially when they are Free Software which can be used, studied, shared, and improved by everyone. But is this really the case with Hemlis?

A few moment’s thought are all that’s required to realise that the only trustworthy app is a Free Software app. This is why the US Government goes to the trouble of certifying Free Software encryption cyphers as their national standard, why the NSA uses GNU/Linux and Hadoop to monitor the world, and why everyone from the armed forces to drug smugglers turn to Free Software network tools like Tor to cover their tracks online. After all, what use is security that cannot be verified, because its workings are secret?

Considering the obviousness of these facts, Hemlis, self-billed as “The Beautiful & Secure Messenger”, could reasonably be expected to be 100% Free Software. Many indicators point to this not being the case however.

The crowd-funding model Hemlis used rewards donors with “unlock codes” which extend app functionality with picture messaging, among other things. This business model is as old as the hills, and just like the shareware and neo-proprietary (aka ‘open core’) apps that came before it, provides exclusivity to paying customers by artificially locking other users out. The code that locks other users out we refer to as an “anti-feature” because its functionality that’s built for the sole-purpose of inhibiting what a user can do. For an excellent (and terrifying) explanation of how anti-features are harming humanity and their environment hear Benjamin Mako-Hill’s recent keynote speech on the subject.

Benjamin Mako Hill

Mako Hill on anti-features

But shareware / neo-proprietary software cannot, by definition, be Free Software. One of ways Free Software protects users is by making them immune to anti-features, because when you have the source code to a program, you can simply remove or disable unhelpful code to suit your needs. Because anti-features serve nobody but the original developer, they don’t last long in the wild, and usually get swiftly removed. The Hemlis founders are smart people, and among them is Peter Sunde, famous for his leading role in the Pirate Bay, also known as “the World’s most resilient BitTorrent tracker”. Peter et al wouldn’t base their funding model on a reward system that was destined to be undermined on release day, so some part of the initial Hemlis app must be non-Free Software, or perhaps all of it. And as we know, non-Free Software cannot be trustworthy software, which is Hemlis’ stated purpose.

But it’s not just the Hemlis mobile apps that are looking suspiciously closed. From the official FAQ:

We have all intentions of opening up the source as much as possible for scrutiny and help! What we really want people to understand however, is that Open Source in itself does not guarantee any privacy or safety.

As the quote says, the availability of source code is not a sufficient condition for security or privacy. Availability of source code is, however, a necessary condition for those things. It doesn’t sound like the team are committed to Free Software, privacy, or security from the above statement – if they were, then they wouldn’t imply that 100% source code availability is impossible, which, as they are writing the app themselves, is patently not the case. The FAQ continues:

It sure helps with transparency, but technology by itself is not enough. The fundamental benefits of Heml.is will be the app together with our infrastructure, which is what really makes the system interesting and secure.

Their explanation emphasises the critical relationship between the Hemlis mobile client and the developer’s own server infrastructure. That sounds like a centralised service, i.e. a single messaging server to which all the mobile clients connect, which is the same network model that so many other proprietary messaging apps use, including BlackBerry Messenger and What’s App. However their description hints at Hemlis’ own control of the server as well as centralisation. But why should the Hemlis dev team be the only ones to run a Hemlis messaging server? It remains to be seen whether the quote is referring to infrastructure software, or infrastructure service – e.g. whether the dev team will make the Hemlis messaging server Free Software, or just keep it for themselves along with control over the network and knowledge of where all our messages go.

Being Free Software is a necessary condition for privacy and security

Source code availability is a necessary condition for security

These observations raise important questions about how trustworthy Hemlis will be when it’s finally available, and whether $125,000 of community good will shall be invested in Free tech for the good of everyone, or (at least) partly closed tech for the good of the Hemlis project founders. I’ve already sought answers to my questions on Twitter but so far received no response. Hopefully we’ll all have more information soon.

And until Hemlis materialises in an app store near you, you can use an existing Free Software messaging app that has already had its privacy tested and it’s decentralised network independently deployed: Kontalk is in both the F-Droid and Google Play stores, ready for your use. I’ve been using it for cost-free text and picture messaging back to the UK from Germany since I moved four months ago. If you’re looking for a glitzy website featuring a heartfelt plea for your money from a celebrity, you’ll be disappointed. But if you’re looking for bullet-proof privacy and seamless integration with Android, try Kontalk.


6 Comments

  • Reply samtuke |

    More details emerge, confirming suspicions:

    Your server only?
    Yes! The way to make the system secure is that we can control the infrastructure. Distributing to other servers makes it impossible to give any guarantees about the security. We’ll have audits from trusted third parties on our platforms regularily, in cooperation with our community.

  • Reply torsten.grote |

    From their website:

    Will it be Open Source?
    We have all intentions of opening up the source as much as possible for scrutiny and help! What we really want people to understand however, is that Open Source in itself does not guarantee any privacy or safety. It sure helps with transparency, but technology by itself is not enough. The fundamental benefits of Heml.is will be the app together with our infrastructure, which is what really makes the system interesting and secure.

  • Reply Hugo |

    From the website

    “Why not use OTR?
    Even though we love OTR it’s not really feasible to use in a mobile environment. The problem is that OTR needs both parties to be online for a session to start, but a normal phone would not always be online. It would not work at all for offline messages neither.”

    Huh, what?

    https://github.com/WhisperSystems/TextSecure/wiki/Protocol: The TextSecure encrypted messaging protocol is derivative of “OTR Messaging.” The major difference being the use of ECC keys instead of standard DSA, as well as the compression of some data structure formats.

    From https://whispersystems.org/ licensed under GPLv3

  • Reply leroy |

    So… BBM, according to this interpretation cannot be secure, or safe.. The reality of things is that software CAN be secure, its not even about the software/code. It’s about the intentions of it’s creator. This new app could be secure, and keep the oss hippies happy if the security features come in library form, and the UI is closed. This way people can check and contribute to its security, but not (easily) create derived copies. Better yet, other messenger apps could share the same security foundation!

  • Reply samtuke |

    @leroy Thanks for your comment!

    We disagree: proprietary software can not be secure in any meaningful sense, even if the UI is the only non-Free component. How could we know how the UI was handling input? How could we know it was even using the libraries it claimed? The “Open Source hippies” who value full stack open Source are the ones building the world’s security infrastructure – OpenSSL (64% of servers), PHP (39% of servers), Apache, Nginx, CentOS… Security that cannot be inspected and validated is no kind of security at all.

So, what do you think ?