When Sensors, Bluetooth, and System Files Become Attack Surfaces

For OpenHarmony, the next security boundary is not another named permission but the fidelity of the state an application can observe or control. This chapter follows the study's sensor, microphone, Bluetooth, and system-file findings to explain why sampling rate, consent transitions, and global observability are security properties. The reader should come away able to separate the visible feature from the underlying capability: a motion sensor can become an inference instrument, a pairing operation can become an integrity decision, and a file that looks like diagnostics can become a second permission model.

Fidelity turns measurements into inference

A permission review often asks whether an app can access a sensor. That is necessary, but it is not sufficient. The security impact also depends on how much information the sensor exposes, how often it can be sampled, and whether the operating system limits what can be reconstructed from the measurements. A low-resolution signal may support an ordinary feature. A high-frequency signal can reveal behavior that the user never intended to share.

The Android research collected by the study demonstrates this difference. Accelerometer and gyroscope measurements sampled at high rates were used in prior work to infer four-digit PINs, capture low-frequency components of speech, observe keyboard input through vibration, and infer driving routes without direct access to GPS, Wi-Fi, or cellular location. These are side-channel attacks: the app does not ask for the secret as a named object. It measures a physical effect correlated with the secret and reconstructs information from that signal.

OpenHarmony exposes the corresponding motion-sensor APIs without imposing a comparable rate limit. The paper reports that an app can set the sampling rate arbitrarily high for accelerometer, gyroscope, and orientation data. That design choice leaves the important variable—measurement fidelity—under the app's control. A permission that says “this app may use the motion sensor” does not answer whether it may collect enough observations to infer a PIN or a route. The sampling policy is part of the access policy.

This is why Android's mitigation is instructive. Android 12 limits how often an app can obtain motion data through a direct sensor channel and requires a special permission for higher-rate access. The specific implementation differs from anything OpenHarmony might choose, but the design lesson is general: when data becomes more revealing as fidelity rises, the platform must mediate fidelity rather than protect only the existence of the interface.

The microphone case exposes a related gap between notice and prevention. OpenHarmony displays a privacy indicator when an app accesses the microphone, which appears to give the user awareness. The paper reports, however, that the indicator is difficult to notice against the default home-screen background and does not appear on the lock screen even when an app is actively using the microphone. More importantly, an app holding the MICROPHONE permission can access the microphone in the background and record without further user interaction.

The symptom is therefore not simply “the indicator is hard to see.” The contributing conditions are background access, a high-fidelity input, and a weak observation mechanism.