The Quiet Defaults That Keep Security Debt Alive
OpenHarmony's remaining design risks are not all dramatic interfaces. This chapter follows the quieter choices that shape security over time: how processes are created, what survives uninstallation, who can read global logs, which legitimate features can carry data, and whether network protection is the default. The practical judgment is temporal as well as technical. A platform can make one release safer, leave another release exposed, or miss a parent system's later fix because security knowledge was not carried across the reimplementation process.
Security changes as state changes
A performance optimization can alter a security property without looking like a permission decision. Android's Zygote and OpenHarmony's appspawn create application processes from a shared parent. The arrangement reduces startup work and can make process creation efficient, but sharing a memory layout also reduces the randomness that Address Space Layout Randomization, or ASLR, is meant to provide. If many applications begin with predictable layouts, a defense that depends on per-process diversity becomes weaker.
The OpenHarmony result is partial rather than absolute. The paper reports that most application processes use the shared-parent model, while some critical processes are created separately. That separation reduces the exposure for the protected group but does not eliminate the design property for the rest of the system. The issue is not that process creation is inherently unsafe or that every process can immediately be compromised. The issue is that an optimization changes the initial condition shared by many security domains, creating cross-process predictability where independent randomness would have been preferable.
This is a different failure from an app reading another app's file. No ordinary permission needs to be missing. The contributing condition is a common creation path; the security consequence is that an attacker may gain a more predictable environment for later memory-based attacks. The operating system has traded some isolation margin for startup behavior. A design review must therefore ask what security diversity the optimization removes, which processes are exceptions, and whether the remaining protection is adequate for the threats the platform accepts.
A resource's lifetime creates another transition that can reopen authority. An application moves through installation, use, update, and uninstallation. The intuitive end state of uninstallation is that the application's private data and identity no longer belong to a future installation. Android research found cases in which residual data remained in system services such as the AccountManager. A newly installed app could reuse that residue to steal credentials, gain privileges, or access private data.
The failure is not simply “deletion was incomplete.” It is a mismatch between the identity lifecycle and the data lifecycle. The old app has ended, but a later app can encounter state that the system still treats as usable. If the platform reuses an identifier or trusts a leftover record, the boundary between two app lifetimes collapses. Android addressed the historical problem through proper cleanup and unique app identifiers. The design lesson is that uninstall is a security transition: the system must define what is destroyed, what may persist for legitimate reasons, and how any persistent state is prevented from being inherited by an unauthorized successor.