WirelessMoves – My Thoughts on the Evolution of Wireless, FOSS and the Past, Present and Future of Computing

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.

GrapheneOS – Part 3 – Separation Options for Google Play Stuff

My main reason for turning to an alternative Android flavor is privacy. GrapheneOS takes this to the next level and by default doesn’t talk to any Google servers at all. Even things like the connectivity check web request when connecting to a new network or requesting ephemeris information for fast GPS startup go to GrapheneOS servers rather than to Google. Like on LineageOS, which I have used so far, the downside of not having any Google software on the device is that particularly banking apps do not run. A small price to pay for privacy, but GrapheneOS offers a way out of this without compromising privacy: Running Google Services, particularly Google Play in a sandbox.

GrapheneOS – Part 2 – Google Play Services

Good, so there’s GrapheneOS on my Pixel 8 now. Like on my previous Pixel 6 with LineageOS, I don’t need the privacy challenging Google Play Services for my core apps, as they are all open source and from the F-Droid store. That being said, there is one type of proprietary apps, however, which I would really like to have on my main phone and which require these services: Banking apps.

There are various ways to get Google Play Services on custom Android Open Source ROMs, and GrapheneOS uses a particularly nifty version: The original Google Play Services and the original Google Play app store can be put into sandboxes, and GrapheneOS then puts an insulation layer around the play services to shield the operating system from it. Sounds nice!

I have to admit that I only had a very vague idea so far what the Google Play Services actually are and how they are embedded in Android. At this point, I felt that I needed to understand this a bit better before allowing it on my main phone. So after reading the GrapheneOS details on the topic and the Wikipedia entry on Google Play Services, I think I understand this much better now. So here’s my take on it:

GrapheneOS – Part 1 – Making the Jump

12 years ago I moved from Symbian (does anyone remember?) to Android with a sad heart and great unhappiness about the amount of private data that would be siphoned out of the device. Fortunately there was CyanogenMod, an Android Open Source Platform (AOSP) fork that removed pretty much all privacy invading extras from Android. Happiness restored! Over the years, Cyanogen morphed into LineageOS, and I’ve been using this flavor of privacy friendly Android until today. While the future for free Android forks has looked a bit dire in some years, things are much healthier these days and there are several interesting options now apart from LineageOS which do not require living on the bleeding edge. So when it came to changing smartphones once again, I decided to try out something different: GrapheneOS.

OpenStreetMap – RSS Change Notification

A quick post today on a cool service for OpenStreetMap I’ve recently discovered: For many years, I’ve been using Osmand and other tools on my smartphone not only for maps, local search and navigation, but also to contribute changes, i.e. new shops, opening hours, etc. etc. Recently, I wondered if I could see who else has recently updated the map in my region. After a bit of searching, I found WHODIDIT, that shows recent changes of Openstreemap on a map. Even better: One can get updates via RSS for a region by drawing a rectangle on the map, which generates an RSS feed. Works great and gives me a much better understanding, how many people and how often changes are made where I live.

Growing Pains With Eduroam – Going Manual

I’m a great fan of the idea of Eduroam Wi-Fi and I’ve been using it and helping others to use it for many years. The idea is simple: You have an Eduroam account at your home university which allows you to not only use the Eduroam Wi-Fi locally for ‘Internet’ access, but also in other places that offer Eduroam. Authentication is then provided by the authentication server of your home institution. Distributed authentication, world wide use, very nice! In Europe, pretty much every university offers Eduroam and in the Nordic countries you even get connectivity in train stations, airports, hospitals and other public places. This is all very nice if it weren’t for two little problems: Port blocking and ‘low signals spilling into the streets’.

Nextcloud Refresh – Part 5 – Differential Restore

So here we are, only one thing is missing for me to complete my switch from a self maintained Nextcloud instance to Nextcloud AIO: Differential restore of data to a standby system. A quick recap: The default restore doesn’t work for me, as it performs a full restore of all data which takes too long. What I need is a differential restore process that only transfers files that have changed from the remote backup server to my standby Nextcloud instance and deletes the files that no longer exist. While there is no official process to do this, it’s easier than I first thought.

Nextcloud Refresh – Part 4 – Recovery Testing

In the previous post on the topic, I promised to follow up with a post on how to do a differential Nextcloud AIO restore. My application: Keep a cold standby Nextcloud AIO instance up to date so I can quickly activate it, should my main server fail. However, doing a periodic full restore to a backup instance in my case is just not practical due to the sheer amount of data that needs to be moved. Hence, a differential restore is required.

Before I go to the differential restore, I would like to make a short detour, as I do not only need a way to run a differential restore, but also a way to test if the backup server would actually work when the containers are started. The one thing I need for this is that I can dynamically change the domain name at which the backup server can be reached. While the instance is only the backup server, I don’t want to reach it at, let’s say, cloud.martin.com but rather at cloud-test.martin.com. Turns out this can be configured quite easily.

Nextcloud Refresh – Part 3 – Full Restore

In the previous post on the topic, I’ve had a look at how to create manual or automated local and remote backups of a Nextcloud AIO instance. Also, I mentioned briefly that restoring an instance to a previous state works without a fuzz. In this post, I’ll have a closer look, as there is one significant shortcoming of the default procedure: It’s all or nothing!

Nextcloud Refresh – Part 2 – Backup

OK, so there we go, I now have a ‘refreshed’ Nextcloud installation. Everything runs in (hopefully) well maintained Docker containers. No longer do I have to deal with web server configuration, php variables, certificate renewals and sudden incompatibilities when upgrading the underlying operation system. Next step: Let’s get the backup / restore process working for this setup. In this post, I’ll have a look at how to create a local backup to get started with, and a remote backup, which is what I need for safety and redundancy reasons. Turns out that the difference between the two types of backups is small.