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.
I had been hoping to begin distributing image files for the Freedombone project via the Dat protocol earlier in the year, before the 3.1 release, but at the time other things were more of a priority. Recently I returned to investigating how to do that, and there is now Dat version of the website and downloadable images. If you have the dat command installed then downloading an image is just a matter of doing a "dat clone [link]", similar to cloning a git repo.
The peer-to-peer nature of dat means that this method of distributng large files (typically about 3GB each in compressed format) is a lot more scalable than just directly downloading from one not very powerful server. Like git, the data is content addressable and can be seeded by arbitrary numbers of peers so it doesn't have to reside in any one place. The more peers there are the faster downloads can happen, and being distributed provides some amount of censorship resistance.
So dat will be the preferred distribution method for image files in future. The previous method worked, but my server did struggle sometimes and I had to stop downloads of images happening via the onion address because it was saturating Tor's bandwidth limits.
There are other interesting possibilities for dat which I'll also try. I don't know if git repos can be hosted via dat, but doing remote backups using it would be quite feasible and perhaps better than the existing implementation in Freedombone.
I think I've done most of the necessary preparation now in readiness for getting out of Github. I had been claiming that I was going to do that for the last three years and its recent purchase by Microsoft provided me with a slam-dunkin reason to finally do it. I've slated closure of my account for 11th of June 2018, added as a TODO item in org-agenda. That will give enough time for any Freedombone systems out there to automatically update the repos to the new location.
It has been fun being on Github. I stayed there because it mostly seemed to not be evil, despite being another proprietary silo. People sometimes had a dig at me for the hypocrisy of promoting self-hosting while having the repos in a silo, and they were entirely justified in doing so. The main advantage of Github was just visibility and searchability. Apart from that other systems such as Gogs, Gitea and Gitlab have very similar features. It's the same kind of reason why video creators post to YouTube rather than just their own sites. You can self-host videos, but who is going to discover them? Similar applies with software projects.
Like many folks from the FOSS side of the world I could rant at length about Microsoft. In recent years during the post-Ballmer era they say they've become a lot more friendly towards open source. They fund the Linux Foundation and some of their software is released under copyleft licenses. But not much of it is. Their desktop and server/cloud operating systems, and their office productivity software remains, as far as I know, closed source. They also still extort people using software patents. This indicates to me that Microsoft's new found love of FOSS is just superficial and that fundamentally their interests or corporate ethos have not changed. Having some FOSSy things enables them to recruit bright young engineers and makes for some nice sounding publicity material at conferences. They will no doubt claim that buying Github proves - via putting their cash where their mouth is - that they are an honest player on the FOSS scene. But a couple of years down the line I expect that Github, if it still exists at all, will be pushing ads, might have some login which requires being on a Microsoft platform and will be very specific to Windows, Microsoft APIs and Visual Studio. Anything else which can't be locked in will be sidelined and then dropped like a coyote over a cliff edge.
But in a way Microsoft has done me a favor. In buying Github it made a decision which was a fuzzy trade-off of social and technical factors into a clear line in the sand and a question of which side you're on. Their acquisition will cause some amount of dissruption to FOSS development, and I'm sure they must have been aware of that as a desired outcome when they made the deal. Lots of installed things point to Github repos and if there are enough projects leaving Github then those things will start breaking.
So what's the way forward? We have quite good replacements for Github, but they lack the community element. Perhaps the fediverse protocols can help here, adding a single sign-on and a federated way of publishing changes and discussing features and bugs. Another possibility would be to create a software directory on a distributed hash table. I think the developer community has the capability and now the motivation to begin tackling these problems. Producing another giant silo like Github isn't the answer.
There has been an app on F-droid for the FreedomBox system for a while now and I was wondering whether I could do something similar for the Freedombone project. I didn't know anything about how the FreedomBox app worked, so I assumed it was an Android version of the Plinth user interface and was trying to figure out how the connection between the box and the app worked.
But it later turned out that wasn't what the FreedomBox app was doing at all. It's not a userops app but instead is more of a helper app to make it easy to install and run the client apps needed to work with the box. This is the type of thing which you might tell other members of your household/apartment/dorm/hackspace/commune to install so that they can use the services of the local server. It will guide them to the relevant sections of F-droid or the Play store, or open the relevant apps or web pages.
It was suggested that provided Freedombone can talk the right json protocol then the FreedomBox app would also work with it. This would avoid needing to re-invent the wheel. Communication between the box and the app is one way only, so there aren't any security implications and no credentials or other private information is involved. The most an adversary on your local network could learn is what systems are available on your server.
Some amount of wrangling later I got it working. An additional patch to the app was needed so that web pages for particular Freedombone apps, typically installed onto subdomains, can be opened from the FreedomBox app and that has since been merged upstream.
This makes Freedombone a little more consumer friendly, but the main administration remains only via ssh and so unlike FreedomBox this isn't really a consumer grade system yet. Anyone who has used a Raspberry Pi without a screen should be able to use Freedombone though. I'm not yet decided on whether to go all the way and try to do something equivalent to Plinth. It might be a lot of work, and I'm really not much of a front end developer. If I can find a low maintenance and minimalistic interface which can also be secured then I might give it a go, but I don't want to get distracted into maintaining a giant django app or anything comparable.
RSS is an old technology, but still useful. It's disappointing that it's not better supported by browsers but that's understandable given that it's a system which tends to make it easy to view content without adverts or other distracting links/images. I'm pretty sure that's the main reason why Google stopped supporting it when they controversially dropped their own reader.
I've been running Tiny Tiny RSS for a long time. The server software is modified so that it grabs new feeds via Tor, and this helps to avoid having any third parties gaining knowledge of what you're reading. The last I read, the maintainer of TT-RSS still has no interest in supporting proxying via Tor.
TT-RSS is great, but it's also quite complicated and the reading experience on mobile has been frustratingly flaky. As time passes I'm starting to read RSS feeds more on mobile devices and less on desktop operating systems with large screens. I've tried most (possibly all) of the various TT-RSS mobile readers for small screens, and didn't like any of them very much. So I was wondering if I could replace TT-RSS with something simpler which would work both on desktop and mobile. Searching around on Github I found an existing project with not much code and adapted it until it was sufficiently usable. The result is a new RSS reader called Smol RSS.
Smol RSS, as the name suggests, is a very small php system which allows you to select a feed from a drop down list and then view it. The way that it works is such that the feed is grabbed locally within your browser and not by the server. So installing to an onion address means that when you're browsing through feeds there isn't an easy way for a third party to know what you're reading. Orbot now supports version 3 onion addresses, so this also gives a good level of confidentiality. Unless you give out the onion address it would be hard for anyone to know what it is or that you are associated with it.
Smol RSS is an extremely minimal reader, so there are no advanced features like in TT-RSS. But for my purposes this is good enough and a lot more convenient. It's now an app within Freedombone, and I added both light and dark themes which are selectable via app settings in the admin control panel.
why not just use a native mobile app for RSS? I could do that, but having something on a server means that there's more convenience when using multiple mobile devices. I can set up the feeds list in a single place and then that applies no matter where I access it from.
Yesterday there was a security flap over possible PGP bugs. There's some legitimate concern behind it, but the biggest feature of this disclosure was that the way that it was communicated was really poor and alarmist. There have been a series of high profile software bugs over the last five years and the trend seems to be to always create a bigger razzle than the previous one.
As far as I can ascertain the security implications for the Freedombone system are zero, even though GPG is used quite extensively within it. Freedombone uses the Mutt and Mailpile email clients and neither of those are very affected. Mutt has S/MIME turned off and Mailpile doesn't display HTML in emails by default. There are a few issues with Mailpile which are described here. The TL;DR is that unless you are reading encrypted mail from 10+ years ago and you're being actively targeted then there isn't likely to be a problem.
In reality efail is a low impact security issue with some email clients or some people running extremely old versions of GPG. These issues had also mostly been known about for a long time.
This wasn't how the problem was publicised though. Instead the advice from EFF was to immediately turn off PGP encryption or uninstall PGP software. Even if you are running an email client which has one of the efail problems the EFF advice was not an appropriate or proportionate response. It suggested to me that the people at EFF were not thinking in terms of threat models. Out there in the wild how likely is the exploit to happen and what are the chances of that weighed against the security features provided by GPG/PGP email encryption? Most users of PGP are not fools, and it has been widely understood for a long time that including HTML within encrypted email is bad opsec which can expose you to a bigger range of threats.
"Recommendations to disable PGP plugins and stop encrypting emails are completely unwarranted and could put lives at risk. The correct response to vulnerable PGP implementations should not be to stop using PGP, but to use secure PGP implementations"
In the years after the Snowden revelations quite a lot of effort went into getting more people - especially those in "at risk" categories - to encrypt their email. To then encourage all that to be thrown away was reckless and I think there is still a debate to be had about what constitutes "responsible disclosure". What information was EFF supplied with and why did they report in the manner that they did? Was it just clickbait one-upmanship, or something else? Nothing on the internet is perfect and security software which has some bugs under some conditions is probably still better than transmitting communications in the clear where it can be trivially read by any intermediary.