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.