If you spend enough time with a system like Qubes, you realize there's no need for a tradeoff between freedom/experimentation/learning and security — everything is contextual. There is a natural lifecycle where tasks move from experimental to predictable.

In the experimental phase, you want security to create strong isolation between the open area and the rest of the world, to maximize freedom within the protected area. As experimental code matures and wants to interact with external systems, and (possibly) the entire world via public internet, we can whitelist expected behavior and impose contextual limits, to regulate transitions across the biological system/world membrane.

One question is, who determines policy for non-experimental systems that interact with the world? Centralized app-stores are a blunt policy instrument, not to mention their propensity for business conflicts of interest. On the one hand, we want to encourage reuse of known-good policy defaults, which have been proven by other users against known threats. On the other hand, the long tail has many corner cases and even non-expert users can search the web to tweak config/policy settings to manage their own policies.

One techno-political precedent is CSS style sheets which at least tried to model a separation between "publisher" and "user" style sheets, acknowledging (a) the conflict of interest, (b) that users can override publishers.

What if every policy layer in client systems involved late-binding runtime negotiation among different stakeholders? An unplanned variation is happening with ad-blockers and anti-adblockers and anti-anti ... what if we developed DSLs for the purpose of efficient runtime and contextual policy negotiation? That would move us a lot closer to behavioral and contextual policy rather than semantic central policy.