Martin – Page 2 – WirelessMoves

From Signal to Molly-FOSS and Unified Push

As you might know, I’m using the ‘Conversation’ XMPP based messenger app on Android and my Linux notebook for text, audio and video communication with friends and family. A federated self-hosted XMPP server keeps me independent from- and interconnected with others at the same time. And then there are friends and associates in a somewhat wider circle for whom it is not very appealing to use yet another messenger. Perhaps as unappealing as it is for me to use Whatsapp. But perhaps there is a middle ground?

Keep Alive Timing of Google’s Firebase Cloud Messaging

In the previous post I had a look at the background keep-alive data traffic of messaging apps on my GrapheneOS device that do not use the Google Firebase Cloud Messaging (FCM) service for push notification. I’ve optimized my apps and servers to have keep alive timers of 5 to 6 minutes, which ensures that even aggressive NAT routers in the path do not kill the connections. So how do these values compare to Google FCM?

Background Traffic of Android Apps – An Update

It’s been 5 years since I’ve had a look at how often the apps I use on my smartphone send or receive data in the background. Keeping the amount of background traffic to a minimum is important to reduce power consumption while the phone is not actively used. Google and Apple have recognized this and are offering a single channel to each device through which notifications can be sent. While the approach is understandable, there are people like me who are not very fond of having notifications run through a single centralized entity. On Android, fortunately, apps can keep their own decentralized notification channels open in the background. Some of those apps and servers are better than others when it comes to minimize traffic and thus to reduce battery consumption. When I recently switched to GrapheneOS, it was time again to have a closer look at background data exchanges and to see if there is anything I can optimize. And here is the result:

WebRTC Video Bandwidth Requirements

In a previous post I’ve been looking at the network behavior of voice calls over WebRTC on Android. In that graph, one can see that the bandwidth, independent of Wi-Fi (over DSL) or cellular is around 80 kbit/s in each direction. During the Conversations XMPP app call, we then switched from voice-only to voice+video. Needless to say that bandwidth requirements then change significantly.

From Firefox to Fennec to Vanadium?

I think I’ve been using the ‘original’ Firefox web browser since 2004 on my notebook and also on Android from the day it was released. Over the years, there has been criticism around anti-privacy features that came and went, most of them probably well founded. Nevertheless, I stuck to Firefox on my smartphone until recently but decided to switch after seeing just how often Firefox ‘calls home’.

Wireguard on Android – A Bit of a Mixed Bag

Earlier this year, I had (another) look at Wireguard. Beginning with Ubuntu 24.04, the client is now fully integrated in the network GUI and a Docker based server installation has become available as well. One thing I didn’t have time for at the time was to look at Wireguard on Android. So let’s have a go now.

WebRTC Handover between Wi-Fi and Cellular

I use the Conversations XMPP messenger a lot on my Android phone, not only for text, image and video chat messages, but also for voice and video calling. It’s a joy to use! While in the early days, voice calls dropped when moving between the cellular network and Wi-Fi, the process has become pretty much seamless in the meantime. When I recently jumped between Wi-Fi and cellular a number of times on purpose, I was surprised that I couldn’t hear the switch between the networks in the audio channel at all. So perhaps the call didn’t switch and staid on cellular? I decided to have a closer look.

F-Droid and Aurora Now Auto-Update Apps

A quick note today about something that probably everyone but me knows already: When I last installed the F-Droid and Aurora App Store front-ends, the one thing both of them could not do were auto-updating installed apps. Not a big problem for me because I don’t mind being in control when a device updates apps. But for those in the family that would rather like things to be automated, this was not so nice. Looks like since Android 12, alternative app stores can now also automatically update apps. When I installed F-Droid and Aurora, the option did not exist, but an update down the road introduced the feature, disabled by default. Good default, I commend them for it. But actually, I have to admit that auto-update is something I would like as well, so I’ve switched it on for my device as well now. Many thanks, cool stuff!

GrapheneOS – Part 5 – App Separation and Termination in the Private Space

In part 3 of this series, I’ve taken a look at how the Google Play Services (app) and closed source commercial apps from the Google Play store can be separated into Android’s private space to deny them access to any data on the device. I really like this separation, and having used it for some weeks now, I have noticed a number of additional nifty features: App termination and network separation.

GrapheneOS – Part 4 – Wi-Fi Privacy

Today, I’d like to share a few notes about GrapheneOS and Wi-Fi privacy. When connecting to a new Wi-Fi network for the first time, ‘normal’ Android devices I use generate a per-Wi-Fi network randomized MAC layer 2 address and then keep using this MAC address for this network. While this prevents tracking a device between different networks, an individual network can still track a device forever. Not ideal.

GrapheneOS fortunately goes a different way! Instead of using a per-network MAC address, the default is to use per-connection randomized MAC address. This removes traceability over time even in a single network.