Freedombone Blog

Freedom in the Cloud

Making email easier

Mailpile has existed as an app within Freedombone for a couple of years, and it's a nice webmail client, but for a more mass market type of approach it's not ideal. The reason is that the setup is quite non-intuitive and assumes that you know what acronyms like SMTP, IMAP and GPG mean. It's highly doubtful that the average shopper knows about any of that, and chances are they just use Gmail because that's what they were instructed to do by the initial setup process when they first got an Android phone. Gmail didn't ask them for an IMAP domain.

On Freedombone an email server is part of the base install and it has the capability to send and receive messages using onion addresses. I thought it would be nice to have a webmail client which doesn't need any post-installation configuration and which can be used with noscript or with javascript turned off. At first I thought I might need to write something like that because every modern webmail client appears to make extensive use of javascript, but the prospect of writing a usable email system is definitely a non-trivial undertaking so I wanted to avoid doing that if possible.

The only non-javascript solution I found was Squirrelmail. Squirrelmail is an old system by technology standards, although not as old as the kernel. It pre-dates smartphones, and it's certainly not the most glamorous web software you've ever seen but it's functional and customizable to some extent.

So I added a customized version of squirrelmail to the web interface of Freedombone.

The login has been changed to a new logo, and it's linked up to themes and languages such that if you change that on the settings screen the webmail system also changes accordingly. Testing it on mobile in the vertical orientation it looks odd but in horizontal orientation its ok and quite usable. I made a couple of themes called freedom_light and freedom_dark using the same colors as the main web interface so that it looks somewhat consistent. And you can use it to send between onion or clearnet email addresses without much hassle.

So despite its age and smartphone agnosticism Squirrelmail still appears to be quite a good addition.

Apart from the usual advantages of onion addresses the biggest one here is that you don't need to be using GPG to still have fairly good communications security. It's not end-to-end in the strictest sense, but a lot more secure than email usually is. You can also use it via a Tor browser with the security level cranked up to the max if you want to.

Changes to the mesh

Prepping the post-Brexit apocalypse bunker with a "dig for victory" poster and a newspaper cutout of Theresa May on the wall for darts practice during electrical blackouts we also have the Freedombone mesh. The mesh system is a bootable USB version of Debian which can be used with laptops, and there's also an image which can be used with the Beaglebone Black to increase wifi network coverage. Even if the internet is unavailable the mesh network can carry on providing a local communications system.

Recently I've improved the internet functionality so that if you plug a mesh system into your internet router with an ethernet cable then it just automatically becomes a gateway for any other peers in the network. This avoids needing to do any manual network restarts and so makes things more convenient.

I've also removed the Patchwork SSB client because it was difficult to maintain the installation of that on a 32bit version of Debian. I'm still using 32bit images for the mesh, because if you're up against it then any old hardware could be requisitioned at short notice to build a mesh and there may still be old 32bit laptops stashed at the back of closets.

New icons

Some new icons and a new logo have been submitted to the Freedombone project. These were created by Rashid Mhar, and give the interface and website a much nicer look.

There are also now light and dark themes for the web interface, and the ability to edit translations. I've added some automated translations by default, and no doubt these will need changing to some extent.

3.2 release

Commit: d326e580f3cf399fbe965df11a04357fbec12ae0

This is a minor release which continues on the base of Debian 9. The main change in this release is the introduction of a new web based user interface, which aims to make installation and management of the system easier. This is part of the bigger goal to try to push self-hosting into the mainstream and make it more accessible to a wider range of users with a reduced requirement for technical knowhow.

The new user interface was designed for minimum complexity, to operate on screens of any size and without any need to have javascript enabled. Installation may be carried out using only a smartphone running a stock browser. No secure shell logins are required, but that can still be enabled after initial setup if it is needed.

The website and logo have been changed to give it a more appliance-like look, and in future releases the descriptions of individual apps will be moved into the web user interface itself as context sensitive help. More support for languages other than English is also expected in the next version.

Images and source code are now obtainable via dat archives. This should be more scalable than the previous arrangement, because archives can be independently seeded by any number of peers.

On the hardware front there is now experimental support for a few additional single board computers: Beaglebone Green (the non-wifi version), Banana Pro and Beagleboard X15. Running from a SATA drive, rather than microSD card is now also supported, and this can improve system performance dramatically especially if you connect an SSD.

The backup system has been simplified such that there is no longer any need for separate keydrives or special formatting. This means that you can buy a USB drive in a shop, plug it into the server, select backup from the web UI and supply a password to encrypt with and it should then work. If you leave the USB drive attached then it will automatically do a backup once per day.

For installation instructions see the main site. Existing installs should upgrade automatically.

At the present time self-hosting is something only done by people with a high level of technical knowledge, but it doesn't have to remain that way. Version 3.2 is the first version of Freedombone which potentially could be deployable to a mass market - especially if the onion version was used which avoids the need for domain registrations or port forwarding.

Building for Scale

So far the Freedombone home server project has been aimed at people who know how to use GNU/Linux and are not terrified by the sight of a commandline, but for the next release that's going to change.

The next release will have a simplified web based user interface suitable for the mythological "average user". The previous menu system will still be available, but will be for the more advanced users.

I'm not actually a web developer and my knowledge of front end web technologies is very limited. In a job interview not that long ago one of the interviewers berrated me for never having learned Django, saying something like "I do not find it credible that you have not learned Django yet and have not been making money doing that".

To avoid the mess of dependencies which many contemporary web apps appear to entail, for the Freedombone web user interface I've tried to keep it very basic and follow the principle of do the simplest thing possible. I decided early on to avoid javascript. Although it's popular, Javascript often isn't trusted and many people block it altogether with NoScript. So the software architecture of the new web interface is HTML, CSS, a small amount of php and a daemon in the background made with bash. The daemon does all the important stuff, like installing apps or making backups.

Experienced web developers will probably laugh at the crudeness of this implementation, but it works and should be straightforward to maintain. The design can be simplified because it's only expected to be used by whoever is administering the system, so concurrency of inputs doesn't need to be handled.

As a general principle I've tried to keep only a few objects on each screen of the web interface. This keeps the cognitive workload down and the number of things within the buffer size of biological working memory. If there's too much screen clutter then that will make it hard to use. I've stuck to a simple color theme which is hopefully high contrast enough for low vision, and the amount of wording on each screen is kept as small and as direct as possible.

A tricky part of the new user interface was the backup system. If you're running a server then keeping a backup of data is essential. The previous system required making separate keydrives and backup data drives and also included a LUKS formatting step. For a mass market type of system I thought this was too complex, involving too many steps and with too much chance for someone without scrupulous opsec to make mistakes. So I redesigned how backups happen. They're still encrypted with GPG, but the keys are stored on the backup drive and encrypted with a password. This means that it's possible to buy a USB drive, plug it into the server, select "backup" and it will work without any separate formatting step. If you leave the USB drive plugged in then it will make backups automatically once per day. If you later lose the backup drive then the password still protects the keys and therefore the rest of the data.

Another thing about passwords is that I've followed the existing policy of by default not allowing the user to select their own password. This is different from most other systems, including FreedomBox. Instead on first startup the system gives you a random password and tells you to write it down or store it in a password manager. I'm going on the assumption that if the user chooses their password they will choose the name of their cat, or password123, or something else which is trivial to crack.

I've also been rearranging the website such that it assumes a mass market type of deployment, with a mockup of a boxed product in the admin guide.

Whether Freedombone actually does become a mass market thing remains to be seen, but this is a first attempt at moving it in that direction.

XMPP Notifications

Another of the features I'd wanted to add to Freedombone for a long time was server notifications via XMPP, and now that has been added. This is for things like notification that an upgrade or security test has failed or that the tripwire has been triggered. Previously those notifications were only via email, but I'm not very obsessive about email and rarely check it, whereas instant messages are much more likely to get my attention.

The security policy for XMPP chat was previously set such that end-to-end security was required, but it was difficult to automatically send out an OMEMO encrypted message from the server and so I've had to downgrade end-to-end security to being optional. This is not ideal, but the tradeoff between having to deal with folks trying to send me plaintext messages and being promptly alerted if something has failed on the server is probably worth it. Longer term I'd like to figure out if I can automatically generate OMEMO messages and then I can return to a better security policy.

The main factor which delayed the implementation of this was the question of needing to generate a separate XMPP account on the server to push out notifications. I didn't really want there to be a permanent separate account with a password lingering around somewhere which could become a possible security vulnerability. The solution to this was to generate an ephemeral account purely for the purpose of sending a single message. A new notification XMPP account gets created with a random password, sends the message and then about one second later the account is deleted. Even if the account credentials were to leak during the sending of a plaintext message they can't subsequently be useful to a potential adversary.

Another addition to the notifications system is being able to send a webcam photo if the USB canary is triggered. The purpose of that is to answer the paranoid question "Is anyone trying to mess with the server while I'm not at home?" if you're out shopping or at work. The particular threat model is known as evil maid. If you're running Freedombone on an old laptop and have a secondary webcam plugged it it will preferentially use that, so that you can set up the field of view appropriately. Not many people will need this level of physical device security, but it's nice to have the option. Also if you have the Syncthing app installed then any USB canary photo will be synced to the admin account.