Freedombone Blog

Freedom in the Cloud

Beginning on Buster

In the last couple of days I've started work on the buster branch of Freedombone. "Buster" is the codename for Debian version 10. It's not officially released yet, but is expected to be within the next few months and by the time that happens there should be an equivalent Freedombone version. I expect that it will take a while to get fully working, but I already have an image which builds and a few apps which are confirmed as being installable. Email also appears to work with only a small fix to Dovecot settings. Searx search and the web interface also work.

Based on initial tests I think the upgrade from Debian 9 to 10 is going to be easier than it was from 8 to 9. It will still take quite a while to test the installs for each app, and sometimes different package versions need to be used.

Debian 10 brings PHP version 7.3, and that means that Pixelfed and some other new apps will be installable. It will also be able to support more single board computer models and TLS version 1.3 will arrive.

The future is looking quite good for self-hosting and the stability of the Debian GNU/Linux operating system makes it possible to run a server at home without constant maintenance.

Muted Words in Pleroma

There has been a recent addition to Pleroma which allows for posts containing matched keywords to be blocked. It's already possible to block individual fediverse addresses or entire domains and so this adds even more granularity such that you can get a good level of control over what does or doesn't get into your timeline.

This is now accessible in Freedombone via the blocking controls on the settings screen. There is a button called muted words which then allows you to define a list of words or phrases to be blocked. The blocking will apply both to local and federated timelines and it's very similar to the feature with the same name on Twitter.

Image description

Muted words already applies to email and XMPP and so the settings screen allows you to define a single policy which will be applied to any installed apps. This might also be useful for parental control if you have a few members set up.

If you're running on a single board computer the application of blocking rules can be a bit slow and it can take a few minutes for Pleroma to become usable again after a settings change, because it needs to recompile. During this time you can expect to see a 502 gateway error.

Adding Padding to OMEMO

I've enabled OMEMO padding within DarkMessenger. This regularizes the message lengths to a minimum of 64 bytes, and thereafter quantized in chunks of 32 bytes. If you are a passive adversary listening on the wire then regardless of how random-looking the cyphertext may be, message lengths still reveal some (probably small, but not zero) amount of information about the conversation. It may be possible to use small and common messages, such as "hi" or "ok", or common emojis, as cribs to then begin to attempt decryption. Having a minimum message length and quantized plaintext lengths removes that as a possibility such that from the passive "bulk surveillance" point of view messages all look quite similar and are harder to track through multiple onion unwraps.

OMEMO padding was a patch I submitted a few years ago, but because it's not in the XEP it never made it into production. A random sequence of spaces and tabs are added before the beginning and after the end of every message such that its length becomes a multiple of 32. On the receiving end the plaintext is trimmed to remove the padding. This has the advantage that even if the message "hi" is being sent an adversary doesn't necessarily know where within the 64 byte padded string the text begins.

The new DarkMessenger version (1.1.00) can be downloaded here.

The rush to TLS

Issues which I've been encountering recently with XMPP are all about TLS and differing threat models. It seems as if LetsEncrypt has been around for ever, but really it has only been usable in the last two or three years. During that time an increasing number of internet applications just assume that TLS authentication is in place.

Before LetsEncrypt XMPP servers typically allowed self-signed TLS certificates or no certificates. Recognition by Certificate Authorities (CAs) wasn't mandatory. But increasingly now it is. This is all fine except in cases where you don't need TLS or where Certificate Authorities are untrusted and belong in the threat model. That's usually the case if you're running XMPP on onion addresses. After all, CAs include numerous dodgy companies and entities like the Chinese government.

So if you're setting up an XMPP server with the intention of using both clearnet and onion addresses then there's a conflict of interests between the two routing worlds. The clearnet would like CA-recognized TLS certificates to always be used. The onionspace would prefer that to be optional or not present.

In the rush to implement TLS everywhere, and thereby secure the internet from the evildoers, minority use cases like onion routing have been forgotten about and there isn't a clear solution if you want to inhabit both worlds.

As a workaround I've added a settings screen for the XMPP app within Freedombone which allows TLS authentication to be strictly enforced or not.

Matrix addendum

There has been a recent talk about Matrix at FOSDEM 2019 in which it's said:

As of Matrix 1.0, we require homeservers to present a CA-signed TLS certificate

So very much the same problems are going to apply to Matrix on onion addresses quite soon. Probably the version of Matrix on onion-only versions of Freedombone will need to be modified in order to federate, and will be non-compliant with the spec. If that's infeasible then it might be that Matrix on onion will only be non-federating, which would be disappointing.

Addendum addendum

It looks like Matrix will be ok after all. In the recently published federation API it says:

The TLS certificate provided by the target server must be signed by a known Certificate Authority. Servers are ultimately responsible for determining the trusted Certificate Authorities, however are strongly encouraged to rely on the operating system's judgement. Servers can offer administrators a means to override the trusted authorities list. Servers can additionally skip the certificate validation for a given whitelist of domains or netmasks for the purposes of testing or in networks where verification is done elsewhere, such as with .onion addresses.

Dark Messenger

Recent testing of the Conversations app with an XMPP server running on the onion-only version of Freedombone revealed that it no longer worked. This was strange because for the first few years of development of the server system I used this as a test case, having messages go back and forth between a phone and a laptop using the onion server and no clearnet.

I think what has happened is that within the last year or so enforcement of TLS within XMPP clients has become stricter and can no longer be easily bypassed or turned off. While LetsEncrypt is a great thing if you're not using the clearnet then the imposition of strict TLS can become a problem leading to bad or in this case broken user experience. It's yet another example of how minority use cases sometimes get disregarded.

The changes needed to get the app working with an onion-only server again are fairly minor but unlikely to be upstreamed. So I've made a fork of Conversations dedicated to messaging using onion addesses, called Dark Messenger. Dark as in darknet or "going dark". Most of the effort was actually just changing the branding to distinguish it from the main Conversations version. You can run the two apps on the same phone without any interference if necessary.

dark messenger on a mobile phone

The dove is a CC0 icon and it symbolizes peace and reconcilliation. Also there is the dove in the biblical flood story who brings back the olive leaf as a sign that refuge was close at hand.

Noah then sent forth a dove, which returned the first time without good news; but the second time, she brought an olive leaf in her bill, plucked off, plainly showing that trees, fruit trees, began to appear above water.

Not exactly instant messaging, but a sort of message bringer during times of hardship.

Dark Messenger can be downloaded as an installable apk or as source code from the downloads section and the development repo is here. You won't find it on any app store.

There are various advantages to this kind of setup, and it's hard to accidentally send anything insecurely. In the longer term Briar might become a better option, because it doesn't need any servers.

The ethical technology of 2019

I'm reading this article and agree with the overall aim of trying to produce more ethical technology. I've you are a Free Software person then you've always been interested in ethics.

But there's lots of cringe-inducing things in the article, especially when they describe Mozilla.

"When building a product, designers should make the default settings the ones that will be best for users. Firefox is a good example. After completing more usability tests, the browser will start blocking third-party trackers, which collect your data as you surf the internet, by default."

Well that's great, but also by default Firefox collects data about exactly how you use the browser as you surf the internet and sends it back to Mozilla. You're not informed about that at all. That data could easily be used to create tracking fingerprints, and Mozilla Corporation's business relationships with search engines - particularly Google - are sufficiently opaque that it's an easy supposition to make that a scandal could be brewing.

Will sending software engineers on ethics courses fix the problems of the tech industry? No. But it would make the engineers more aware of bad ethics in business practices, and they'll be less happy while working.

Will having a "Trustable Technology Mark" certification improve things? Maybe, but probably not. The closest I can think of would be FSF's Respects Your Freedom certification so it might not be an entirely worthless exercise but much would depend on the details. FSF has the list of four freedoms which are a fairly concise criteria against which to check any given product, whereas "trustable technology" could be a lot harder to define.

Making users owners is the best advice from the article.

"make your users the owners of your platform–not venture capitalists, not shareholders"

This requires business models to change and for advertising to no longer be the primary revenue stream. Working against this though is the web 2.0 consensus, which concluded that nobody will pay for web services. The next billion internet users are not likely to have spare cash hanging around with which to invest in startups or pay for subscription services. They're going to be using low end smartphones and the margins will be wafer thin.

One possible way to go with ownership of technology is the Guifinet model, in which you have a foundation which sets some rules and perhaps runs crowdfunding campaigns, but the resulting network is owned and run by the users. When that's the case then the interests are aligned and you're not likely to see the kinds of large scale abuses that the tech silos currently impose.