Hi I just found Joanna Rutkowska’s blog post Qubes Air: Generalizing the Qubes Architecture where she states that that is the next step for Qubes-OS. The article was written in 2018. So, I wonder whether that’s still the objective; getting Qubes in the cloud? Really?
3 Likes
Development seems to have been going slowly but steadily. As far as I’m aware, the biggest refactor towards that goal is the new GUI Domain. If you haven’t already, you should read this:
2 Likes
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!
1 Like
I guess this is a prime example for shooting from the hip, isn’t it? 
Are you always this quick when it comes to decisions based on (uncertain) considerations for the future?
There’s a trend to “either…or” even if “both…and” is in the realm of possibility.
I’ll wait and see and stay a happy Qubes user. 
You could add that to “your solutions for now”.
2 Likes
Six month testing, reading Qubes documents including related ones, and reading/writing code… Nope, I don’t think that’s quick…
That’s why:
So do I, but I do not support the SaaS/Cloud goal, hence I turn my time away from. Just observing…
You just did.
Anyway, Qubes OS is not even booting on my systems. AMD Ryzen 5/7 based Linux tailored laptops. Because of that unfortunate decision to base Qubes OS on Xen.
Sorry, to me it sounded like you were abandoning your Qubes system because of the above mentioned “news”. My bad.
From your first link:
Readers who are allergic to the notion of having their private computations running in the (untrusted) cloud should not give up reading just yet. Rest assured that we will also discuss other solutions not involving the cloud.
Example: Hybrid Mode
Some users might decide to run a subset of their qubes (perhaps some personal ones) on their local laptops, while using the cloud only for other, less privacy-sensitive VMs. In addition to privacy, another bonus of running some of the VMs locally would be much lower GUI latency (as we discuss below).
Example: Qubes on “air-gapped” devices
This approach even allows us to host each qube (or groups of them) on a physically distinct computer, such as a Raspberry PI or USB Armory. Despite the fact that these are physically separate devices, the Admin API calls, qrexec services, and even GUI virtualization should all work seamlessly across these qubes!
So (forced) SaaS is absolutely not where Qubes is heading.
This strikes me as a gross misinterpretation. There are no plans to force anyone to use the cloud. It’s just a proposed architectural improvement that would allow for the capability of having qubes (or zones) on different physical devices. If you don’t want to do that, simply keep all of your qubes on the same physical device that you own and control, just as you do right now.
By way of analogy, it’s possible to run both a client and a sever on the same machine. It’s also possible to run them on separate physical machines.
If I wave a magic wand and suddenly grant you the power to move any qube you wish to a separate physical machine (and still have it work the same way), you have lost nothing if you choose not to exercise that power.
5 Likes
Random slightly off-topic picture:
2 Likes
I think it is very important to share this idea of next generation Qubes. I am pretty sure future will bring up some new approaches or solutions … and threats.
i.e. setup Qubes Air on a distributed, onion-encrypted, surveillance resistant network and freely accessible mix-network. I will not make ad here but things like this are in development and imo it could be also options to consider for Qubes Air.
1 Like
Of course…
Did I used the word force? Hmm… 
And yet it’s already actively developed. The idea is to get rid of the deployment problem:
Deployment cost (aka “How do I find a Qubes-compatible laptop?”)
Probably the biggest current problem with Qubes OS – a problem that prevents its wider adoption – is the difficulty of finding a compatible laptop on which to install it. Then, the whole process of needing to install a new operating system , rather than just adding a new application , scares many people away. It’s hard to be surprised by that.
This problem of deployment is not limited to Qubes OS, by the way. It’s just that, in the case of Qubes OS, these problems are significantly more pronounced due to the aggressive use of virtualization technology to isolate not just apps, but also devices, as well as incompatibilities between Linux drivers and modern hardware. (While these driver issues are not inherent to the architecture of Qubes OS, they affected us nonetheless, since we use Linux-based VMs to handle devices.)
Although the above mentioned problems could be mitigated by replacing Xen with KVM. And you could still develop a cloud solution of some sort. Maybe a server version (Xen based) and a client version (KVM based). That would enable users to run there own private cloud, if desired.
As long as Qubes OS is based on Xen it will never really work on newer hardware that’s a fact.
See above. It’s still Xen based. So, it probably will lure users to go for it because (a) they use Qubes OS already, (b) therefor have data in it. Since we know how tedious it is to get your data out of it it’s quite likely that some users will go for it. Simply to avoid to move back to a traditional solution.
I know this process quite well because of the different tests and evaluations I did in regard to virtualization/isolation. It can be quite difficult to entangle all the separate VMs.
However, that’s me. This whole post is the conclusion of test/evaluation of Qubes OS, and I wanted to create a post, which consolidates the planned future of this project.
I’ll keep in eye on it, promise . That’s it.
If I ever wanted to switch from Qubes back to a conventional monolithic operating system, I would probably just:
- Copy every AppVM
/hometo a USB drive. - Copy everything from the USB drive to the monolithic OS.
Done.
I can’t see myself ever doing this, but it hardly seems difficult.
Even if all you had was a Qubes backup, and suddenly every Qubes ISO, line of code, and existing installation somehow vanished off the face of the earth, we went out of our way to make sure that you can always get your data without us: Emergency Backup Recovery without Qubes.
Using Qubes is basically the complete opposite of vendor lock-in. 
The Qubes Air article is not really about Xen vs. KVM. If you want to read more about that, search out some of the threads on qubes-devel and issues on qubes-issues. Also see here and here.
3 Likes
Yep…could work, provided you used in all AppVMs the same OS/Installed Apps/settings etc. Otherwise it leads to quite a bit of manual work. No? All easy peasy? Are you using Whonix? Yes… Do you know how to configure it on a traditional Linux distribution?
Since you haven’t tested it yourself yet, you don’t know…I would suggest you try. Simply to prove your point. Not to me to yourself…give it a shot…
I had to do it; twice…and I was involved in updating and testing the documentation. In my case it took three days on an AMD Ryzen 3 / 16GB RAM laptop. I had four small AppVMs <32GB, and two big one >130GB. The small ones were no problem, but the big ones were: Unpacking failed…and when it didn’t fail it ran for ages.
I didn’t say that. I said and still say that Xen is server software in will not work on newer laptops. If your target groups are laptop users (journalists, activists, whistleblowers, security / privacy advocates/consultants, etc…) then KVM would be the best solution. There is no such thing that one size fits all. So, in short two versions: one KVM based (client/laptop) and one that is Xen based (server). That’s what I pointed out.
Thanks for the links. I read them. As I mentioned earlier on this thread, I did six month intensive testing/reading etc.
But now you’re talking about something different. That isn’t about getting your data out of Qubes. That’s about trying to duplicate the functionality of Qubes outside of Qubes.
Getting your data out is still easy in those scenarios, since you can simply qvm-copy it to another VM, then to a USB drive.
And thanks to you, it’s now easier.
I’m just pointing out that “Xen vs. KVM” appears to be off-topic for a thread about Qubes Air.
However, I also think you’re probably overlooking the security trade-offs involved with KVM. There’s a reason the Qubes devs (some of whom are world-class experts in virtualization security) still think Xen is more appropriate for Qubes than KVM right now, despite all of Xen’s flaws (which they are very open about). But this is for another thread (probably better suited to qubes-devel).
1 Like
Nope. I don’t talk about replicated Qubes functionality. The beauty with VMs is that one can configure them specifically for a certain application, and it’s super easy to run different versions in separate VMs. With different versions I mean both application versions and same version but differently configured. Developers, troubleshooters, testers, reviewer etc. use that. So, now in the event you want or have to go back to a traditional system you run in problems. It’s not just copying. There is whole bunch of re-/configuration work involved. The whole context / concept changes when switching from Qubes OS to a traditional system or vice verse. So, it takes you out of business for some time. Of course by using the cloud one can omit that, but that’s out of question, because that means giving up control. Not happening ever.
Thanks for the flowers.
I do not say Xen vs. KVM; I say Xen and KVM. Xen for server; KVM for laptop.
I do not neglect security trade-offs, but a system, whatever system, has only value if it can be used (on recent hardware) not only on 3-5 year old hardware, otherwise whats the point.
That’s exactly what I’m saying. You’re just agreeing with me now. You have perfected the art of disagreement through agreement.
The point is to have a reasonably secure operating system that you can actually use right now for practical, real-world daily tasks. You’re in a forum full of people doing exactly that right now.
If you don’t find any value in that, then perhaps Qubes is not for you, and that’s okay!
(By the way, some of these people are using hardware more recent than 3-5 years old.)
Where do you see me agreeing?
I find value in having a “reasonable secure OS”, but Qubes OS isn’t even booting on laptops/mini-pc I manage. It runs only on an old Acer Aspire Ryzen 3 (that’s just a dual core cpu) with 8GB RAM, but that was unworkable slow. I increased the RAM to 16GB (the max possible) and it was still slow. VMs had to be started each at a time. Booting took 2-3 minutes. That’s not acceptable for an OS that shall run on a laptop. Although Qubes requirement states 4GB is enough. That’s a joke. Furthermore,that’s what the thread is about, is that I disagree with the monetizing through an SaaS platform, where the paper (first document) clearly states that that is sacrificing privacy and security for convenience. I understand that a project needs money, but that shouldn’t be through such a shady proposal. That’s how it looked to me.
I’m long enough in this business to have my own “reasonable secure system”, and too long in this business to fall for this cloud stuff. Cloud means the user becomes the product (it does not matter whether it’s a free or paid service, they all surveil, track, and use the data as they please).
Only if your cloud is controlled by someone else. With the Qubes Air proposal you can set up your own cloud. I do not see any disadvantages at all with having that option.
Sounds like a reason to start a new thread and find a solution.
Worked fine with 16 GB for me. Perhaps it’s slow for you for some other reason? Or maybe you are using too many VMs? The latter is my case, so I had to get 32 GB.
1 Like
Yep…but only in that case. How man average users might / could do that?
Nope. Case is closed by now. It was simply too much for a 2 Core CPU and 8GB RAM, even with 16GB, but with 16GB I could actually use it, but only in a way I described earlier.
As I said before minimum is a quad-core and 16GB RAM, but the official requirements don’t say it.
Works like a charm on my 2-core laptop. Due to my exceeding use of many qubes, I had to install 32 GB RAM, but with 16 and not too many qubes it worked quite well.
Why do other users concern you? If you care about your security, everything is covered, no? Others decide for themselves.
1 Like