Martin – WirelessMoves

Being Mobile Device Overlord For a Day

If you are working for a company that employs more than a handful of people and use a company smartphone or tablet, chances are that the device is owned and ‘managed’ by the company. ‘Managed’ basically means that the company uses a remote Mobile Device Management (MDM) solution that hooks into a management API of the smartphone. The same applies to notebooks as well, but I want to focus on mobile devices in this post. While the concept was clear to me in theory, the practical aspects of this have always been a bit vague, as I’m not working in an IT department that ‘manages’ remote devices. Recently, however, I came across an MDM solution that offers a free trial account. So I jumped at the chance and became a ‘Device Overlord’ for a day to see just how much can be controlled remotely and how the device enrollment process works.

UnifiedPush – Part 4 – Power Efficiency

Finally in this series, I’d like to say a few words about UnifiedPush (UP) and power efficiency. UP is a decentralized system and can use different transport options. Have a look at previous posts on this topic for details. And surprisingly, some transport options are much better than other when it comes to sending keep alive packets to ensure that Network Address Translations (NAT) gateways do not forget the connection and inadvertently block incoming notifications.

UnifiedPush – Part 3 – Molly-FOSS and the Gateway to Signal

In the previous post, I’ve had a look at how to set up UnifiedPush (UP) on Android. The easiest option: Download the SunUp app, switch-off battery optimization so it can run in the background and you are done. Easy! At the moment, I’m using UP on GrapheneOS for two applications: Tusky, a Mastodon reader and Molly-FOSS, a Signal messenger fork which replaces the Google cloud notification service with UnifiedPush. Molly-FOSS can run on its own without UP, but then uses Signal’s fallback proprietary web socket push system that sends keep-alive packets several times a minute. This is very power inefficient and I wouldn’t want to use this method in practice. Setting up UP in Molly-FOSS is not difficult, but it was a bit confusing for me at first, because it requires an additional setup step which is not part of the normal UP configuration procedure. Let me explain:

UnifiedPush – Part 2 – An Easy Practical Example

In the previous post, I’ve had a look at UnifiedPush (UP) and how it works in theory to deliver push notifications from servers to apps on mobile devices. UnifiedPush has been designed to be de-centralized, and if one does not want to self-host a UP server, there are a number of different transport options and UP server providers available for use. I use two apps on my Android device with UnifiedPush, Tusky, a Mastodon feed reader and Molly-FOSS, a de-googled Signal messenger fork. While I was tempted to go straight for a description of how Molly-FOSS uses UP, I’ve decided to defer that into a separate post and rather go for a description of how Tusky uses UP, as the setup for this use case is simpler. Let’s go from simple to more complicated!

UnifiedPush – Part 1 – Why and How

In a previous post I’ve had a look at how I can use the Signal Messenger app on my GrapheneOS Android phone without Google’s push notification service (FCM) for incoming messages. There are a number of options and I settled for the combination of the Molly-FOSS fork of the Signal App and UnifiedPush (UP) for notification. It works like a charm so I had a more detailed look at how UnifiedPush actually works and which options there are. It was a bit challenging to get my head around the online documentation so I thought I’d write a couple of blog entries to see if I can explain the concept in simpler terms. Not only for you, but also for me, because I’m sure the topic will come up again in the future.

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’.