The Reimplementation Test: Carry Forward Lessons, Not Liabilities

The OpenHarmony case answers the question that opened this series: rewriting an operating system can remove source-code lineage without removing design lineage. The final judgment is not that OpenHarmony is secretly Android, nor that every Android weakness must appear in it. It is that interfaces, defaults, privilege boundaries, shared state, and lifecycles can preserve the same security assumptions across different implementations. A reader evaluating a new operating system should therefore ask which assumptions were carried forward, how they were tested, and where the evidence stops.

Security is a property of the whole design

The study becomes clearest when its findings are viewed as one system rather than as 24 isolated vulnerabilities. At the first layer is authority: who may invoke an operation, who may receive the request, and whose origin has been verified. OpenHarmony's documented privilege levels, permissions, ACLs, and user-consent rules express that intended boundary. The findings involving statistics, identifiers, DataAbility, Common Events, and implicit Wants show why the boundary must cover every route to the same state. A permission on one API has limited value if a system file exposes the identifier, an event broadcasts the protected fact, a data component ignores its read or write rule, or an unverified component can receive the action.

At the second layer is fidelity. A sensor, microphone, Bluetooth relationship, or system file does not have one fixed security meaning. The amount of information exposed, the rate at which it can be sampled, and the state transitions an app may trigger determine what an attacker can infer or control. OpenHarmony's reported high-rate motion access, background microphone recording, consent-free Bluetooth operations, and readable global measurements make this concrete. The security property lies in the capability's effective precision and control, not just in whether the platform gives it a familiar API name.

At the third layer is state over time. Process creation can make memory layouts predictable. Uninstallation can leave data available to a later application. Global logs can move sensitive information from a system store into a privileged app's sandbox. A legitimate app invocation or shared media file can become a covert channel. These are lifecycle failures because the security boundary changes as state is created, shared, persisted, copied, or destroyed. A review that checks only the first API call cannot see the later transition where authority or information becomes reusable.

At the fourth layer are defaults and composition. Certificate validation can be technically available yet difficult to apply consistently if it must be configured for each request. Cleartext HTTP can remain the path of least resistance when encryption is not enforced by default. A system can offer flexible inter-app composition while failing to bind a sensitive action to a verified endpoint. These choices move security work onto application developers and users. They may be made for compatibility or convenience, but the platform still determines the failure mode that occurs when nobody adds an extra safeguard.

The layers interact. An implicit Want is an endpoint problem, but the danger increases when the request carries sensitive state and the receiver can trigger another transition. A system file is an observability problem, but its impact depends on the privilege boundary of the API whose information it reveals. A process-creation optimization is a memory-isolation problem, but it becomes a system risk only when an attacker can use predictability across process domains. The design-level view is valuable because it preserves these relationships instead of treating each symptom as an unrelated bug.