I just launched secure.shrib.com, a new iteration of the secure alternative to shrib.com. shrib.com is used by millions of people around the world. The following is an invitation behind the scenes.

Historic Background

I have been running the online note-taking app shrib.com for many years. At first, it was a purely personal tool. One of my dayjobs at the time involved working on lots of different devices, and I wanted a barebone textpad that I could access without any advanced technology or login.

By now, millions of internet citizens have been using the site. We (me and my millions of users) are taking personal notes, sharing texts, collaborating to edit an article, organizing a party, keeping our to-do lists, collecting code snippets, saving links, or doing our research with shrib.com.

While not having to log in and still being able to access the notes on any connected device is a very convenient thing, it has an important drawback. Some people are not aware of the fact that all notes on the plain shrib.com are accessible for anyone.

Early Encryption Feature

Hence, the original shrib.com seamlessly integrated a highly secure, client-side encryption feature. This means that a user could encrypt her notes with the click of a button, and no-one on earth could read her note without her password – not me, not the NSA, no-one else.

I was pretty proud of it. I had used the robust and open source «Javascrypt» library by John Walker. I tweaked it just a bit to fit into the context of shrib.com, and I made it blend into the overall shrib.com user interface seamlessly. For example, I thought that «encryption» was too intimidating for normal users, and used «locking» instead (with the result that people did not realize that this was rock hard AES encryption).

In fact, so seamless that hardly anyone noticed. As shrib.com started to evolve, I always adapted the encryption feature to fit the new situation. I spent countless hours dragging that feature along. This means: if I implemented a new shrib.com feature in 2 hours, it may have taken another 4 hours just to adapt the encryption (or «locking») mechanism.

One day, I ran some statistics on my database, and realized less than 3% of my users even used encryption at all. Duh!

Fanning Out

It took me many years to draw the right conclusion: fan out to a special edition of shrib.com. Just for those who really care about privacy. First, I just separated all encryption vs. plain text features and created i.shrib.com. I could finally remove all the encryption mechanism from the main shrib.com site.

Now, shrib.com is much leaner, new features can be implemented much more rapidly, and a lot of code could be cleaned out.

At the same time, now the privacy features can be tailored much more to the few – but still many – users who actually appreciate privacy online.

Redefining Secure Online Notes

So I started thinking hard about what I would like. Here are my requirements:

1. Simple, plain text – and fast. I want no rich text formatting, no long load times for lots of Javascript and CSS.
2. No login. I don’t want to have to remember yet another login pair – or save yet another one to a password safe I depend on.
3. Client-side encryption. I want no plain text to get out of my browser window. No plain text in the air, on the wire, or on the server.
4. A standard, open-source, peer-reviewed encryption algorithm without any customizations.
5. A way to make it a lot harder for an attacker to even get to the encrypted version of my note. Think two-factor authentification (or three, or many…).

The Result

I am happy to have released a first iteration of secure.shrib.com. Here is how it meets the requirements:

1. Simple, plain text – and fast. The interface is kept super simple. I learned to know that people who really appreciate actual privacy also appreciate straight, simple, and no-nonsense interfaces.
2. No login. Not only does secure.shrib.com not need you to log in: there is no cookie, no «local storage», and no tracking whatsoever.  No jquery, no google analytics, not third-party scripts or resources.
3. Client-side encryption. Your notes on secure.shrib.com are only in plain text in your device’s memory as you work on it. As soon as you perform any other action, it is encrypted inside your browser. In order to make it harder for an attacker to forge the encryption algorithm, everything is served over SSL («https»).
4. A standard, open-source, peer-reviewed encryption algorithm without any customizations. As opposed to the «customized» version of Javascrypt that I used before, I have now switched to the well-known, trusted, and tested Stanford Library. And no customization. If you look at secure.shrib.com’s source, you will see the original sjcl.js is included without changes. Industry-standard AES algorithm at 256 bits is used.
5. A way to make it a lot harder for an attacker to even get to the encrypted version of my note. If you are willing to sacrifice convenience for added layers of protection, you can require email or phone verification for your note. This means that everytime you want to access your note, you will have to receive and confirm a token sent to either your email address or your phone – or both.

The tool is online, and I look forward to your response!