End to end encryption in the new version of Screensaver Ninja, part 1

When I described the architecture of the new re-built-from-scratch Screensaver Ninja, I talked about end to end encryption but I didn’t go into a lot of detail. Let’s do that now.

Some definitions

First, let me define what I mean by end to end encryption. It means that the data that is protected will be encrypted from the time it leaves the computer that generates it until the time it arrives at the computer that consumes it. When the data is in my server, at rest, it’s encrypted.

This is different from SSL or TLS which only encrypts the information while transferring from your computer to the server but then the server actually decrypts it and if it stores it, it stores decrypted. Both modes of encryption are important and have different uses and Screensaver Ninja will use both but this article is about the former.

Not all the data will be encrypted, only the critical parts, such as the URL of the sites you added, the cookies used to access those sites, as well as any other sensitive information that might be added in the future, such as credentials, scripts, CSS, etc. Particularly I’m not protecting: how many sites you have, for how long you show them, in which machines you show them. Should my servers become compromised, that data won’t give an attacker access to the websites you are showing so, they are less critical than cookies and credentials.

Back to Screensaver Ninja

In Screensaver Ninja, each account will have to be two symmetric keys (generated randomly). The first one is the master key which is used to encrypt everything and the second one is the displayer key, which is used to encrypt the screenshots for the displayers. The whole system will look like this:


The configurator and renderers will contain both, the master and the displayer keys while the displayers will contain only the displayer key. Your URLs, cookies, credentials and other sensitive material will be encrypted only with the master key so the displayers will never gain access to it. The renders will generate the screenshots and send them to the displayers encrypted with the displayer key.

These two keys will never be placed on the hosted server in plain text, they’ll be encrypted. Each user, renderer and displayer will have a public/private key pair that will be used to encrypt the master and displayer keys. All public keys will be uploaded to the hosted server but the renderers’ and displayers’ private keys will remain in their respective computers.

The users’ private key will be uploaded to the server so the user doesn’t depend on a single machine to operate Screensaver Ninja but it’ll be first encrypted with a key generated from the user’s password.


From that architecture, we can design the registration process that looks like this:



In that sequence diagram you can see the generation of the random public/private key pair that belongs to the user as well as the generation of random master and displayer keys.

It is important to note that the password never leaves the user’s computer. It is used to encrypt the private key (after applying PBKDF2 to it) and it’s also hashed before being sent to the hosted server with bcrypt.

PBKDF2 stands for Password-Based Key Derivation Function 2 and it turns a password into a piece of seemingly random data suitable for use as a key. Running it for so many iterations makes the process slow, which makes an brute force attack unbearably slow.

Bcrypt is a one way hashing mechanism used to store passwords so that the password can be verified but not reobtain. It’s the currently recommended solution to store passwords on a server so that should the database be exposed, nobody will be able to know what the passwords were. In the case of Screensaver Ninja, the password is hashed before leaving the user’s computer to avoid exposing it to the hosted server in any way and then again in the server for storage, in what I dubbed over hashed password,  to avoid replay attacks should the database become exposed in any way.

Logging in

The process of logging in is not as complicated as registration but it’s still more complex than your average application.


The user as usual enters the email and password but the first step for the configurator app is to request the salt used before to hash the password. This salt is random so we need to get the stored one in the server. With this salt, we can hash the password using bcrypt while in the client and send that for authentication.

The server verifies the hashed password matches the over hashed password in the server. If it does, then it considers the user logged in and sends the session cookie and the user’s data including the encrypted private key. This key has to be decrypted with the previously entered password which has to be processed with PBKDF2 the same way it was done while registering.

Even if an attacker somehow manages to log in by deceiving my servers somehow, the private key is still encrypted and without the password they won’t get far.

Once the private key is decrypted, the configurator requests all accounts. Note that Screensaver Ninja will be a multi-account application, so you can operate several accounts from a single email address. Each of these accounts comes with a master and a displayer key which is encrypted with the public key, so it proceeds to decrypt each of them with the private key. Once done, you are fully logged in and in business.

For clarification, the master and displayer keys are stored encrypted several times, once for each user, displayer and renderer, because each of them will have a different public/private key pair.

Changing the password

Changing the password has an added complexity similar to logging in. In this sequence diagram we assume the user is already logged in and wishes to change the password:


Both old and new passwords need to be hashed on the user’s computer before being sent and then the process is similar to your standard web application. Old password is verified, if it matches, new password is stored in the database.

The big difference here is that the private key of the user is encrypted with the password, so, a new version encrypted with the new password is sent to the server and it is stored in the database should new old password match.

Conclusion so far

For most web applications, I generally just use a library that implements authentication. It this case that is not possible as the system has very particular needs. I searched around for ready-made implementations of this and I couldn’t find anything. This meant spending a considerable amount of resources in building one and there were many iterations.

When it comes to security related code, the best way to do it is not to do it. It’s to rely on widely used and scrutinized libraries. What I’m doing here actually makes me uncomfortable. I have asked a few of my friends to review this design and that pushed me to do several iterations, improving the system and simplifying it.

Once I get some revenue from the project (or investment, who knows), I’ll hire a security expert to go over the whole thing again, both the design as well as the code implementing it. And if someone wants to see the code, I’m happy to post it online.



The Highlander query with Rails’ ActiveRecord

For those cases in which there can be one and only one record on the database with certain fields and I don’t just want to get the first one and silently get the wrong one. I want to make sure there’s one and only one, so, I wrote this little extension to ActiveRecord that does exactly that:

module ActiveRecordExtension
  extend ActiveSupport::Concern

  class_methods do
    def one_and_only
      records = limit(2).all.to_a
      if records.count > 1
        raise "#{self} generated more than one record when expecting only one."

    def one_and_only!
      one_and_only.tap do |record|
        if record.nil?
          raise "#{self} didn't generate any records."

ActiveRecord::Base.send(:include, ActiveRecordExtension)

The first method, one_and_only, will raise an exception if there’s more than one item but it’ll return null if there aren’t any. one_and_only! will fail if there isn’t exactly one and only one record in the database.

If you don’t know why I’m calling this The Highlander query, you should go and watch Christopher Lambert’s masterpiece.


Screensaver Ninja will be very different this time

After my announcement of Screensaver Ninja’s potential return, many people asked for features and more information. I answered all emails individually but there are some things I want to share with everybody.

I’m rewriting Screensaver Ninja from scratch with a completely different architecture to cover the two most requested features:

  • Microsoft Windows support
  • Centralized management of many installations

Most of Screensaver Ninja will be developed using cross platform technologies and it’ll have several components:

Screensaver Ninja component architecture.png

This breakdown in components exist to make the most complex deployments possible but I’ll provide packaged solutions for the simple cases.

The configurator is the first app you start. This one allows you to create an account and set up which web sites to show and in which machines. The account is created on a hosted server I’ll be providing and this time Screensaver Ninja will be SaaS, that is, software as a service, with a monthly or yearly subscription.

The displayer components are the ones you run in the machines you want to display the web pages. Displayers will include screensavers for Mac and Windows, but also standalone applications, live wallpapers, iOS and Android apps, etc.

The displayers will never contain any cookies or credentials so you can put them in lower security machines without worrying that person gaining or having access to that machine will gain access to your web applications. This is achieved by shipping screenshots to the displayer.

The screenshots are generated by another component called renderer. These will get the cookies and credentials but you only need one for your whole organization and it can run in a secure environment, such as the computer of a trusted person or even a server in a data center. You may also have more than one renderer to distribute the load and ensure availability.

A single computer can run all components if you are a solo Screensaver Ninja user.

Cookies and credentials will be end to end encrypted so only the configurator and the renderers will have access to them. Screenshots will be encrypted so that the displayers have access. This ensures that I don’t have access to your private data and should my servers be compromised, the attackers won’t have your data either.

This sequence diagram shows the flow of data through the different components:

Screensaver Ninja architecture.png

What do you think? Does this suit your needs?


Screensaver Ninja might be coming back

Since discontinuing Screensaver Ninja, I have received many messages asking when it is coming back: over Twitter, Facebook, email, and even one person tracking me down on Reddit..

For those of you who don’t know what Screensaver Ninja is, here is the old explainer video:

It has been very painful to read these messages for a couple of reasons. Firstly, I strongly believe in the product. I want to have it; use it; and enable others to use it. I constantly see expensive and badly designed dashboards or wasted screens, which my product will address. Secondly, judging by the requests, other people want this just as much as I do. Not proceeding with Screensaver ninja could be a wasted business opportunity; although it is hard to tell if the demand is enough to support its development right now.

I set up a landing page explaining what happened to Screensaver Ninja and a form for people to register for notifications of its potential comeback. This was a way to save everybody’s time and frustration; for those emailing requests for up to date information when I could only say, with sadness, “it’s over”. To my surprise, this form has been gathering five or so leads a week, which is rather a lot for an abandoned product.

I have started playing with the idea that I might revive Ninja: This time I have designed a bigger system that covers many more use cases and allows me to support both Windows and Mac OS as well as other platforms just as easily.

During this process I identified the technological bottlenecks; the aspects to product creation that can take months to negotiate and solve, such as hacking Apple’s cookie jar or packaging Chromium. In doing so, I have built a selection of prototypes testing my choices – and everything is working beautifully.

So that’s it: I have decided to revive Screensaver Ninja. I have emailed all of you whom have shown interest to tell you the good news, and have received an overwhelmingly positive response from both individuals and corporations; some wanting to run hundreds of instances.

I want to be completely transparent with my supporters; I am building Screensaver Ninja by myself in my spare time between long days and after hours work at two different consultant gigs. Whilst I am looking into the options of partnerships, developers, and marketers, I have decided not to wait for these additions to the team in order to make progress. I’m very excited about this phase both from the technical as well as the business points of view so Screensaver Ninja is moving forward and I will have frequent updates.

Going into the property business 

I’m a tech entrepreneur and that has not changed, but after six or seven years of trying to have at least moderate success, I’m starting to hedge my bets.

On the side, I want to have some passive income and it looks to me like buy and hold properties, that is, buying them and renting them out, also known as buy to let, is the way to move forward. I identified some very profitable areas and they are in the least expected places. For example, in London you can expect a return on investment of around 3% while I’m getting something around 16%.

If you want to listen to my journey, I’m documenting it as I go with Clayton Morris on his podcast about investing in property. He just published the second episode in which I talk about getting the money for my first two deals.  I just pulled the trigger on starting the business. I’m super excited and I can’t wait to share more good news in the next episode. 


Emacs is hurting Clojure 

Emacs is a very powerful text editor and its popularity amongst Clojurians is easily understood. Emacs has a long tradition in the Lisp communities as it’s written, in a big part, in a flavor of Lisp called Emacs Lisp.

Because of its history, it handles Lisp code wonderfully, with automatic correct indentation, paraedit, integration with REPLs, etc. But Emacs is really hard to use.

Yeah, most Clojurians know how to use it by now and they suffer from bias: “it’s not that hard” they say. Learning Emacs or Clojure is hard enough. Combining them is insane.

Many Clojurians also say it’s worth it. And again, I think they are biased. Human brains are very good at forgetting pain. Other editors these days are also very powerful and although not as much as Emacs, their usage is intuitive so you can achieve a higher level of proficiency just by using it, without spending time and effort in becoming better at it.

The way Emacs is hurting Clojure is by Clojurians maintaining this myth that you need to use Emacs for Clojure. This is not done by simple statements but by a general culture of jokes saying things such as “you are wrong if you don’t use emacs”.

Me, personally, I don’t care what editor you use. If you want to learn Emacs, go for it. Intellij and Cursive is much easier to use and almost as powerful. When I compare myself to another clojurian, productivity is generally decided by knowledge of the language and libraries, not the editor. If you want to use another editor, so be it. It’s better if they understand Lisp code but it’s not a deal breaker for learning Clojure.

I do care about the success and popularity of Clojure. Coupling the growth of the language to the use of an editor that is hard to use and non intuitive makes no sense. It’s hurting us. Even if you are an Emacs power user, when you talk to a Clojure newbie, please, don’t push it down their throats.

Thank you.

Avoiding threads of emails when developing a Rails application

Call to Buzz, like many applications I developed before, sends emails. Lot’s of emails. To avoid accidentally emailing a customer or random person I use mail_safe. It’s one of the first gems I install on a Rails project and you should too. mail_safe re-writes the to-header so you end up receiving all the emails that you sent.

Once you are receiving all these emails, there’s another problem. They are likely to have exactly the same subject, so, mail clients are likely to group them in threads, which can be annoying. To avoid that, I added this to my ApplicationMailer class and voila! all emails have a unique subject:

if Rails.env.development?
  after_action :uniq_subjects_in_development

  def uniq_subjects_in_development
    mail.subject += " #{SecureRandom.uuid}"