I have bought a Mudita Kompakt that is unfortunately stuck on AOSP 12 and no longer getting security patches.
A big selling point of this device for me was being able to sideload media apps like Apple Music, Pocket Casts, Libby, RSS reader etc.
More sensitive apps that I’ve sideloaded are Signal, Proton Mail, and Proton Drive.
Given the wide variety of attack vectors that can exploit unpatched AOSP, I’m concerned that being logged into these critical accounts is a big risk.
My threat model is simply to protect these accounts. I already use security keys as a second factor whenever possible.
I’m most worried about Elevation of Privilege attacks.
I’m curious to hear what everyone thinks about using an end of life version of Android. Is it fundamentally incompatible with account security? Are there extra hardening steps I can take?
The device settings confirm it’s on AOSP 12. I’ve reached out to their support team asking if the device will be upgraded to 13 or 14, but haven’t heard back.
I haven’t gotten any updates that mention backporting security patches.
I’m within the 14 day return window, so if I don’t hear back I’ll return it.
Based off your replies, I’m assuming you think using unpatched Android would comprise my threat model? I was hoping there was a way I could harden the device.
IMO you would need to be very mindful of the apps you install, sites you visit, and networks you connect to, be extremely wary about opening any document, links, sent from anyone etc.
It is definitely not end of the world, unless you are either prone to targeted attacks, or you have poor OPSEC. Well, you always need to have good OPSEC to stay safe, just with an old device, it is even more crucial.
p.s. I still keep an phone that runs Android 10, solely for Google Pay Wallet.
You should be able to check it yourself, maybe search it on internet. Might need you to enable dev settings.
Hardening is great, but it isn’t a match for an insecure system.It’s a bit like putting a super strong lock on a tent…
Look, I am usually not that strict on security like others here, but the monthly security patches are a must if you want a safe device.
Maybe, just maybe it is suppported by LineageOS. If it is, then this would be better. But idk if this fit with the distractionless mindset of the phone.
Android 12 is end of life. I highly advise you to return it since you can do that. End of life software is highly insecure and also lacks privacy features that current Android has.
that thing isn’t even cheap, a brand new Pixel 9a (supported until April 2032) is only $10 more.
ASB patches cannot be fully backported to EOL branches and only the latest branch gets PSB patches. so even if they claim to, it will be either impartial or a lie.
From Braving, there is a phone called the minimal phone that is currently on Android 14, and they pledge 5 years of software update. This is a new company.
this is the response I got, after my request was escalated to a senior manager.
We started with AOSP 12 as a baseline. On top of that, we added changes specific to the chipset we use. This system was then modified by us extensively. We didn’t create a launcher that covers AOSP, but developed both applications as well as the low levels of the OS, including drivers. This allowed us for example to implement Offline+, which Android does not natively support. For that reason, I think it is fair to say we started with AOSP 12, but it is not AOSP anymore. It is a separate entity at this point. So we’re not planning to upgrade it to AOSP 13 or 14, but rather to Mudita OS K 2.0, 3.0, and so on.
The list of attack vectors is different for our OS than for the baseline AOSP because of a different set of functions. For the above reasons, patching our OS with AOSP patches is not a feasible approach. Most of the code would not be applicable. Instead, we conduct our own patching process. We analyze security fixes that are released to AOSP, not only 12 but any newer version, case by case, analyse whether the vulnerability applies to our device, and fix it based on the released patch code or from scratch. This process will be done continuously. In the system-update release notes, we’ll include information on any security fixes we implement.
@SkewedZeppelin can you elaborate on what you mentioned about ASB patches unable to be backported? That seems to be the strategy that this company is taking.
I would love to respond with a source/citation. Thanks for your help.
I can’t really weigh in on whether they are adequately securing against discovered Android vulnerabilities with this approach (although it’s doubtful), but something I will point out is:
Even if they are patching all applicable AOSP security flaws as needed, the changes to AOSP that they made (“developed both applications as well as the low levels of the OS, including drivers”) are likely not being watched/audited by as many people as AOSP itself for obvious reasons, so it is very possible they are introducing entirely new vulnerabilities in their “Mudita OS” that will go unnoticed.
Interesting, it might be able to fool someone if they rephrase it to “analyse whether the patches has known issues that causes serious issues to our device, before implementing them”.
If it won’t break their device / services, there is no reasons not to include the patches, even if the patches would, they just implement workarounds and get it properly fixed on next release.
