The Joy to Be Server-Free

freedomA few months ago, I toyed with the idea of adding a server to my PassLok Privacy app. I reasoned that a server would be able to store users’ Locks so that other users could retrieve them automatically—very much like the General Directory does now, but even more deeply integrated with the program so that users wouldn’t even be aware that a server was being contacted. Everything would be real easy. Seamless. I also reasoned that everyone else was doing it, so why not?

To this effect, I started looking for some student help (my day job is as a professor in a major university), and I almost hired some of them to start coding the server part. But then I thought, what if someone has already done this? Wouldn’t it be foolish to be doing all this work if I could just copy it? Lucky me, half hour of googling around revealed Peerio, a multi-platform application developed by the same team as Minilock, which is a Chrome app that encrypts files using the same engine as PassLok.

peerioPeerio is quite a nice app, no doubt. Users are given a seven-word passphrase (which they cannot choose, only accept or get a new one) from which the private key is generated after many rounds of SCRYPT (PassLok does the same, though the number of rounds is chosen more intelligently), and then the public key is obtained from that through the Curve25519 functions in TweetNaCl. Crypto primitives are NaCl, like PassLok.

After looking at it for a few days, I concluded that PassLok might evolve into something quite similar to Peerio (except for the forced passphrase and lesser details) if a server was integrated into it. And I didn’t like it.

Several reasons. The first one that jumped at me is that Peerio has become a closed system. Peerio users can communicate only with other Peerio users, or lose all the advantages. Peerio users cannot have a conventional email address. The best they can do to connect to outsiders is invite them via email to join Peerio. So Peerio has become yet another centralized messaging system like Slack, Telegram, Whatsapp, and the other million of them. You can be sure that when the dust settles in this industry there will be only two or three of them left. Or none at all; read on.

Second, money. Yes, money, unfortunately. There is no way to have a server that handles any volume if you don’t put money into it. Computers cost money. A decent Internet service costs money. Add maintenance, support staff, sales staff, and pretty soon you’ve got a lot of mouths to feed. You may think this is positive, but it can also be quite a liability for the long run. Server-based systems must generate income or die. This brings ads, tracking, software bloat, and all the rest of things that would be so cool to avoid. At this point, as you can imagine, I was pretty much convinced that PassLok had to remain server-free.

Third, and almost as importantly, processing on a server can actually decrease security. Sure, no one outside can see the code and mess with it. But this is a bad thing. This means that a user cannot tell what is actually happening to his/her precious data, even if he/she wants to. Assurances can only take you so far. If all the processing is done client-side, on the other hand, users can see the code that is actually executing. They may or may not understand it, but that’s a different issue. The important issue is that they are not forced to trust.

passlokSo I took PassLok in the opposite direction, and the result is PassLok for Email. It doesn’t even depend on the server anymore. PassLok for Email downloads directly from the Chrome or the Firefox stores, where it has been digitally signed. It updates automatically when a new version is released. The browser won’t accept the code if the signature verification fails. Just in case, there are instructions so users can verify the authenticity of the code regardless of that signature. Sophisticated users can inspect the code as it executes, stop it, make it skip instructions, whatever.

My server load? Zero point zero, with as many zeroes behind those two as you care to add. There could be a billion copies of PassLok for Email running at the same time and neither my computer nor the email servers would be affected in the least. Now that’s scalability. Denial of service? Please allow me to hold my sides as I laugh.

How come other developers don’t seem to see this? Unfortunately, it’s the same word: money. Once you get into that spiral it is hard to break off. PassLok almost did. . . .

So go ahead and take PassLok for Email for a spin. Invite your friends if you like it. There is a button for that, and their replies already have full security. You can find PassLok for Email for Chrome at this link, and the Firefox version at this other link.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.