Privacy implications of containerized application runtimes

Key Takeaways from the Case Study

I established the baseline by monitoring network traffic on a factory-reset device for about 24 to 36 hours. I executed TCP/UDP port scans across the 1024 to 65535 range to map the default attack surface before deciding to strip the default provider's services entirely. This initial reconnaissance shaped the core strategy for building a privacy-hardened mobile environment.

• An AOSP base with Gapps removal reduces scanning exposure at the OS level.
• Tools like Yalp and F-Droid enable app access without Play Store dependencies.
• Paid providers like Posteo limit data practices compared to free services.

Challenge: Data Exposure in Standard Android Setups

Standard Google free Android relies heavily on Gapps for core functions. This architecture guarantees continuous data scanning occurs in free email and app ecosystems. To quantify this exposure, investigators isolated the device on a dedicated VLAN to capture idle telemetry. Activity data showed that containerized runtimes frequently bypassed local VPN routing rules.

Containerized runtimes on devices like the ZTE Z9 mini amplify tracking rather than restricting it. Idle telemetry captured over an around 45 to 60 minute window revealed payloads ranging from roughly 12 KB to 48 KB per transmission. Telemetry transmission rates varying significantly based on the specific baseband firmware version installed on the test device complicated the packet analysis.

Solution: Building a Controlled Runtime Environment

Replacing the default ecosystem requires a defined process. I utilized Mokee OS on an AOSP foundation with postmarketOS elements to establish a clean slate. Initially, the team attempted to use a micro-services spoofing framework to maintain compatibility, but discarded this approach due to the security risks of enabling signature spoofing system-wide.

System-wide signature spoofing frameworks introducing critical vulnerability vectors when improperly isolated.

Instead of relying on spoofing, I implemented a strict isolation protocol. You can reference the AOSP project documentation for the baseline partition structures required for this process.

1. Flash the Mokee OS base image to overwrite the factory firmware.
2. Perform system app conversion requiring 3 to 4 hours of manual partition resizing during the installation pass, targeting API levels 26 through 27.
3. Execute the /system/app mover utility to finalize system-level permissions.
4. Establish APK sourcing via Yalp and F-Droid as the primary store.

Results: Observed Privacy Outcomes in Testing

Post-modification network logs were aggregated and compared against the baseline captures to verify the cessation of unauthorized background data flows. The telemetry reduction was immediate and measurable. Background connections dropped from 42 concurrent streams to 3. Battery life extended by 14 to 18 hours during standby testing.

App functionality maintained through alternative download methods proved that usability does not have to be sacrificed for security. Paid provider choice eliminated email scanning and ensured that communication payloads remained encrypted at rest.

While these metrics reflect an optimal VLAN environment, they represent a verifiable reduction in the device's attack surface.

Scope and Limitations of the Testing Approach

Hardware selection was dictated by the availability of an easily unlockable bootloader and community-maintained kernel trees, restricting the scope to a single legacy handset. The hardware limited to the ZTE Z9 mini device means these specific partition resizing steps may not map directly to modern A/B partition layouts.

The timeframe based on older app versions and a narrow testing window introduces temporal constraints. The environment relied heavily on kernel version 3.10.x dependencies, with a focus on specific ROMs like Mokee OS.