After doing a bit more research it turns out that the final goal is to get Qubes OS as a SaaS. Documented in the following documents:
- Qubes Air: Generalizing the Qubes Architecture
- Qubes Architecture Next Steps: The GUI Domain
- Wildland: Why, What and How?
- Project WildlandThe Why, What, and How
Quote from the 1st document:
This approach may trade security for convenience (if the endpoint device used to access Qubes-as-a-Service is insufficiently protected) or privacy for convenience (if the cloud operator is not trusted). For many use cases, however, the ability to access Qubes from any device and any location makes the trade-off well worth it.
I can’t disagree strongly enough!
In essence I understand that the user’s device (laptop, smartphone, tablet, desktop, whatever…) shall be a viewer, that’s it. It’s shown in the document that a user can have a hybrid installation, but that wouldn’t change the fact that the ultimate control is with the provider like with any other cloud solution. That’s still true even by implementing the Wildland protocol (documents 3 and 4), regardless how fancy it maybe. Bottom line is always that the software and hence user data are on the server infrastructure of the provider, hence out of the user’s control.
If the user wants to be in control, and she has to be, than the only way to archive that is to have the software and data on hardware she controls; meaning owns.
Btw, the SaaS approach explains also as to why the Qubes OS project holds on to Xen (Xen is server software). A lot SaaS solutions run on Citrix, which is Xen based.
Conclusion, solution for now:
Back to Tails and a base Linux distribution (rolling updates, like Manjaro, or pure Arch-Linux, or Gentoo, etc) with isolated VMs, split Internet access (clear-net / tor (Whonix)). On owned hardware!