Word count: 2794. Estimated reading time: 14 minutes.
- Summary:
- The Google Pixel 9 Pro was compared to the Samsung Galaxy S10 in a previous post, with the latter being 50% more expensive after adjusting for inflation. The upgrade motivation was the fresh battery and changing software stack, as the MicroG-based stack had run its course.
Friday 17 October 2025: 13:29.
- Summary:
- The Google Pixel 9 Pro was compared to the Samsung Galaxy S10 in a previous post, with the latter being 50% more expensive after adjusting for inflation. The upgrade motivation was the fresh battery and changing software stack, as the MicroG-based stack had run its course.
A brief history of my phone software stacks
Like for most people, stock Android was the least worst solution, and up to 2015 or so there wasn’t any choice in any case. My last phone to run stock Android was my Nexus 6P, the last of the truly great bang for the buck phones from Google, and we ran those 2015-2018. Apart from the phone being too big, we were pleased with it.
I began running MicroG when I moved to my HTC 10 phone in 2018. I was lucky with the HTC 10 that there was available a regularly updated LineageOS with MicroG bundled in – this made updating it easy, at least so long as LineageOS was available for the HTC 10, which I remember at some point stopped because a maintainer disappeared. It then became real hassle to keep the HTC 10 somewhat current to security updates etc.
In 2020 I moved over to the Galaxy S10, and in a sense the Samsung was better for firmware updates because for a while it had much better consistency of OS updates given that HTC had left the mobile phone market by then. The problem now was the effort for me to redo debloating the stock Samsung OS and replacing Google Play Services with MicroG, and despite that an Android 12 firmware did ship for the S10, I never found the time to upgrade my phone.
The reality began to set in that if I wanted the thing which has access to all the money I have to be up to date with security fixes, I was going to need something which automatically keeps itself up to date. That meant returning to a stock OS, or at least something where somebody provides timely OTA updates.
The additional problems with MicroG
MicroG I think first launched around 2015, but was just about usable for things like banking apps when I started using it in 2018. Since then, it’s been sufficient more or less for everything I needed it for with the S10, albeit with caveats:
The N26 and Wise banking apps were happy with MicroG – probably because both are Germany focused and Germany has the biggest install base of MicroG of anywhere – but pretty much every other banking app wasn’t going to work e.g. forget about Revolut or anything similar.
You couldn’t use the latest versions of most Google apps e.g. Sheets, Maps, or Docs, because they will use features MicroG hasn’t reimplemented yet. If you stayed with versions a few years old you were fine, and only very occasionally did you get a Google app which really strongly insisted you had to upgrade.
MicroG had a very reasonable privacy preserving Location solution in the beginning which got nearly instant locations including indoors, but over time the third party location services it depended upon began to get decommissioned. MicroG didn’t seem to care much about creating a better solution, taking the view that waiting for GPS was fine. And I suppose it was, usually I’d wait a few minutes for a GPS lock and it wasn’t the end of the world. There were, however, a number of occasions where I wanted an indoor location and in that situation I was out of luck.
MicroG is mostly developed by a single person and when his attention is elsewhere, it doesn’t keep up. You find yourself installing some app and it’ll not work and you’ll find an open issue on the MicroG bug tracker and it’s simply a case of somebody finding the time to implement the missing functionality. Which could take months, years, or never.
Finally, MicroG preserves more privacy to a certain degree, but it isn’t immune to security bugs and other exploit vectors. As it grows in popularity, you begin to worry as more and more of your financial and secure life gets authenticated by your mobile device. In short, the use case is shifting, and he who takes control of your mobile device can nowadays generally fleece you of all your money. That didn’t use to be the case, but now it has become so, the threat surface has changed.
Improving security and privacy over MicroG
Around the same time as MicroG became available, there were tinfoil hat people obsessed with making forks of Android more secure than the standard one. At the time I assumed that it would be like with NetBSD – all the actually good ideas would get stolen by the mainstream project, and if they weren’t stolen, they were probably too tinfoil hatty in any case.
That seemed to be exactly the case for Android: these forks would demonstrate proof of concept, then Google would reimplement what seemed a reasonable selection of the best of those ideas. So far, so good. However, the hardware story had markedly changed recently in a way which hadn’t been the case until now …
In 2023, the Google Pixel 8 shipped the first phone with fully working whole system hardware memory tagging support, which was a developer mode opt-in setting. The first phone with hardware memory tagging always turned on is the iPhone 17, which shipped last month despite that the underlying technology – ARM MTE – shipped in 2019 (in fairness, Apple shipped kernels with MTE enabled years ago, but userland was harder due to how many apps would blow up if it were turned on). I too wanted a phone with hardware memory tagging always turned on, but Google is constrained severely by the Qualcomm Snapdragon chipsets not supporting MTE, and they’re the principle performance Android chipset used in all the big flagship devices. Assuming a seven year major update support period for those flagship devices, it could be as long as a decade still to go before Google can insist on always on hardware memory tagging in Android.
The reason why hardware memory tagging matters is because it substantially mitigates an entire class of security bug: lifetime issues. Most lower level software without a memory garbage collector has lifetime issues; most of those lifetime issues are benign, but some can be exploited by a malicious actor and a few are outright security holes. If you write your code in a language such as Rust, you will greatly reduce the occurrence of lifetime issues (though writing your code in Python, Java, .NET or most other languages is even better again), but there is a lot of poorly written C and C++ out there. Hardware memory tagging has the CPU check lifetime correctness for over ~90% (for ARM MTE) of all memory accesses for ALL code, which hugely reduces the viability of that attack vector.
GrapheneOS's config page for default exploit protection (each app can be given individual settings overrides too)
The other shift in hardware was that phones had become so well endowed in CPU, RAM and storage that it had become viable to put things into containers of isolated subsets of a full phone, much as one might do with a Docker container: it gets its own filesystem, own memory, own userspace, and is kept entirely apart from all other containers. This is expensive especially on storage, but when 512Gb of storage becomes affordable, the situation has changed. It’s now worth storing multiple copies of the userspace filesystem if that significantly improves privacy and security. If your CPU is now fast enough that you don’t need to use insecure techniques like Android Zygote to speed up app launch times and you can just launch apps from bootstrap, waiting one second for an app to launch becomes worth it if that significantly improves privacy and security. Ditto for using a memory allocator that is dog slow but secure – that’s a good tradeoff if your RAM and CPU are fast enough it won’t matter in practice.
You are probably getting the picture: mobile phones are growing up and becoming more like micro servers of secure isolated containers instead of a high end insecure embedded device. GrapheneOS is slower than stock, but it’s faster on the Pixel 9 than my Samsung S10 was. So I still get a faster phone than before, and you won’t notice all the inefficiency introduced by all the security measures.
Enter GrapheneOS …
To be honest, I hadn’t really paid much attention to GrapheneOS until recently, though I’ve been aware of it and its ancestors for maybe the past decade. Its user community definitely fell historically into the tinfoil hat category – well intentioned people, but maybe a little too paranoid.
Android had shipped multiple user profiles for a long time, since Android 11 released in 2020. They were originally intended so multiple people could log into a device and each get their own space. Each user profile was utterly isolated from others – internally each gets their own Linux user account, each gets its own filesystem, and when you switch between them only the base ‘Owner’ account keeps running. Switching away from any other user profile completely halts anything running under that user, unless you explicitly disable that happening.
In Android 15 which was released last year however, Google shipped something far more useful: a ‘private space’, which is a separate user profile with a UI and i/o bridge into a main user profile. In stock Android they didn’t really make that useful, but GrapheneOS very much took that new feature and made it into a killer feature reason for me to move to GrapheneOS.
What GrapheneOS enables is for you to install Google Play Services and all the associated gubbins into that ‘private space’. The private space is completely closed down whenever you lock the phone, and it is only opened when you explicitly open that private space. Therefore, Google Play Services et al only run when you explicitly opt into them running. Which might be once per day in my case, for a few minutes at a time, unless I’m using something like Google Maps for directions in which case I can’t prevent it tracking my location in any case.
The bridge between the main user profile and the private space is limited but sufficient: the clipboard works, and you can Share stuff between both profiles. It’s a little clunky when you’re interoperating across profiles, but entirely workable.
In your main profile, you do NOT install Google Play Services and instead install F-Droid. From F-Droid you can get all the basic apps I’ve ever needed for essential functionality e.g. calendar, security camera viewer, ntfy for push notifications, Gadgetbridge to interoperate with my watch, swipe keyboard, and so on.
In fact, apart from WhatsApp, I’ve been very pleasantly surprised at the quality and diversity of open source apps on F-Droid. I have high quality solutions for everything essential, none of which spy on me, track me, or try to exploit me. For everything else which I might only use occasionally, it is a quick button tap and fingerprint authentication to wake up the private space and everything available on a normal Android phone is there and working well, including banking apps such as Revolut which don’t appear to be able to detect that they are running inside a container.
Containerising the Google Play Services ecosystem so it only runs and therefore leaks and spies on you is a good step forwards, however they’ve also managed to retain full fat location services by proxying the Google services:
You can opt in, or out, of using Wifi and Bluetooth scans to pinpoint location. If you do use them, they’ll locate you within seconds even inside an airport without any GPS signal available. Very nice, and I found it a welcome return when I was travelling last month.
You don’t have to use GrapheneOS’s proxies if you don’t want to. You can in the configuration point them at alternatives instead. You can run your own proxies, or your own database services, or use Apple’s servers, or Nominatim’s. As far as I am aware, all the other free of cost services have been shut down so that’s a complete set. GrapheneOS does cache what it fetches locally far more aggressively than stock OS, so it might only fetch the database of GPS satellite locations once per week, as an example. This greatly reduces how much about your current location gets leaked, though obviously as soon as you fire up the Google Play Services ecosystem your exact location will get sent to Google.
Re: WhatsApp, as mentioned in previous posts Meta do supply an edition which doesn’t require Google Play Services. It does work okay, albeit it’ll chew through your battery unless you ‘optimise’ its background power consumption, which means it only gets run every hour or so if in the background. Which means messages will be delivered delayed, and anybody who tries to ring you via WhatsApp won’t get through until you wake the phone. There is one other bugbear: out of ALL the apps I have installed onto that phone – including ALL the ones from Google Play Store – the one, single, ALONE app which requires memory tagging disabled is WhatsApp. Otherwise the system detects lifetime incorrectness which kills the app, making it unusable.
This is very poor on the part of Meta, but of course they don’t care about security nor you. They only care about monetising you in ways which don’t generate legal liability for them.
If WhatsApp weren’t so prevalent in Europe, or if it had an alternative client ideally open source which was more secure, I would be happier. There is an open source solution which involves bridging WhatsApp running within a VM on your server into Matrix chat via https://matrix.org/docs/older/whatsapp-bridging-mautrix-whatsapp/, and then you actually use a Matrix client on your phone. And that appears to work well if you only care about text messaging, but obviously enough it won’t do video or voice calls which is half the point of WhatsApp.
For me for at least now, I’m happy enough with the current solution. WhatsApp is the weakest part of this story, but I think I can live with it. What I get from the new software stack is:
- Automatic, timely, OTA security fix pushes.
- A greatly more secure software stack than before.
- A more private software stack than before.
- No more incompatibility problems caused by MicroG.
The downsides:
The phone is more clunky to use than before, often requiring two fingerprint authentications and waiting for Google Play Services to launch. I only really care about this for taking photos with the Google Pixel camera app, which requires Google Play Services. GrapheneOS does come with a system camera app which is perfectly fine for taking pictures of many things, but if you want the Ultra HDR photos, you’ll currently need the Pixel camera app.
ntfy has to keep open a connection at all times, and that does drain the battery if not on Wifi because it prevents the LTE modem from going to sleep. I might experiment with UnifiedPush at some point, but it too will need to keep open a connection. Something has to keep open a connection if it’s not Google Play Services.
WhatsApp kinda sucks. I can’t leave it running in the background all the time like ntfy because it sucks down far too much power. So then I get an impoverished experience. And it’s also the only app which can’t have hardware memory tagging turned on. It’s clearly a buggy piece of crap. Shame on Meta!
What’s next?
With that entry above written, I have cleared my todo list of entries to write for this site. Much of the unusually large volume of text I’ve written on here these past few months were because of long standing todo items e.g. upgrade phone which were either going to be happening anyway around about now, or were only done because I finally had the free time to get them done.
It’ll be a return to normal infrequent posting to here after this. I have lots to be getting on with in open source and standards work, not least cranking out new revisions of WG14 papers and reference libraries for those papers. And that I expect will take up most of my free time from now on until Christmas.
| Go to previous entry | Go back to the archive index | Go back to the latest entries |