Airborn OS Blog

To content | To menu | To search

Tuesday, February 23, 2016

The first web application that doesn't trust the server

Airborn OS is an in-browser OS and Google Docs alternative that encrypts your files in the browser.

TLDR: The latest version of our Firefox extension has been approved. It checks the content at against a known good version. This way, you see a warning if anyone in the chain from us to you wants to, say, steal your password. That could be us, our hosting provider, our Content Delivery Network (CDN), someone who hacks any of the above, or someone further down the chain who can get their hands on a certificate for

Every so often, someone comes along who wants to make a web application that can't read the notes you store in it, or view the pictures you store in it, or something like that. "I'll use a symmetric encryption library! Then user's notes are secure." Most of them are promptly redirected to this Matasano article or some other explanation of the fact that if your users are entering their password and notes on your website, they have to trust you every time they do that. So why use encryption at all?

We, too, read the articles. Couldn't we cheat? Maybe we could build a browser extension? In fact we did, for Firefox. It contains checksums of the first few files you get from If any of them don't match, you get a big error page. Or if the checksums are considered out of date, you get a smaller warning.

The checksums are considered out of date when a new certificate for has been generated and is in use. Today, that can be done quite easily and unnoticed, so the warning shouldn't be taken lightly. However, in the future, Certificate Transparency will notify people when that happens, so that they can check if a corresponding extension update has been issued.

These first files, checked by the extension, then continue to fetch and execute further scripts, which are authenticated with the user's password. If the user wishes, they are asked before updating those further scripts. The result is that none of the scripts that the server delivers are trusted at face value.

But Firefox extensions take weeks to update, right? You can't put a website's checksum in there!
Our experience so far, with three versions of our extension, has been pretty good. Still, this is a valid concern. The first few files on have been purposely designed to remain constant. For example, most of the content on the homepage is loaded in a sandboxed iframe. This has some downsides, but for us it's worth it.

Nobody wants to install an extension before using a web app!
We hope that those who care about their security will. However, not everybody has to install the extension for everybody to benefit: an attacker doesn't know in advance whether or not you have the extension installed, after all.[1] That means they don't know if their attempt will go unnoticed.

Does this mean Airborn OS is secure?
Maybe. We would like to have a full audit done of Airborn OS and the Firefox extension in the future. However, if you install the extension, and disable automatic updates for Airborn OS, you're probably running the code that's on GitHub.

Can my web app do this too?
Yes. Send a pull request with your web app's checksums. However, make no mistake: the files for which you include checksums can't change often.[2] So your web app either needs to be very simple, or you need to build upon this to verify the rest of the web application in some other way. A simple example would be to check the rest of the source with the version on GitHub.


[1] Unless you don't use Firefox. However, in the future we could solve that by 1) releasing an extension for other browsers or 2) impersonating other browsers in our Firefox extension for some users.

[2] If you want to help decide on branding for the addon, or want help with making the first few files of your web app static, shoot me an email (see GitHub).

Thursday, December 17, 2015

A Better Taskbar

Airborn OS is an in-browser OS and Google Docs alternative that encrypts your files in the browser.

Normally when I talk to people about certain things in Airborn OS, such as its security, they at least think it's somewhat complicated, sometimes even overcomplicated. However, there's one thing I show people that I'm proud of, but they seem to think is completely obvious and even uninteresting:

When you minimize a window, it's placed on the taskbar in the location closest to where it was, not next to the previous window.

Please try out the Airborn OS Demo if it's not clear what this means.

Indeed, it didn't take a long time to come up with this. Nevertheless, I've never seen it anywhere else.

The main advantage to this is that it makes it easier to find windows you were previously looking at, which is the purpose of the taskbar.

The main disadvantage is that if all your windows are maximized and you only have one screen, it doesn't help you. Currently, Airborn OS partially layers those windows on top of each other so that only the icon is visible. However, many modern taskbars already only show the icon, so it might actually work well in that case.

Thinking further

How do we make it easy to find windows you were previously looking at?

One counter-question is, "What do we know about the window we are trying to find?" Every answer to that question points to a window switching mechanism:

  • Its title
    • Show every window's title on the taskbar
    • Make a "window search box" in which you can type part of a window's title
  • Its icon
    • Show every window's icon on the taskbar
  • Its location
    • Make windows' position on the taskbar close to their location
    • Add a mechanism to view and switch to covered windows (e.g., a 3D view which looks at the desktop at an angle from above)
  • What it looks like
    • Add a mechanism to view all open windows
  • That we we were looking at it recently
    • Show a list of windows in order of last focused
  • Where it always is
    • Allow users to order their window list

Obviously, some mechanisms show multiple properties of the window, such as its icon and title, or its location and what it looks like.

Invitation to experiment

Switching windows on many operating systems can still feel a bit behind, say, switching files in Sublime Text. In any case, there's probably always room for improvement on every OS.

If you know HTML, CSS and JavaScript, not just Airborn OS's taskbar is written in it — Cinnamon's (the desktop environment by Linux Mint's developers) is as well, and GNOME 3 allows you to write extensions (including a taskbar) in JavaScript, too.

Thursday, May 21, 2015

Dividing Content into Visual Pages in CSS

Airborn OS is a secure alternative to Google Docs.

Pages Demo Screenshot

Update: this no longer works since Firefox 40. I filed a bug on Bugzilla.

Unlike Google Docs, Airborn OS (or rather Firetext, the text processing app) doesn't include a custom renderer for text documents. Instead, it uses the browser's built-in html viewing and editing capabilities. This means that if we want to divide content into visual "pages" that correspond to the pages that would come out of a printer, we'd have to do it in CSS (or a combination of CSS and JavaScript). Can it be done?

It sure can, with some trickery. The trickery consists of two steps:

  1. Divide the content into CSS3 Columns. Thanks to the foresight of the creators of the Columns spec, column-count: 1 happens to do exactly what we want: divide into columns with a specific width and height.
  2. Rotate the columns so they are under each other instead of next to each other, and rotate the content so it's the right way up: writing-mode: vertical-lr and writing-mode: initial. This tells the browser it should order text (and columns) from top to bottom.

Unfortunately, this trickery only works in Firefox and then only if you set layout.css.vertical-text.enabled to true. If you do that, you can see a working demo here.

Even when support is enabled by default in Firefox, there are still unsolved problems: it's hard to style individual "pages" much further than in the demo (padding, box-shadow and border don't work on individual pages; outline does but is buggy). When you enable editing text more problems arise, for example this bug.

Also, before you use this on your own website, there's a debate to be had if pages improve readability. Still, it's a cool trick and it's amazing that it works at all.

For a related technique to show only one page at a time, see this article.

Thursday, April 30, 2015

Airborn OS as a Secure Alternative to Google Docs

Maybe you want something more secure than Google Docs/Drive.
If so, Airborn OS might be a good alternative for you.

What is Airborn OS?

  • It's an operating system in the cloud.
    It comes with the app "Firetext" to edit text documents.
  • It's accessible from any platform.
    Like Google Docs, you only need access to a browser to edit your documents. Unlike Dropbox, you don't need to download and upload your documents to edit them.
  • Your files and apps are all encrypted in the browser.
    This makes Airborn OS much more secure than Google Docs.

How does Airborn OS realize more security?

The encryption of Airborn OS uses a private key. Every user has their own private encryption. The encryption is used both for the documents and the code of Airborn OS to open and edit your documents. So nobody can read your documents, or change the code to open and edit your documents.[1]

What can't you do with Airborn OS yet?

Google Docs is a complex product with many features. Airborn OS and Firetext are still in development and don't have all of them. Here are some things you can't do with them yet:

  • Work together on documents.
    Firetext, for now, is an individual app. You can't edit one document with two people at the same time unless you're sitting next to each other.
  • Spreadsheets and presentations.
    With Firetext, for now, you can only upload, create and edit text documents.

In short, Airborn OS with Firetext might be a good alternative to Google Docs if you want more security and don't need all the functionality of Google Docs.


[1] For more information on how this is made secure see

Saturday, April 25, 2015

Secure Delivery of JavaScript

Airborn OS is an in-browser OS that encrypts your files in the browser.

Let's say you wanted, like us, to create a web application that encrypts your user's data with their password before it stores it on your servers. You value your user's privacy, after all. Does this buy you anything, though? Not really. Tomorrow you could change your code to send you your user's password. Even worse, you could do so for a particular user you're interested in. In other words, there's no way to securely deliver a web app without trusting the server.

Yet. What we need, in essence, is an external source that tells us what the HTML, CSS and JavaScript of the web app should be. People should be able to be notified when the source changes, in case you changed it to send you their password, and it should be the same for everybody, so that when one person checks the source, everybody can be more confident in it. A browser addon, or eventually the browser itself, could then check the server's responses with that external source.

One possibility for the external source is the browser addon itself. However, updates to Firefox addons can take a few weeks to be approved, which is simply too long when you need to change your JavaScript (more about that later). Browser updates also take six weeks, if we ever wanted to build this functionality into the browser.

A more promising possibility is the website's certificate. With the upcoming Certificate Transparency (CT), people will be able to keep track of certificates and be confident that everyone gets the same certificate. We could use a certificate extension to store the information we need. Currently, though, no Certificate Authority (CA) that I'm aware of actually allows you to put arbitrary information in certificates. One CA we asked worried about CA/Browser Forum requirements. One CA was willing to do it, but at a large sum per generated certificate, which is a disincentive you shouldn't want.

Finally, we could do something in between those two possibilities: store the information in the addon, but allow updating the web app by regenerating a certificate (which is faster). In other words, pin the information to the certificate. This is what we currently do for We call it "HTTPS Content Signatures" (HCS) and the addon is here (code).

Once Certificate Transparency becomes a requirement in browsers[1], this means it's no longer possible to serve unknown certificates with a website (that's what CT is). That means it's no longer possible to serve unknown HTML or JavaScript to the browser as long as every known certificate is listed in the addon (that's what the addon does). Secure delivery of JavaScript, coming soon!

As promised above, one more note about updating the web app. Having to regenerate your certificate every time you update your web app is still quite unfortunate, especially if it means users of the addon are no longer protected. It might be necessary to reduce the amount of code that is protected this way. I'll offer two possibilities.

For the homepage and login page, you could separate form from function with a sandboxed iframe. However, there are many small problems with this to which I have no solution yet: it complicates scrolling, if you allow navigating the top frame (for links) that could be abused, and some things can't be moved to an iframe (e.g. <meta> tags).

For the web app itself, you could protect only a small "loader" and do in it whatever you want. What we do is decrypt the rest of the code with the user's password.

This is all by no means an easy or ready-made solution, but for web apps that are very serious about security, it could be an important building block.


[1] Since we have an addon anyway, we could build this requirement into the addon. We haven't done so yet, though.