| Making it hard to siphon personal data doesn't require manufacturers to prevent side-loading of apps. A much better solution would be to create better permissions models (capability-based) for mobile devices. As an example, one could build a granular permissions model which forced apps to be composed of multiple modules. Each module would have their own sets of mutually exclusive permissions. An app that allowed the user to apply filters to photos/videos could be composed of two modules: One which had read and create permissions for files the photo library along with read-only access to an app-local storage directory A module which had the network communications permissions (exclusively by OS APIs that performed all the crypto[1]) and write-only access to the app-local storage directory (for downloading new filters) By forcing apps to be broken up into separate modules and ensuring that all network communication is done from a carefully constrained sandbox (which can only read/transmit a tiny subset of data generated/available to the app), users could see exactly what the app transmitted without having to install their own self-signed root certificate (and maybe also jailbreak their devices if the app that they're interested in is using certificate pinning or ignoring the OS certificates). The best way to technically combat a lot of this sort of data-slurping nonsense would be to force apps to have near[1] total transparency for all network communication for any user that wanted to see. [1] The OS crypto API would have to provide a few authentication routines which blanked passwords, secret keys, etc. after use to prevent the unintentional leaking of secrets. Those APIs would obviously have to be designed to be resistant to malicious use by Facebook, etc. |