You’ve made no contribution toward understanding Qubes, Qubes Air,
Wildland, or those documents you kindly numbered.
As an example, from the infamous 3rd post:
“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.”
Factual errors, and logical fallacies.
Please, no more.
I would support a KVM version of Qubes in addition to Xen, but I still prefer Xen for client/laptop because of the better security.
Hello everyone, I have been lurking around for more than a year but it’s only now, in the middle of the night, that I have decided to create an account and write my first post because this matter is one that concerns me quite a bit.
I share some of the concerns sven and qufo pointed out, mainly the fact that Qubes Air might have some negative consequences for non geeks as sven put it. I don’t think for a moment that the Qubes team will force people to use Qubes in the cloud, what worries me is this: “The beauty of Hybrid Mode is that the user doesn’t even have to be aware (unless specifically interested!) in whether a particular VM is running locally or in the cloud” This to me is not beautiful to me at all, I believe (both from the article OP posted and comments made by ADW) that users will have the option to not use the cloud at all and keep things entirely locally but what worries me is that many non tech savvy users that rely on Qubes for their safety, like journalists and social activists, might have some Qubes in the cloud and not even know it. I like the concept and the possibilities opened up by Qubes air, I do, but I am worried about the implementation. In my opinion, and I am sure of others too, Qubes air should be opt in, not opt out, Qubes should all be local by default and would be up to the user to change that, perhaps in Qubes settings there might be an option to place that Qube in the cloud or something similar. Perhaps a reassuring solution could be asking the user during installation if he wanted to use Qubes completely locally or if he wanted to have the ability to place them in the cloud, akin to the manner the user is asked if he wants to download updates over Tor or not.
Anyway, it would be great if someone from the Qubes team could add some more thoughts on this. Keep up the good work, my life would be much more stressful without this amazing OS.
I believe as long as Qubes remains being developed independently (i.e. by ITL) this will never be a concern.
Firstly, Qubes has vulnverable populations as one of their prime targets and running software “in the cloud” by default could be against their interests.
Secondly running things in the “cloud” is expensive and I don’t think it would even be feasible for the Qubes team to do that by default for all users.
I see this future development direction as very enticing feature set for organizations (including newsrooms!). When resources are available in an organization, I’d say the way Qubes is rolled out is by having a system administrator who is responsible for setting up and maintaining the multiple Qubes systems in the organization. This is how I believe it’s done at the FPF’s digital security team.
And this is how I think the “qube in the cloud” will be rolled out. Not as something by on default (that would be incredibly expensive and nefarious for many threat-models), but instead that organizations have the power to configure.
“The beauty of Hybrid Mode is that the user doesn’t even have to be aware (unless specifically interested!) in whether a particular VM is running locally or in the cloud”
With my comments above I see this comment as non-nefarious. Assuming the model in an organization where most people are users and not necessarily administrators, they don’t need to be concerned about how the system is implemented and that is fine! (as long as it doesn’t go against their threat models).
One particular example that I can think of is at a newsroom, when people are working on a sensitive story. Instead of having all the documents scattered around individual journalist’s workstations, by using a remote qube, all journalists could be working directly on the same virtual environment, thus not risking ever having to be concerned about having sensitive documents for that story on their laptop.
Anyways, just my thoughts.
I didn’t know something like Qubes air was even possible but it seems like a great way to get more people to start using Qubes, very interesting, as long as, like others have stated, everything is kept local by default…
Moderator notice: TL;DR no!
This thread misunderstands the nature of free software (which Qubes OS is), which Qubes OS is a free. Also nowhere is this intention stated by developers. The idea is to give power to the user not take it away. It may come to a point where dom0 is running an extremely minimalistic OS for security reasons. But at that point it will still be accessible. The sanity test in free software is: if the developers can access a component on their laptops, so can you…
The question aroused (for me at least), after reading this topic.
What will happen with dom0 in the future? Will we have access to in a way we have it today? I asked that question there, didn’t found anyone ever asked about it before, so due to it’s better visibility and possible importance, I’m continuing here by posting my reply in the next post.
I find this is totally wrong reading. If A=B, it also means that B=A. So, is dom0 AdminVM? For sure yes!. But is AdminVM dom0? Not necessarily! So we cannot say that equation dom0=AdminVM is valid, which actually it isn’t. Dom0 is so much more! Is template a qube? Well yes, but qube isn’t necessarily Template! See? So, for the sake of others who won’t click on the link you posted, i.e. doesn’t stand for dom0 = Admin VM, but it means " as GUI currently resides in dom0" which is totally different, because tomorrow GUI could reside in any other AdminVM (it already does, but not in AdminVM? Anyway, it doesn’t matter).
So obviously other users are confused too about the dom0 in QubesAir
But even if this is true, it is good for the question: will we actually have as much as we need dom0s? Well, I admit even current single dom0 is too much for most of users. How would they handle as many of them? And my fear now: will they be offered someone else to handle those for them? In both cases, how much control then users would have over Qubes?
Or, there will be still one and only “control center”.
For these assumptions, let me quote Sven from another subject
How much control over it user would have then? The same as over Kernel and Xen? This insinuates AdminVMs again. But they’re not dom0.
Yet. But does introducing AdminVMs everywhere prejudge it’s “destiny” regarding users interacting with dom0?
It’s not about the term, it’s about the function of the core part of Qubes would have in the Air.
Goals
The goals of the Admin API system is to provide a way for the user to manage the domains without direct access to dom0.
Threat model
TBD
Can’t wait to see it
I must admit that I have a strong feeling of unrest that I will be enjoying and be fully responsible for my actions in dom0 for not too long in the future.
Not restricted but shouldn’t be used, and limiting dom0 is not really good idea as I believe it could limiting “qubes configuration” too.
Limiting dom0 is a very good thing for your security and customizability. Dom0 has access to everything and runs a lot of code, so any malicious or buggy program in it can easily break all your security achieved with carefully crafted split-* qubes and other compartmentalization approaches.
Fortunately, dom0 already does not have to run the huge PulseAudio code (which doesn’t look very secure to me). Did you loose any customization because of that? I think it’s the opposite, because now it seems easier to replace it as a whole, whenever a good alternative appears. Similar arguments go for the sys-gui.
There can also be several “partial-admin” VMs instead, each managing its own subset of qubes. (It will will probably attract a lot of business customers to Qubes, too, benefiting every user.)
Why do you need any control over dom0? Especially when it doesn’t do anything? I guess, it can make it even easier to replace it? Isn’t it more control?
Which function and why do you need it?
For the same reasons I want control over my car and I don’t have it, because its “dom0” is in someone else’s laptop and I have to pay for the diagnostics and repair, even if I could do it myself if it was mechanical?
I can’t explain it more banal than this.
Well, maybe having to pay for replacing mobile phone battery today unlike couple of years ago is more banal, I admit.
Instead of educating users, we’re continuously (and intentionally?) dumb them down - “you’re stupid, this is too complex for you, so we will hide it from you” politically correct wrapped in a wafer “we will make it easier for you”
Please don’t deny this as at least a possible legit perspective.
I completely agree that control over everything you own is essential. This was not the reason I asked. I meant, which control you are loosing when making dom0 minimal? AFAIK you still can do everything you could before; it just gets compartmentalized.
Would you also say that you lost control over the Linux kernel running in dom0, because it doesn’t have access to everything? (compared to an ordinary Linux distro) (some things are managed by Xen instead)
Thank you for this.
From the diagrams and the available documentation, it is obvious that tomorrow dom0 will have it’s own IP address and God knows which servers. Sounds familiar?
So, it’s not about minimalism (I can’t agree more with it), but about the topic subject.
It’s the best currently available tradeoff. Because Joanna, or some documentation, said that they would like to write their own (meta)OS from the scratch but it’s not feasible considering resources. I’m sure you can recall this.
Please cut the FUD. No one is trying to move your dom0 into the cloud against your will or any nonsense like that. The Qubes OS Project has always been a user-first, security-first project. Nothing about that has changed. Spinning inane conspiracy theories about one of our own 4.5-year-old articles accomplishes nothing constructive. If doing right by users for over a decade hasn’t earned us any goodwill in your eyes, then nothing we say will dissuade you from assuming the worst.
Also: It’s open-source software, remember? No one can ever stop you from creating your own build that lets you do whatever you want.
Heck, you could even fork the entire project and call it “Non-Evil Qubes (NEQ)” if you’re convinced that the rest of us are trying to be evil. If your fork is the superior project, surely the majority of contributors would abandon the old one to join yours.
Already addressed misconceptions about Qubes Air in detail in this other thread:
I don’t think there is any point in asking the question in OP post for now as there is no active development of Qubes Air architecture. Right now it’s just the development of induvidual blocks like sys-gui that could be used for Qubes Air later. But as I can see there is no development of Qubes Air architecture going on and Qubes Air for now is just a general thoughts on the topic without any definitive development plan existing.
So nobody can tell right now what will be with dom0 in the future.
In the future it may have restricted functionality because of different reasons for example disabling some functionality for security reasons or just because developers didin’t have time yet to make interface to securely access some functionality in dom0 like it is with Xen and CPU cores temperature right now:
This is not what “control” means. Dom0 runs on your own computer and you still have full control over it, even though it’s not pure Linux. It’s just different software. It’s like saying that after installing Linux you do not have any control over your PC, because your are used to run Windows – totally missing the point.
Same about Qubes Air. You choose where dom0 (or whatever will replace it) runs and you have full control over its source code and running options, even if it runs something minimal, even if it runs in (your) cloud. It’s just a choice of the operating system. If Qubes OS 5.x becomes an OS that you don’t like, you are free to continue using 4.x, but it wouldn’t mean that you lost contol of it.
It is still a goal and I think discussing it is a good thing.