Native apps

The native Sailfish OS experience revolves around gesture based control, very much like on the Nokia N9. On the Nokia N9, you had a nice curved glass on the sides of the phone, which elegantly captured the swiping motion you used to minimize an app. Sailfish OS inherits those gestures, and I find this way of navigating rather convenient.

How well those gestures work, depends on the quality of the port of Sailfish OS. I have never had many troubles with this myself, and I was told Jolla is taking extra care on the new Jolla Phone.

Native apps are built using stacked pages. Clicking items in an app opens a page, and moves in with an animation from the right.

Closing a page follows the opposite motion: swiping on the page to the right will “pop” the page from the stack, more or less the analogue of Android’s “back” button. Sailfish OS shows a little indicator on the top-left if this back-action is available.

These gestures, together with colours, headers, font sizes, icons and more, form a consistent design language for the whole operating system. This is one of many reasons why I prefer native apps to Android AppSupport: everything feels (and is!) integrated with the operating system. Android Apps just feel off, and they’re really a necessity rather than a convenience.

My day on Sailfish OS

I am one of those people for whom waking up is a nightmare. I get woken up by the lights in my bedroom turning on 100% brightness, thanks to Home Assistant. If I need to access something in Home Assistant, I open the user interface in the Sailfish OS Browser (more on browsers below). Home Assistant’s web interface works well enough for me. The native Home Assistant apps aren’t to my liking, and the Android app feels way more out of place than the browser does.

I usually grab my phone to scroll Reddit on Quickddit a bit before I get out of bed. Or, admittedly, Instagram. It happens. I’m sorry. At least I’m using the Android app in the AppSupport container, as not to pollute my browser. These days though, I really like Mastodon, and I’ll usually have a quick scroll through with Tooter β as well.

( Quickddit, Tooter β, Instagram Android, Calendar)

Anyway, I should be telling those things to my therapist instead of blogging them. At this point, I’ll unplug my phone around 80% battery charge, because I limit the charging to preserve the battery life. What my phone does after, depends entirely on the planning of the day. To check my planning, I use the built-in Calendar application. This app is still closed source as far as I can tell. However, it’s excellent, and it’s built on the open source Nemo QML calendar plugin. Unless you’re a rebel with a cause, you can’t legally find the Calendar app source code on /usr/share/jolla-calendar on your device. I host my calendars on my Nextcloud instance at home. Furthermore, I wrote a script that spits out my Taskwarrior tasks as an ICS file on scheduled and due dates, which is also ingested by the Calendar app.

Most of my days, I walk to my office at VUB. It’s a short walk, and the shortest route passes by an incredibly nice sourdough bakery. I can’t pay with my phone’s NFC there, which I honestly don’t mind. They take cash and normal cards.

Driving

I drive an EV, a Renault Zoe ZE40 from 2017. It’s a lovely little thing. Renault provides an Android app, which you can use to change some charging parameters, or to remote start the climate control. This is one of the very few Android apps that manages to detect the “non-legitimacy of my device”, and I have no clue whatsoever why Renault would want to enforce a locked bootloader. I had the app configured on a “real” Android device, after which I could use the account via Home Assistant. My Browser has a shortcut to open the page for the car, and I’m quite convinced that works even faster than opening the app. Another advantage: I can built automations around this!

When driving, I will usually either listen to a podcast or to an album. My Renault’s infotainment system connects to the phone via Bluetooth (calls work fine, although there’s a microphone audio quality issue on the Xperia 10 IV and V). I noticed that the car automatically triggers a Play action when it connects. I abuse this by making a paused playlist when I’m heading out, which then automatically starts when the car has booted up. This is all just regular MPRIS over D-Bus at the Sailfish OS side.

(Home Assistant in the Browser, controlling my car, Unplayer, gPodder, Whisperfish)

If it’s music I’m listening to, I generally use Unplayer. It doesn’t have gapless playback, and hasn’t been updated in some centuries, but it’s otherwise fast and easy to use. (See post-scriptum below.) My music is stored on a 64GB µSD card in Opus VBR format. I have yet to test whether DeadBeef Silica works for me; I was told it supports Opus and gapless playback.

Often, I’ll be listening to music over Bluetooth. I have Sennheiser Momentum earbuds (MTW4). I can’t recommend them, the MTW series has quality control issues. My current ones didn’t break yet. They sound incredible (even without Apt-X support, not sure which magic drives them currently), and their noise cancellation is terrific. I also have a Bluetooth DAC and a Bluetooth DAC-and-AMP from SMSL. In general, Bluetooth audio works rather well, as far as Bluetooth audio goes. The Xperia 10 IV and V issue regarding Bluetooth microphone quality is annoying, and so is the lack of Apt-X support. I am quite confident that the former will not be an issue on the Jolla Phone, and the latter doesn’t really bother me. It’s Bluetooth after all. If it’s quality that I’m after, the SMSL’s have USB and optical inputs.

For podcasts, gPodder is pretty much perfect. (See post-scriptum below.) I currently have a bug where its start-up takes some minutes because one of the podcasts is super slow to load. Haven’t had the time to debug it yet.

Back home

The one app which I use the most is Whisperfish. I somehow got most of my friends and family on Signal, and Whisperfish is my way of staying in touch with everyone I care about. Whisperfish has quite some history, and I think it deserves an “intermezzo” post in this series, not only because I co-maintain this app. I have Whisperfish open all the time, 24/7, everywhere I go.

I own a SwitchBot K10+ robot vacuum. I chose this vacuum because it supports a local API, because they officially support Home Assistant, and because it’s nice and compact for my 74m² flat. Getting it connected is another story, however. This required a “real” Android device, again, this time because of Bluetooth: Jolla’s Android AppSupport doesn’t currently pass through Bluetooth. Lack of Bluetooth on AppSupport is a major nuisance for users, but Jolla seems to have it figured out. After connecting, the SwitchBot app connects on my Sailfish OS device as well. The SwitchBot is usable on a daily basis (obviously I automated it such that it runs when I’m away from home). If I want it to clean a specific room, I need to start the Android phone, because the map doesn’t render correctly on AppSupport, and this makes the app completely unusable. It’s really odd, and it’s the only rendering issue I’ve ever seen on AppSupport. I should file an issue about this…

Other daily apps are the banking apps. My main bank is Argenta. I also follow Bogle’s advice, for which I have accounts at a few brokers. All these apps work just fine, no complaints and no issues. In Belgium, we also generally use Itsme, an identity provider built by a private company, founded and funded by a banking consortium. Lately their authentication procedure changed to requiring the scan of a QR code, which the Xperia 10 IV can’t do, because it misses camera drivers. Allegedly this mostly works on other devices with a camera.

Camera

Camera support has generally worked on Sailfish OS, except now for the Xperia 10 IV and V. Because of that, I’ve taken to a new hobby; I’ve taken to photography with a supercompact Sony RX100. It fits in my pocket, and the photos are fantastic. I wrote a little app called FishEye to quickly transfer pictures from the camera to my phone, as to share them via Whisperfish. Sailfish OS isn’t up-to-speed with modern smartphone photo processing techniques, as you might expect. If you want “iPhone quality photos”, you should probably either get an iPhone, or dive into photography like I now did. It’s fun, the water’s warm (and not oversaturated blue), join the dark side!

Browsers

My main nuisance on a daily basis is the Sailfish OS Browser. Compared to using Android Fennec on AppSupport, the built-in browser feels a lot more snappy. However, it’s currently built on Gecko ESR 91. That’s old; 2022 is a long time ago. It’s not just old as in “websites tell you to update”, it’s old enough that certain sites don’t even render anymore. It turns out that developing a browser is really darn difficult, and requires a lot of work. Just the ESR 91 port took little over a year.

For things that don’t render (or things that I think require some more sandboxing), I use Fennec from F-Droid. It’s annoying, but it works well enough. I know that people use Firefox or Fennec on AppSupport all the time, and never use the built-in browser.

Something new popped up some days ago though. A few days ago, we got to know that several Wayland and Lipstick dependencies were bumped and improved, to support native Qt6 and Gtk applications. The same person has an interesting repository on Github called “Firefox”, and has been committing to it with an email address ending in @jolla.com. If you’re lost in technicalities: this is extremely good news, and means we could get a more maintainable browser soon!

More apps

The above covered the more “interesting” apps. Either they were interesting because of how surprisingly well they work, or to mention their quirks. There are plenty of other apps though, which I don’t necessarily on a daily basis. Let’s get them through in two or three sentences. Not because they’re not cool, but because I’d need at least two more of these posts to decently cover them. BarWal is an app for storing loyalty cards any kind of barcodes, which I use for loyalty cards. Pure Maps is amazing; it renders a map with pluggable back-end provider (I use OSM Scout Server for hybrid offline-online support), and has a built-in navigation system. Kuri is an app to track workouts (or share your hikes with friends and family, because it supports Strava uploads).

( Gallery, Kuri, Pure Maps, collection of travel apps I use)

Another bunch of “boring” apps are Phone, and People. Calling people works as you’d expect, and my contacts sync with Nextcloud. The Gallery is relatively simple, although its Nextcloud integration is now quite neat.

A story about app stores

This article is becoming way too long, but I believe I conveyed my message by now. There are many very neat native apps which just work.

One thing which may be confusing to newcomers is the many sources for apps. Sailfish OS apps are RPM packages. There are three important sources for Sailfish OS packages and apps: the Jolla Store (“Harbour”), OpenRepos (via Storeman), and Chum.

First is the Jolla Store, sometimes referred to as “Harbour”. This is Jolla’s official app store, is curated by Jolla, and also hosts some Android apps. It is also your main way to install the commercial offering: the Exchange plugin, the Android AppSupport. Jolla is quite strict in what apps they allow, and what those apps are allowed to do on your phone.

The apps on Harbour are high-quality, but sometimes an app developer requires some more freedom than what Harbour currently allows. There are two big community repositories that are more lenient. OpenRepos is the oldest, and also hosts apps for Harmattan, i.e. for the Nokia N9. The most convenient way to access it, is through Storeman.

The newer, preferred source for community apps is Chum. These apps are centrally built on the Sailfish OS Open Build Service, which gives some better form of quality control. The Chum GUI app is the most convenient way to access these applications.

Generally, you should prefer Harbour, then Chum, then OpenRepos.

Android users are generally used to the Google Play Store. Since AppSupport is not a Google product, and hopefully will never be a Google product, it’s generally not recommended to install the Google Play Store (or anything Google Play). As an alternative for your needs of proprietary Android applications, you should consider Aurora. It’s a free, GPLv3-licensed client for the Google Play Store. You can download it from Harbour. Some apps will expect Google Play to be present. You might be interested in microG as an open source and controllable alternative.

Of course, F-Droid needs mentioning as well. F-Droid is a free store, which serves only free apps for Android. F-Droid is fantastic, and your AppSupport experience would not be complete without it.

At this point, this article has become way too long. The plan is to end the series with a final post to tie some loose ends. Did I miss an app? Get in touch on Mastodon and I’ll be happy to comment or cover in a follow-up! Definitely have a scroll on the reaction on Mastodon, some people recommend podQast over gPodder, and FoilAuth over SailOTP.

In the next episode of this series, I’ll do a Whisperfish intermezzo: the app that I co-maintain, and share its story. Talk to you soon.

post scriptum

Meanwhile, I have switched from gPodder to podQast for podcasts, at the suggestion of several people on Mastodon. At the time of writing, the version on the Jolla Store does not support MPRIS, but the one in OpenRepos does. I also swapped Unplayer for the built-in Media app. I had some trouble with it indexing unrelated files, but some touch .nomedia later it’s actually pretty neat.

Sailfish OS: the most usable Linux in your pocket

Somewhere around 2010, I was happily using a Nokia clamshell phone. It did what it had to, and it had worked for years. At that time, it was apparent that the world was moving toward smartphones: mobile devices with internet connection, a browser, a camera, a fancy screen, and way more compute power than those old-fashioned GSM-era devices. And apparently they could be used as a phone as well.

I was quite repelled by both the iPhones and Android phones at the time. Both were, and still are built by monopolists. Apple’s offering is marketed with privacy, but lacks the freedom to tinker: the whole ecosystem is locked down, and not very suited for the tinkerer and hobbyist that I am. Google’s offering was a more open ecosystem: the base operating system was open source, mostly free, and Linux based. However, something felt off. Whereas the Android operating system might be free and open source, its spirit is not. Google dictates the direction of the system, and their grip on the ecosystem keeps on tightening. Paradoxically, the free and open source Android seemed to be more privacy infringing than its proprietary rival.

At some point I learned about the Nokia N9. Contrary to iOS, this device was mostly free and open source. And contrary to Android, it was built around existing, well-known software stacks. The MeeGo operating system (technically called Harmattan) was built around Qt and QML, and the base Linux was an actual GNU/Linux. The thing even shipped a terminal emulator!

(left: Nokia N9, right: Jolla)

I got my hands on what was probably the very last device on sale in Belgium, and it is still my favorite phone to date. It was opinionated, featureful, and quick despite the rather limiting 1GHz single core processor. Sadly, it became obsolete quickly. Nokia sold most of their smartphone business to Microsoft, and Microsoft did what Microsoft does best: drop what is interesting, and then try and fail to make something nice out of the remaining pieces.

Jolla and Sailfish OS - from 2014 to 2026

Some of the parts did not end up in Redmond hands. Instead, a few brave souls at Nokia ran off and founded Jolla. I was still happy with my N9 when they released the Jolla: the spiritual successor to the Nokia N9 hit the market. I got my hands on it some months after it started shipping, especially when it became clear the N9 would not receive any more updates. The Jolla itself got very mixed reviews. Hardware-wise, it was a significant downgrade in many aspects. The screen was a rather dim LCD (being used to the N9’s utterly fantastic OLED), the more advanced and featureful software meant that the dual-core with 1GB RAM was quite limiting, and the camera was akin to a potato compared to the Carl Zeiss glass in the N9.

Still, it was an attractive device. It was backed by a company, and developed with a community. The operating system, Sailfish OS, was a true GNU/Linux system, which I usually explain as “OpenSUSE with a mobile-first Wayland shell”. The thing works out-of-the-box. You can browse the web, read and write emails, take pictures, look at videos, open a terminal and use ssh, and text and make phone calls. Their commercial offering was mainly “Alien Dalvik”, now Android App Support, which is an LXC container for your Android apps. Since 2014, Jolla has been through many rough waters. I’m sure you’ll find plenty of articles covering those. After the Jolla, their focus was on Sony Xperia devices (“Sailfish X”). These smartphones had the “open device program”, which made them relatively easier for Jolla to port to Sailfish OS. My personal Sailfish OS journey after the Jolla phone was: Jolla, community-ported Motorola Z Play, Xperia 10, Xperia 10 IV (with a lot of issues). Until recently, the Xperia series was the best way to enjoy Sailfish OS. Jolla announced the Jolla Phone (sometimes shortened to “the J2” by the community), a device with actually really decent hardware specs (if you decide to order one, feel free to add Jolla-Phone-10K-0976f49b15f4 to the discount field as my referral code). Finally, we will have an official high-end Jolla device. I am very much looking forward to this. I may or may not have held one in my hands during the French speaking community meeting in Lyon, and my opinion has only improved.

(left to right: Xperia 10 IV, Jolla C2, Xperia 10, Jolla, Nokia N9)

Sailfish OS as a community

Between 2014 and 2019, I was a silent Sailfish OS user, enjoying Linux in my pocket. One of the apps I started to use the most was Whisperfish, a Signal client for Sailfish OS. Whisperfish was developed and maintained by Andrew E. Bruno in Go, but in 2019 he decided to call it quits. I took the initiative to completely overhaul Whisperfish, and write it against the upstream Signal libraries in Rust. Since then, Whisperfish has become one of the most downloaded apps, and the second most active topic on the Sailfish OS forum.

(Community dinner 2026)

This is to say: Whisperfish got me from being a silent user to an active community member. Every year, I look forward to engaging on FOSDEM, and to attend the community dinner. Sailfish OS is not just an operating system. It’s a group of friends with set of shared values: the freedom to use your phone as you please, a design language that feels consistent across the whole operating system, and a chat with the CTO and the CEO about their preferred beer of the night, somewhere during each winter.

Sailfish OS as a daily driver

In my next two posts, I will dive deeper in the apps that I use, the oddly specific tweaks that make my device really mine, and generally how I have set up my device. If you’re curious about Sailfish OS or my journey, do send me your questions on Mastodon!

This is what my phone, the Xperia 10 IV, usually looks like. Yes, I am writing this when it’s 19°C outside.

(left: events view, right: application drawer and application view)

Betreft: “Staatsgeheimen op Signal: waarom gebruiken toppolitici in VS de berichtenapp? En hoe (on)veilig is dat?”, VRT NWS, 25 maart 2025.

In uw interview van 25 maart 2025, getiteld “Staatsgeheimen op Signal: waarom gebruiken toppolitici in VS de berichtenapp? En hoe (on)veilig is dat?”, verspreidt u gevaarlijke desinformatie over communicatieapps. Signal is, zoals u zelf nog rapporteerde in Terzake op 20 maart de zogenaamde “gold standard” in veilige en private communicatie. Dit is niet enkel de repliek van Signal zelf; dit is ook de conclusie van zowat alle onafhankelijke experts en onderzoekers wereldwijd.

Uw interview kwam dan ook als een totale verrassing. Het is — uiteraard — verkeerd om een civiel kanaal zoals Signal te gebruiken voor staatsgeheimen, vanwege de redenen genoemd in het interview. Maar daarenboven argumenteert Kenneth Lasoen dat Signal “te prenetreren” valt en die “encryptie te kraken” valt door inlichtingendiensten.

“Natuurlijk zijn er wel inlichtingendiensten die over de capaciteiten beschikken om die app toch te penetreren en die encryptie te kraken” – Kenneth Lasoen

Voor zulke brede claims is op zijn minst duiding nodig. Er zijn geen publieke bronnen die deze claims ondersteunen. In het beste geval verwijst professor Lasoen naar de enkele gevallen van gelekte Signalgesprekken, waarbij de toestellen van de gebruikers zelf gecompromitteerd waren.

Daarna vertelt professor Lasoen dat Threema een beter alternatief is, omdat het gebruikt wordt door veiligheidsdiensten, alsook veiligheidsdiensten in ons land. Dat is op zich erg verontrustend, gegeven het historisch slecht track record van deze Zwitserse app. Kijkt u gerust ook naar de presentatie van Kenny Paterson, professor cryptografie aan ETH Zürich, over de veiligheid van Threema. Threema’s voornaamste voordeel voor veiligheidsdiensten is de mogelijkheid om de rol van gespreksdeelnemers te visualiseren: Threema geeft weer of een deelnemer al dan niet een bekend contact is, of deel is van je eigen organisatie.

“De servers staan op een hoog beveiligde locatie in Zwitserland en vallen dus ook onder het Zwitserse recht. Daardoor is het bedrijf ook niet zomaar verplicht om die communicatie over te maken.” – Kenneth Lasoen

Signal heeft een lijst van alle informatie die zij ooit hebben overgemaakt aan overheden. Of die alles bevat, of ze eventueel een subpoena hebben gekregen van een geheime rechtbank, is onbekend. Wat wel bekend is, is dat Signal enkel toegang heeft tot volgende informatie: laatste datum van registratie, laatste contactmoment van de gebruiker. Zwitserse servers kunnen een extra gevoel van veiligheid geven, maar het is niet omdat de servers in Zwitserland staan dat de communicatie veiliger is.

“Daarnaast kiest Threema ervoor om communicatiesleutels om de zoveel tijd veranderen. Wanneer een hacker de sleutel van jouw communicatie via Threema dus in handen zou krijgen, kan die jouw berichtgeving uit het verleden niet inzien.” – Kenneth Lasoen

Dit is opnieuw, in het allerbeste geval, een misleidende uitspraak. Het principe van sleutelrotatie is een standaardpraktijk in de cryptografie, die populair gemaakt werd door Signal. Daarnaast heeft Signal altijd zogenaamde “post compromise” security geboden, wat Threema pas recent heeft ingevoerd. Dit is opmerkelijk, want zowel de specificatie als de implementatie van Signal zijn openlijk beschikbaar, zodat Threema dit kosteloos had kunnen overnemen.

“De kwantumcomputer zit eraan te komen. Daar is ook Threema niet tegen opgewassen” – Kenneth Lasoen

De meningen rond toekomstige (of huidige) kwantumcomputers zijn verdeeld. De meeste onderzoekers zijn wel van het “better safe than sorry” principe, en hebben daarom algoritmes ontwikkeld die resistent zouden zijn tegen kwantumcomputers. Threema is inderdaad niet zogenaamd “post-quantum secure”, maar Signal is dat sinds bijna twee jaar wel, net zoals Apple’s iMessage.

“Zo’n computer maakt honderden miljoenen keren sneller berekeningen dan de computers van vandaag. Het zorgwekkende is dat een kwantumcomputer daarom in staat is de meest complexe en geavanceerde codes in een fractie van een seconde te kraken.”

Dit is een misvatting. Quantumcomputers zijn niet sneller dan “gewone” computers. Quantumcomputers hebben een aantal specifieke mogelijkheden die hen sneller maken in bepaalde, erg specifieke berekeningen, waaronder vermoedelijk het breken van het RSA en het ECC algoritme. Dit is exact waar de meningen verdeeld zijn: sommige onderzoekers geloven dat het fysiek bouwen van die specifieke quantumcomputer fysisch niet mogelijk zal zijn. De meeste huidige quantumcomputers die gebouwd worden, zijn niet eens gebouwd met die specifieke doelen in het achterhoofd.

Door deze desinformatie te verspreiden, overtuigt u mensen om over te stappen op een minder veilig alternatief. Dat brengt deze mensen potentieel in gevaar. Signal wordt gebruikt door klokkenluiders en journalisten, die in oorlogsgebieden en in dictatoriale regimes hun leven riskeren om de waarheid te kunnen rapporteren. Uw repliek is hierdoor levensgevaarlijk.

Jolla C2 discussions

The star of the show was probably the Jolla C2, a new device that Jolla has been working on. Sailors Raine and Matti brought a prototype with them. Jozef blogged about it and published some pictures. As expected, I was a bit sad with the screen on the device, but it seemed like a great device in any other regard. Raine was interested in hearing our opinions on the home screen rotation feature, and we had a good discussion about it over a beer or two (or three or four, I lost count). Looking forward to playing with it more when I get mine the next weeks!

Taak, and Rust apps in OBS

Taak is a simple frontend for TaskWarrior, written in Rust. I wrote it with two intentions: to make the simplest, cleanest Rust-app for Sailfish OS that I could think of, and to have a simple frontend for TaskWarrior on my phone. It also serves as a test ground for my Rust apps.

As @poetaster wrote on the forum:

I wanted to add that those two [@xmlich02 and @rubdos] propelled @pherjung to get a nearly complete rust env running and integrate with obs. It’s now up to us to help @pherjung complete the process and document how you set up rust dependencies (vendor dir ahoi!) to compile on obs … or @nephros will simply provide a cheatsheet and we’re all set 🙂

@pherjung and @xmlich02 were basically working on getting Rust apps – rubdos-style – to build in OBS, and as such Chum. If they succeed to build Taak in OBS, Whisperfish will soon follow!

Progress on Whisperfish

Matti and I have been working on Whisperfish, a Signal client for Sailfish OS. My personal goal for the weekend was to get voice calls working. I’m still compiling and testing as I’m writing this post, but I’m confident that we’ll have something to show soon!

Matti guided hoxifi to his first Whisperfish patches. The first patch is a much needed QtCreator project file, to get new contributors started with Whisperfish development in the more familiar Sailfish IDE.

Meanwhile, Matti and I made quite some progress. Linked devices was broken (again, again), because of some missing exchange of key material. Matti implemented the remaining bits to fix that issue.

With some help of poetaster, we got voice note volume normalization mostly done. Turns out it’s difficult to test, because the Xperia 10 IV has a broken audio recorder at the moment.

The bulk of my own energy went into voice call support (and soon™ video call support). As reported earlier, I had managed to get RingRTC and WebRTC to link in Whisperfish. The remainder is “easy”: link up the RingRTC API to the Whisperfish storage, networking, GUI, and multimedia processing frameworks. The past few days were spent integrating the ringing behaviour. Raine Mäkeläinen helped a lot on Saturday: he provided me with a demo application for the necessary MCE and ring tone integrations, which I could easily copy-paste into the Whisperfish QML code. I’d also like to thank Sebix and Pherjung to call me several times during the day, so I could test the ringing behaviour. At the time of writing (nephros just went home, three of us left in the Spálený Kafe coffee shop), I’m figuring out the networking and multimedia.

Closing note

I witnessed a lot of progress around me on several other apps (Tooter, Amazfish come to mind). I hope the other community members will blog about their progress too; this post would become way too long to summarize all the nice things that have been done.

Hereafter are some pictures to set the stage. It was a rather pleasant experience meeting all those people, and I hope to see this group again on the next Sailathon.

NOTE Sept 2025: Whisperfish does not have support for calling, yet. To include support for calling, we need a lot more work than just compiling the RingRTC library. This blog post documents the process of building and linking the RingRTC system into Whisperfish, but some users have interpreted this as to imply voice and video calling support. This is not the case. Currently, Whisperfish correctly decodes the calling state, and is able to display a “missed call” notification, thanks to the below work.

This post serves as documentation for my future self and others, and might be useful for people apart from Whisperfish devs. RingRTC is the library that Signal uses for its voice and video calls. It’s a library containing a lot of Rust code specific to Signal’s needs, see e.g. https://signal.org/blog/how-to-build-encrypted-group-calls/. It wraps WebRTC, the Chromium-library that’s used for voice and video calls in browsers. Specifically, it wraps a fork of WebRTC that contains additional security features, and some other Signal-specific changes.

Whisperfish is quite special in its use of RingRTC. In Signal Android, RingRTC can be loaded as a JNI library, separated from other C libraries. Whisperfish loads RingRTC as a Rust library, and it’s built as part of the Whisperfish build process. The WebRTC library, however, ships its own set of dependencies, by default statically linked into the library. This conflicts with our own shipping of OpenSSL 3 (as a dep for sqlcipher).

Building WebRTC without boringssl built-in is possible, but it’s not straightforward, especially since the necessary patches are not yet present in Signal’s fork of WebRTC. I have built WebRTC specifically for use in Whisperfish, and the resulting static libraries are available at https://nas.rubdos.be/~rsmet/webrtc/ . This post documents how I did that.

Cherry picks

Specifically this commit was needed to build WebRTC with BoringSSL as a dynamic system library:

• 459d6b1d9b - build: add options to configure libsrtp for boringssl or other libraries (9 days ago) <Philipp Hancke> This required a bit of merging to get it in. I also toyed with versions of dependencies to get things to link, but in the end that didn’t seem to matter much. They are in the no-ssl branch of my fork of WebRTC: https://github.com/whisperfish/webrtc/tree/no-ssl

Downloading WebRTC

One would hope that building WebRTC is as simple as git clone and ninja build, but it’s not. Google has a whole repository of shady-looking git wrappers and scripts to build WebRTC. This is mostly because WebRTC is a huge project with a lot of dependencies. Find the instructions at https://webrtc.github.io/webrtc-org/native-code/development/. Crucially, you need to alter the .gclient file after checking out the repo, to point to either Signal’s fork or now my fork:

solutions = [
  {
    "name": "src",
    "url": "https://github.com/signalapp/webrtc",
    "deps_file": "DEPS",
    "managed": False,
    "custom_deps": {},
  },
]

or

solutions = [
  {
    "name": "src",
    "url": "https://github.com/whisperfish/webrtc",
    "deps_file": "DEPS",
    "managed": False,
    "custom_deps": {},
  },
]

I am currently not sure how to tell gclient to use the no-ssl branch. I created the no-ssl branch, and continued from there. I think you can manually check out the branch, and then run gclient sync to get the correct dependencies on top.

Building

In the end, the following script yields four libwebrtc.a files:

#!/bin/bash -ex

export PATH=${PWD}/depot_tools:$PATH

export WEBRTC_VERSION=6478k
export WEBRTC_REVISION="branch-heads/${WEBRTC_VERSION}"

pushd src

NO_SSL="rtc_build_ssl=false libsrtp_build_boringssl=false no_build_ssl=true"

for arch in arm arm64 x86 x64; do
    gn gen out/$arch --args="is_debug=false target_cpu=\"$arch\" rtc_build_examples=false rtc_build_tools=false rtc_use_x11=false rtc_enable_sctp=false rtc_libvpx_build_vp9=true rtc_include_ilbc=false rtc_disable_metrics=true rtc_disable_trace_events=true rtc_include_tests=false rtc_enable_protobuf=false symbol_level=1 $NO_SSL"

    ninja -C out/$arch
done

popd

Most of the build flags come from Signal’s build script, and I added the ssl-related flags.

The resulting files are hosted on my home server, and include a SHA384 hash that is used in the Whisperfish CI build to verify the download.

The compiler that is shipped used in the ninja cross-build system is rather recent, but luckily the new SailfishOS 4.6 SDK is recent enough to handle the artifacts. The 4.5 SDK is not recent enough.

Building against OpenSSL3

The above script builds WebRTC against the default OpenSSL 1.1.1 (since SailfishOS ships that). Since most modern Linux systems ship OpenSSL 3.x, we also need artifacts that are built against OpenSSL 3.x.

You can build this by downloading the OpenSSL 3.2.2 tarball, running ./configure, and then running the adapted script:

#!/bin/bash -ex

export PATH=${PWD}/depot_tools:$PATH

export WEBRTC_VERSION=6478k
export WEBRTC_REVISION="branch-heads/${WEBRTC_VERSION}"

SSL_INCLUDE="rtc_ssl_root=\"${PWD}/openssl-3.2.2/include\" libsrtp_ssl_root=\"${PWD}/openssl-3.2.2/include\""

pushd src

NO_SSL="rtc_build_ssl=false libsrtp_build_boringssl=false no_build_ssl=true"

for arch in arm arm64 x86 x64; do
    gn gen out/$arch --args="is_debug=false target_cpu=\"$arch\" rtc_build_examples=false rtc_build_tools=false rtc_use_x11=false rtc_enable_sctp=false rtc_libvpx_build_vp9=true rtc_include_ilbc=false rtc_disable_metrics=true rtc_disable_trace_events=true rtc_include_tests=false rtc_enable_protobuf=false symbol_level=1 $NO_SSL $SSL_INCLUDE"

    ninja -C out/$arch
done

popd

The includes seem to be architecture-independent enough, that we don’t need to ./configure them for each architecture.

Initially published by petites singularités. English translation provided by OW2.

Open Letter to the European Commission

Since 2020, Next Generation Internet (NGI) programmes, part of European Commission’s Horizon programme, fund free software in Europe using a cascade funding mechanism (see for example NGI0 Commons Fund). This year, according to the Horizon Europe working draft detailing funding programmes for 2025, we notice that Next Generation Internet is not mentioned any more as part of Cluster 4.

NGI programmes have shown their strength and importance to supporting the European software infrastructure, as a generic funding instrument to fund digital commons and ensure their long-term sustainability. We find this transformation incomprehensible, moreover when NGI has proven efficient and economical to support free software as a whole, from the smallest to the most established initiatives. This ecosystem diversity backs the strength of European technological innovation, and maintaining the NGI initiative to provide structural support to software projects at the heart of worldwide innovation is key to enforce the sovereignty of a European infrastructure. Contrary to common perception, technical innovations often originate from European rather than North American programming communities, and are mostly initiated by small-scaled organisations.

Previous Cluster 4 allocated 27 million euros to:

• “Human centric Internet aligned with values and principles commonly shared in Europe” ;
• “A flourishing internet, based on common building blocks created within NGI, that enables better control of our digital life” ;
• “A structured ecosystem of talented contributors driving the creation of new internet commons and the evolution of existing internet commons”.

In the name of these challenges, more than 500 projects received NGI funding in the first 5 years, backed by 18 organisations managing these European funding consortia.

NGI contributes to a vast ecosystem, as most of its budget is allocated to fund third parties by the means of open calls, to structure commons that cover the whole Internet scope - from hardware to application, operating systems, digital identities or data traffic supervision. This third-party funding is not renewed in the current program, leaving many projects short on resources for research and innovation in Europe.

Moreover, NGI allows exchanges and collaborations across all the Euro zone countries as well as “widening countries”¹, currently both a success and an ongoing progress, likewise the Erasmus programme before us. NGI also contributes to opening and supporting longer relationships than strict project funding does. It encourages implementing projects funded as pilots, backing collaboration, identification and reuse of common elements across projects, interoperability in identification systems and beyond, and setting up development models that mix diverse scales and types of European funding schemes.

While the USA, China or Russia deploy huge public and private resources to develop software and infrastructure that massively capture private consumer data, the EU can’t afford this renuFuntoonciation. Free and open source software, as supported by NGI since 2020, is by design the opposite of potential vectors for foreign interference. It lets us keep our data local and favors a community-wide economy and know-how, while allowing an international collaboration.

This is all the more essential in the current geopolitical context: the challenge of technological sovereignty is central, and free software allows to address it while acting for peace and sovereignty in the digital world as a whole.

In this perspective, we urge you to claim for preserving the NGI programme as part of the 2025 funding programme.

Signed, Ruben De Smet, lead developer of Whisperfish, among many more.

On June 17th, 2024, I will defend my PhD thesis titled “Rapid prototyping and deployment of privacy-enhancing technologies” at the Vrije Universiteit Brussel. My promotors are prof. dr. ir. Kris Steenhaut and prof. dr. An Braeken, and my jury further consists out of prof. dr. Jan Tobias Mühlberg, dr. ing. Jorn Lapon, prof. dr. Ann Dooms, prof. dr. ir. Frederik Temmermans, prof. dr. Bart Jansen, and prof. dr. ir. Wendy Meulebroeck.

Practical details

The defense will take place at the Vrije Universiteit Brussel, Campus Etterbeek, in the Promotiezaal D.2.01 at 🗺️ 10:00 CEST.

The defense will be in English, and will be tailored to a general audience. The defense will be followed by a reception (probably at ‘t Complex) around early noon. If you cannot attend the defense and reception, I expect many people to stay at the Complex after 18:00. If you would like to physically attend the defense or the reception, please register online on https://forms.office.com/e/brf4FcD91w.

The event will additionally be live-streamed via Microsoft Teams. If you would like to receive the link to the live stream, either register online, or let me know via any other channel, e.g. by Signal.

Abstract

Since its inception, the internet has quickly become a public service utility. The combination of its commercial exploitation, and the rather intimate nature of how humans actively use the internet, gives rise to some paradoxical situations.

As a citizen of Belgium, I would probably not expect to give my name and phone number to a company in the United States to talk to my brother, 50 km up north. However, for over two billion people, this is their rather paradoxical reality: the company Meta, owning WhatsApp, collects and stores these data for their users. This cherry-picked scenario stands example for a wider trend in the industry.

Cryptographers have worked on several privacy-enhancing technologies (PETs). These PETs aim to minimize the amount of personal data to fulfill a service for users. Although these technologies exist on paper, several practical issues arise. These practicalities are the subject of this thesis.

One practical issue is the performance. PETs, especially those that run on end-user devices, should both be fast and require little bandwidth. We study how implementation details may lead to significant speedups or bandwidth savings. Specifically, we devise a zero-knowledge proof (ZKP) tailored to electronic road pricing (ERP). ERP is a privacy-sensitive topic, and our ERP system achieves some notable performance improvements over preexisting proposals.

A second practical issue is the challenging nature of implementing PETs. We present “Circuitree” and “Whisperfish”, to study how to bring PETs to an actual application. Circuitree is a high-level framework to tailor ZKPs to specific scenarios, using a bespoke logic programming language. The language is designed such that the resulting ZKP is highly efficient.

Whisperfish is effectively a reimplementation of the Signal instant messaging client, and allows to present in detail how Signal deploys their PETs to users. All ideas put forward in this thesis were evaluated by means of their implementation in the Rust programming language.

Bibliography

These publications have lead to the work in this thesis:

De Smet, R., Blancquaert, R., Godden, T., Steenhaut, K., & Braeken, A. (2024).Armed with Faster Crypto: Optimizing Elliptic Curve Cryptography for ARM Processors. Sensors, 24(3), Article 3.

De Smet, R., Steenhaut, K., & Braeken, A. (2023). Private Electronic Road Pricing using Bulletproofs with Vector Commitments. IEEE Transactions on Dependable and Secure Computing, 1–13.

Godden, T., De Smet, R., Debruyne, C., Vandervelden, T., Steenhaut, K., & Braeken, A. (2022). Circuitree: A Datalog Reasoner in Zero-Knowledge. IEEE Access, 10, 21384–21396.

Vandervelden, T., De Smet, R., Steenhaut, K., & Braeken, A. (2022). SHA3 and Keccak variants computation speeds on constrained devices. Future Generation Computer Systems, 128, 28–35.

I would like to thank my co-authors for their contributions to these articles. I would also like to thank Matti, direc85, for his contributions to Whisperfish.

I am the first one to admit that keeping a crazy number of chat applications and accounts around is horrible. I am on Matrix (@rubdos:rubdos.be; I even host my own server), Signal (I maintain Whisperfish, a third-party Signal client), IRC (Weechat), e-mail (with multiple different accounts), and probably a whole lot more that I don’t bother to check. Other people use iMessage, Instagram, Facebook, and even worse platforms for intimate conversation². Especially with the tendency nowadays to write every chat application in Electron (Signal Desktop and Element come to mind in my case), this problem hogs a lot of CPU and RAM that I would rather invest in something else.

This problem is what Beeper wants to solve: all your chats in one single interface. They are barely the first to attempt this. Pidgin, for example, is also a unified instant messaging interface. The Telepathy framework is another one. These are instant messaging (IM) clients with plugins for every protocol, and handle the integration locally on the device.

What makes Beeper unique, is the implementation of the unification. Essentially, Beeper is a “normal” Matrix client, and all other protocols are bridged into the Matrix server. This means that your Beeper account is accessible from all different kinds of devices, and all of these devices will have a unified view over your IM accounts. This is extremely convenient!

Beeper destroys privacy for non-Beeper users

Since Beeper implements the unification on the server-side, the properties of a chat session are reduced to the capabilities of the Matrix protocol, and the end-to-end encryption is terminated at the bridge side. This implies that Beeper effectively acts as a man-in-the-middle, breaking end-to-end encryption, putting user data of all their users in the same place. At least, this implies that your plain text messages exist in memory on the Beeper servers, including metadata and account and session keys. Additionally, Beeper has the goal of implementing messenger interoperability, which reduces properties of all protocols for all contact to the lowest-common-denominator in cases of mixed-protocol sessions.

Let’s consider the implications from the Signal point-of-view, since Signal is quite universally considered the state-of-the-art from a privacy perspective. For example, Signal does not know³ the members of groups, because of their recent-ish private group system (2019). Beeper, being a Matrix server, will need access to the decrypted group state, and hence the Beeper server will know the members of any group. Consider the implications of the above: being a passive member of a group with even a single Beeper user destroys group anonymity!

This is also true for existing groups. If you are part of a group on Signal, and one of the members decides to try Beeper with their existing Signal account, the Beeper bridge server will know about your group membership, without you ever consenting.

Lastly and relatedly, there are some security and practicality concerns, not necessarily relating to privacy. Services like Signal or WhatsApp might disagree, for various reasons, to allow connections from Beeper. They might change their mind over night, or you might bounce on the spam filter, or hit some rate limiter. There are a plethora of implicit security issues of sharing the same Beeper IP address when connecting to messaging services.

Self-hosting Beeper “solves” the problem

I discussed this issue with Eric, when I had the privilege of meeting him in Brussels in February. Largely, the issue boils down to your trust in the host of the Beeper bridges: if you trust the bridges, then it does not necessarily matter that it knows about group states, the contents of messages, or the contacts you are talking to.

Even when you trust Beeper’s servers, there are potential issues. You may have trusted their servers yesterday, but today they can get seized by a government, or Beeper might get breached. Or they might move their servers onto a malicious or curious cloud provider.

So, if you don’t trust the Beeper servers, they offer you the option to self-host. However, this only solves one half of the issue. Alice might trust their own server, but Bob is still forced to communicate with a bridge they don’t know about. Additionally, self-hosting always implies a maintenance burden, which might weaken the security of the communication. In my experience, self-hosting and federation is not a solution to a privacy problem, nor does it give back your autonomy. E-mail is a federated protocol and can be self-hosted. In practice, we are all unwillingly users of Google Mail and Outlook at the same time. Mastodon is a federated system, but in practice we all rely on mastodon.social. In extenso, Matrix is a federated system, but in practice we all rely on Matrix.org. You don’t get autonomy nor privacy if your contacts are on a server you don’t trust.

Don’t complain; suggest what’s better

Honestly, I don’t know. Fragmentation of communication is a real issue, and a difficult, maybe impossible one to solve. I am actively forcing all my personal communication on Signal, and my professional communication through email (Thunderbird) and Matrix (weechat-matrix). This is not a (long term) solution, because I’m putting trust in Signal LLC, where it might not be appropriate.

The emotional or interpersonal implications of “please kindly register on Signal because I’m not used by Facebook” can be quite drastic, and I realize it is not a procedure that most people can afford to follow.

Sadly, life is sometimes more complicated than a technological solution might make it seem like.

Acknowledgements

I would like to explicitly thank valldrac for his feedback on this post.

The automation was relatively simple:

- alias: When nobody is home, start Dobby
  description: ''
  trigger:
  - platform: state
    entity_id: group.family
    to: not_home
    for:
      minutes: 5
  - platform: time
    at:
    - '8:00:00'
    - '12:00:00'
    - '16:00:00'
    - '20:00:00'
  condition:
  - condition: state
    entity_id: group.family
    state: not_home
    for:
      minutes: 5
  - condition: time
    after: '7:00'
    before: '20:00'
  - condition: state
    entity_id: switch.dobby
    state: off
    for:
      hours: 11
  action:
  - service: switch.turn_on
    target:
      entity_id: switch.dobby
  - service: notify.notify
    data:
      title: Dobby
      message: Stof zuigen zal ik doen!
  mode: single

Basically, Dobby cleaned the appartement at most once a day, whenever nobody was there. This idea has a few drawbacks:

• During the weekends, I would often get to the shop for 10 minutes and return immediately. If I would leave again for a longer period the same day, Dobby would have only cleaned for five or ten minutes.
• Dobby would clean every day, even when on a vacation.
• Maybe I would like Dobby to clean during certain periods when I’m home, too. For example, Dobby could go around while I’m in the shower.

Simulating dust and batteries

At this point, it is clear that Dobby should become smarter. Remember, Dobby is an Eufy 11s, which has no connectivity whatsoever. This implies that Dobby is controlled 100% open-loop: Home Assistant can send a start command via IR, and a stop-and-go-home command, but I have no way of obtaining any information about Dobby’s state. At a certain point, I will probably slap an ESP32 with ESPHome on it to have some feedback about battery and cleaning, but currently, Dobby cannot talk to me.

In order to have an idea about the battery charge status, I opted to build a simulator for it. The dobby_charge_rate is a function of whether Dobby is home or cleaning, and the dobby_charge is the integral of that function. Note in the code below that I added a small random term for the integration to actually trigger. Suggestions for (ahum) cleaning that up are welcome.

template:
  - trigger:
      - platform: time_pattern
        minutes: "/2"
    sensor:
      - name: Dobby charge rate
        unique_id: dobby_charge_rate
        unit_of_measurement: "%/h"
        # Home: 25%/h
        # Running: 75%/h
        state: >-
          {% set dobby = is_state('switch.dobby', 'on') | int %}
          {% set dobby_not_full = states('sensor.dobby_battery_charge') == "unknown" or (states('sensor.dobby_battery_charge') | int <= 100) %}
          {% set dobby_not_empty = states('sensor.dobby_battery_charge') == "unknown" or (states('sensor.dobby_battery_charge') | int >= 0) %}
          {{ -75 * dobby * (dobby_not_empty | int) + 25 * (1 - dobby) * (dobby_not_full | int) + (range(-9, 10) | random)/100 }}

sensor:
  - platform: integration
    source: sensor.dobby_charge_rate
    unit_time: h
    name: Dobby battery charge
    unique_id: dobby_charge

Additionally, I made a dust_accumulation_rate and accumulated_dust, in the same fashion. This is based on the number of people that are present at home. The constants are based on the idea that Dobby should clean every four days in vacation mode, but again every day when I’m actually home for any significant time.

template:
  - trigger:
      - platform: time_pattern
        minutes: "/2"
    sensor:
      - name: Dust accumulation rate
        unique_id: dust_accumulation_rate
        unit_of_measurement: "%/h"
        # .5%/hour base rate = 50% every four days
        # 10 hours * one person = 90% dust
        # 1 hour * one dobby = -100% dust
        state: >-
          {% set dobby = is_state('switch.dobby', 'on') | int %}
          {% set not_max_dust = states('sensor.accumulated_dust') == "unknown" or (states('sensor.accumulated_dust') | int <= 100) %}
          {% set not_min_dust = states('sensor.accumulated_dust') == "unknown" or (states('sensor.accumulated_dust') | int >= 0) %}
          {{ (((states('zone.home') | int) * 9 + 0.5 * (1 - dobby)) * not_max_dust - (100 * dobby) * not_min_dust) + (range(-9, 10) | random)/100 }}

sensor:
  - platform: integration
    source: sensor.dust_accumulation_rate
    unit_time: h
    name: Accumulated dust
    unique_id: accumulated_dust

Based on these two properties, I changed the automation to trigger at 99% battery and 75% dust, still checking the presence status of inhabitants and guests.

Taking it a step further: shower detection

Now onto the most silly part: I would like Dobby to clean while I’m home alone and showering. During that time, Dobby would not bother anybody, and can freely roam about for about 15 minutes. This is especially useful if I don’t plan to be away for a long time, and I would have guests over the same day.

My first attempt at detecting shower presence was based on the bathroom humidity sensor. And so was my second and third attempt. I’m not sure which version this one is, but this is the last I tried:

sensor:
  - platform: statistics
    name: Bathroom Humidity Stats
    entity_id: sensor.xiaomith2_humidity
    state_characteristic: mean
    sampling_size: 40
    max_age:
      hours: 1

binary_sensor:
  - platform: template
    sensors:
      showering:
        value_template: "{{ states('sensor.xiaomith2_humidity') | int > states('sensor.bathroom_humidity_stats') | int + 5 and states('sensor.bathroom_humidity_stats') != 'unknown' }}"
        friendly_name: Showering
        device_class: occupancy

Basically: if the humidity is over 5% higher than the hourly mean, I consider the shower to be occupied.

This worked, more or less. Dobby would start cleaning by the time I got out of the shower, and then probably started and stopped a few times more while I was in the living room.

Finding those exact offsets that work is annoying and unpleasent, and this process finally got me to touch machine learning. Over the course of today’s afternoon, I wrote a little KNN inference system that talks to Home Assistant, and bases its features and samples of Home Assistant’s logbook. To be more precice: Hasli keeps track of a list of entities, and runs inference when the tracked entities change their state. Hasli will then update its own entities in Home Assistant, for further use in automations.

Currently, a configuration for Hasli looks like this:

binary:
- name: "showering"
  input_entities:
  - name: "bathroom humidity"
    entity_id: "sensor.xiaomith2_humidity"
  - name: "bathroom temperature"
    entity_id: "sensor.xiaomith2_temperature"
  - name: "bedroom humidity"
    entity_id: "sensor.slaapkamer_smart_air_humidity"
  - name: "bedroom temperature"
    entity_id: "sensor.slaapkamer_smart_air_temperature"
  - name: "people counter"
    entity_id: "zone.home"

  - name: "bedside presence 3"
    entity_id: binary_sensor.lidlpresence3_occupancy
  - name: "toilet presence"
    entity_id: binary_sensor.lidlpresence1_occupancy
  - name: "bedside presence 2"
    entity_id: binary_sensor.lidlpresence2_occupancy
  - name: "living humidity"
    entity_id: sensor.living_smart_air_humidity
  - name: "living temperature"
    entity_id: sensor.living_smart_air_temperature

Expanding Hasli

Currently, I have a local main.rs that is tailored towards my own “showering” inference. My hope is that Dobby will clean tomorrow morning while I’m in the shower. If that works, the goal is to make Hasli a proper daemon, and integrate it with the Home Assistant UI to allow everyone to design inference systems based on their sensors, and annotate the required data through the Home Assistant UI.

Any help to get data annotation integrated in Home Assistant would be very welcome. I envision a UI element where you can annotate a timeline of your own sensor data, not unlike the History Explorer Card by alexarch21.

Hasli should also expose a service to Home Assistent, such that data annotation can be automated!

The year is 2015. Mae’s message to Annie that she sent via Facebook Messenger is intercepted.

“I’m sick of this place,” reads Mark, her boss at Facebook. Mae and Annie were no longer allowed to communicate. Above all, Mark now knows that Mae doesn’t appreciate her job or Facebook’s values and standards very much.

In a parallel universe, we find ourselves in the year 2022. Facebook is now called Meta. In 2016, Meta added end-to-end encryption to Messenger in view of their Commitment to Privacy. With end-to-end encryption, the content of a message is only readable by the sender and the recipient, not anymore by the messaging service. However, the message that Mae just sent to Annie via Messenger is intercepted again. Mark knows that Mae and Annie are communicating; Mae is in trouble again.

Since Edward Snowden’s revelations in 2013, the use of end-to-end encryption has been gaining momentum, because it safeguards our privacy. Despite this, Mae is in trouble in both universes. End-to-end encryption is a good start, but unfortunately, it seems insufficient.

In fact, end-to-end encryption only protects against reading messages during their transit. End-to-end encryption is therefore a minimum requirement for a private messaging service, just like a letter in the mail is also in a sealed envelope, or just just like a message that has to remain within the four walls of your home also doesn’t get projected onto your outside walls.

Few messaging apps turn on that end-to-end encryption by default. Messenger has been planning to turn that option on by default for a while, but for now, the user has to do that manually, after a search in the options. Even with Telegram you have to manually create a “Secret Chat”, which additionally means you lose a lot of functionality. The best students in the class here are Signal and Threema, where end-to-end encryption is a requirement.

To understand why Mae is in trouble, despite end-to-end encryption, we need to look at metadata. Since 2016, Meta, then Facebook, has been making a statement: they are not (or no longer) interested in the content of conversations, because conversations are now optionally end-to-end encrypted. For them, the value of a messaging service lies is in knowing the dynamics of the social network: Who talks to whom? When? Where are the individuals when they send those messages? How frequently do they talk? Like no other, Meta knows the value of metadata; they changed their name for a reason. Meta knows all too well how to exploit and valorize this data, and mention this in their privacy policy:

[W]e combine this information across different devices you use. For example, we use information collected about your use of our Products on your phone to better personalize the content (including ads) or features you see when you use our Products on another device, such as your laptop or tablet, or to measure whether you took an action in response to an ad we showed you on your phone on a different device.

Sealed sending, Signal and zero-knowledge

Their polar opposite is called Signal. Signal rules the Metadata-free Empire. Had Mae used Signal, Mark would not have known that Mae and Annie were still talking. In fact, since 2018, Signal has been using “sealed sending”, where the sender of a message does not identify themselves when sending a message. “Sealed sending” is the technological equivalent of not listing the sender on the envelope. This sounds simple in theory, but in practice is quite complicated. If you allow anyone to reach a digital mailbox, then you’re also allowing them to receive unwanted messages and you potentially create an avalanche of spam.

Signal uses a zero-knowledge proof against this. Zero-knowledge proofs have recently become become very popular to solve privacy problems in crypto currencies such as Monero and ZCash. They allow you to convince someone of certain propositions, without disclosing any information in the process. In the case of crypto currencies, a zero-knowledge proof is used to ensure that an encrypted transaction is sound: the payer proves that their wallet does not go below zero because of that transaction, without disclosing how big the transaction or the contents of their wallet is. In Signal, you prove to the servers that the receiver allows messages to be received from you, without disclosing who you are.

The practical implications of zero-knowledge proofs reach a lot further than private transactions or sending sealed messages. For example, it is possible to design an alternative to the EU Digital COVID certificate (in Belgium, COVID-Safe Ticket, CST), which dynamically generates a QR-code depending on the local rules. This QR-code, unlike the original on the CST, does not contain any information about your vaccination or test status. It only contains a “proof” that indicates you comply with the rules. Besides, creating such a zero-knowledge CST is possible without any cooperation of the involved governments. This highlights the contrast between the CST and the Bluetooth based contact tracing. The contact tracing application was developed with the explicit intention of collecting and processing the least amount of information possible, but this effort has clearly not taken place during the development of the digital COVID certificate.

Private group messaging

At the end of 2019, Signal introduced another technological advancement, also made possible in part because of zero-knowledge proofs. For sending messages in groups, most messaging services make use of “server fan-out”: the sender sends the message once to the server, and the server takes care to distribute the message to the individual group members. For the server to execute that process correctly, it needs to know the structure of the group. This is not the case for Signal, nor for most other “client fan-out” systems. In these systems, the sender is responsible for sending the message to every group member individually. The disadvantage of this technique is the necessary bandwidth when sending a message.

Signal always used client fan-out because of its privacy advantage. The most important argument for server fan-out, apart from the higher bandwidth requirement, is keeping the group structure consistent. In a naive client fan-out system, the group structure is dictated by the last observed update, independent of who supplied that update. You could consider this total anarchy, but only until December 2019.

In order to keep the group structure consistent, Signal will now store the group structure on their server, in encrypted form. Note that Signal still does not see who are the members of the group, but it will act as an authority on the correct member list. A group administrator can now change the list, by adding or removing members. This poses a problem, however: the server needs to be sure that the list is modified by someone with permission, but the users of the group do not want to identify themselves when carrying out such a mutation. The privacy of the users is guaranteed through a zero-knowledge proof. The user proves that they are in the list of administrators, without disclosing their identity.

The net effect is an anonymous authentication system: users can prove their permission level, without disclosing who they really are, all while the servers are ensured that only privileged users can access sensitive data.

Other modern cryptographic techniques

Zero-knowledge proofs are only one of the many modern cryptographic advancements that are currently being studied. They are deployed more and more, because they achieve a concrete result, without overly compromising performance of the application. Other techniques are still young, and might have an unacceptable impact on performance. As an example, homomorphic encryption allows to make computations on encrypted data, allowing to later decrypt the computed result. A dream application is to apply artificial intelligence in large data centres, without them ever needing the actual privacy sensitive data. This is possible on paper, but still prohibitively expensive in terms of computational cost. For simpler computations, homomorphic encryption is already very practical, and is for instance used in the new Signal group system.

Another promising technique is “secure multy-party computation” (SMPC or simply MPC). MPC allows two or more parties to keep some values secret, while being able to compute a common result from those secret values. The classic example is the rich man game of computing who is the richest among a group of people, without disclosing each others net value. Practically, MPC has been used to make statistics and studies on databases that could not be joined because of their privacy sensitive contents.

With modern cryptography, many modern digital privacy issues can be tackled. Not only on messaging services, but also far outside that realm. Often, those problems are not visible at the surface.

While the focus of this article was on the privacy enhancing techniques used in Signal, Signal is of course not holy or unique in improving technology. Newcomers such as Session also innovate in techniques to hide metadata. For an outsider, it is sadly difficult to judge these alternatives. Signal is critiqued, rightfully so, on requiring a phone number during registration. This critique often shadows the more fundamental, less visible positive aspects of Signal’s engineering. It is however clear that Signal leads many innovations in terms of privacy-enhancing technology. End-to-end encryption is clearly only the start of innovation in privacy-enhancing technology, and the innovations mentioned in this article are most definitely not the end.

Acknowledgement

The writing of this article was supported by Cybersecurity Vlaanderen, under the Cybersecurity: Outreach & Training programme. This article goes together with the article “Cryptographic techniques for data minimisation” (Nl. “Cryptografische technieken voor dataminimalisatie”, currently untranslated), which dives deeper into the technical details of the cryptographic primitives mentioned in this article.