Call for Transparency - Critical Security and Bug Tracker

[han]

Dear Mudita Kompakt Team @urszula @Michal_Kicinski @aleksander,

NA devices were delivered last week, placing all users within the 14-day return window. Some critical questions have not been answered.

Kompakt Operating System Security - AOSP 12 No Longer Supported

We need a definitive yes or no answer: Will the AOSP version be upgraded to Android 13 or 14 to enable monthly security patches?

If no, will security patches be backported to the AOSP 12 in a transparent and timely manner?

If both answers are no, this creates serious security implications that need to be addressed. Users have not been warned about the severe security risks of using an unpatched device.

Many users have already sideloaded sensitive apps like Signal and financial apps without understanding these risks.

While sideloaded apps are “officially unsupported”, Bluetooth, WiFi, SMS, and other core system components (WebView browser) present equally serious attack vectors on unpatched devices.

At minimum, security patches for these domains need to be backported.

Will the Mudita OS development team commit to a public bug tracker?

This forum is not a substitute for a bug tracker. Users should not be burdened with hunting for acknowledgment of reported issues.

Creating a public bug tracker will:

• Eliminate duplicate bug reports across multiple forum threads
• Highlight prioritized bugs without requiring commitment to timelines
• Provide users a straightforward overview of platform status

Without clear answers to the above questions, users cannot make informed decisions about keeping their devices. I hope to hear back from the team soon.

Thank you.

[urszula]

@han Thank you for posting this. I have asked our team to chime in here & help out with some answers. I think perhaps @BartekFilipek can help as well once he gets more info.

[michalstasiuk]

Hi Han, let me answer that and start with an overview of our approach to Mudita OS K security.

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.

Please let us know whether this explanation is sufficient and what you think of this approach to communication with users.

In terms of a public board, our resources at this point do not allow us to maintain and moderate a public tracker. There are also privacy and security risks involved if clients’ errors with their logs, crash dumps, and use-case context were publicly available. What we’ll focus on instead is delivering the benefits of a public tracker you’ve mentioned in our current communication channels:

• Identify duplicate reports and link them
• Communicate the priority we’re putting on a particular issue
• Communicate our roadmap plans

We have gathered enough feedback, and in the next several days we plan to communicate our roadmap. I hope there will be more clarity on what we plan to do. Our roadmap announcements will focus more on new features than on bugs, but fixing bugs, especially security issues is and will be a higher-priority task for us.

Thank you for being in dialogue with us. Your questions are great feedback about what is important to our users. I look forward to hearing your thoughts on these answers. If the 14-day return window is close to expiring and any of your key questions remain unresolved, feel free to contact the support team. We’ll do our best to answer your questions in time, or, if we need more time, we’ll extend the period. This, of course, applies to all clients.

[paxristi]

“Android security update” now shows September 16, 2025.

[gezimos]

@paxristi

“Android security update” now shows September 16, 2025.

If you read Michal post above, they explain how these are their own patches. So in terms of reference September 16, 2025 doesn’t mean much and it’s not related to the security updates that Google will send to a Pixel device or to other big brands that include Google play services.

Not sure how reliable snoopsnitch is for MTK devices, especially since mine is not rooted. But it can’t detect the standard patches above 2023-04.

That said,. everybody should follow Mudita’s advice and don’t use banking/financial apps on the device. Don’t download apks from sketchy sites, stick to original sources like AuroraStore (which is a front-end alternative for googleplay). ApkPure is also good, a lot of other sites are hit or miss.

F-droid is a good alternative for open source apps. Github is good too, but I’ll only recommend it for apps that don’t require u entering any login details, unless it’s from a reputable developer.

[bone_naga]

So you’re saying you only worry about vulnerabilities that apply to the MK. I’m having a hard time imagining too many vulnerabilities that wouldn’t apply, unless they were for something like Google Play Services.

My biggest concern is whether your team will only consider only the stock MK or if you will assess vulnerabilities knowing that many users have sideloaded apps. If you decide to discount web browsers as an attack vector, for example, I would consider that a huge mistake since plenty of users have sideloaded a web browser.

[paxristi]

@gezimos According to Snoopsnitch, the patch detector works on any phone (otherwise the app only works on Qualcomm devices). However, seeing as how it hasn’t been updated since 2023, I’m not sure if it is capable of detecting patches released since then.

[paxristi]

@michalstasiuk and @urszula I don’t think I’m asking for anything new, since we’ve been told security updates would occur. However, those have not been communicated in the systum update release notes as was mentioned above. Is it possible we can get any more transparency on what security updates have occured? I don’t think anyone needs exact patch numbers, but it seems the “Android security update” date might be misleading if security updates weren’t mentioned in the update release notes.

Attached is a screenshot from Snoopsnitch. As mentioned by @gezimos above, it indicates that patches from 2022 and 2023 are missing (it is unclear to me if the app is capable of showing patches released since 2023).

[urszula]

@paxristi

However, those have not been communicated in the system update release notes

@paxristi I’ve asked our team about some clarification on this topic. I will come back with info when they respond.

[vinylbook]

Any news here? My 14-day period is about to expire and i would love to keep the Kompakt. However, this depends on the perspective on security that Mudita presents…

[urszula]

@vinylbook I will follow up with the team. I have not received an update yet.