qubes-remote-support looks quite good thing for me. I see it’s main use for me in having secure access to your server with QubesOS installed over the network.
@marmarek said that it won’t be preinstalled in Qubes and you’ll need to install it manually if you need this function:
You can read the links in the issue to get more info on this package.
This is mentioned in the 4.1 Release Notes:
Optional qubes-remote-support package now available from repositories (strictly opt-in, no package installed by default; no new ports or network connections open by default; requires explicit connection initiation by the user, then requires sharing a code word with the remote party before a connection can be established; see #6364 for more information)
Wait, sorry I won’t answer your comments at the moment (avoiding digressions, spinoffs, etc):
no new ports or network connections open by default; requires explicit connection initiation by the user, then requires sharing a code word with the remote party before a connection can be established (TCP/IP I emphesized from the diagrams)?
Is this simple, legit question asking for simple yes/no answer backed up with some official link? Mentioning remote access to dom0 several years ago was/would be considered as heretic, yet today we have it, as an option for now. So, tomorrow will be…?
3. Where is the dom0 actually in this concept? If no one knows, that isn’t good (“let’s go and we will see where we will end up”?). But I’m sure this isn’t the case, you people are taking this project more serious and meticulous than anyone else their.
I was heavily taken for the words and contexts I never wrote or meant about, while at the same time I’m quoting official docs and team members (deeplow mentioned somewhere it is actively developed, I had all the links and docs needed for this discussion opened, then “cut the FUD” actually cut my disp TorB and now I have to collect them all again), and I have a feeling I’ve been told that it is not written what we all can read.
And I’ll repeat for the last time: I’m not accusing/putting the blame on anyone for anything: this is your private project and you can do with it whatever you think is good (and as of May '22 it’s perfect to me), I’m just trying to comprehend where it is heading to.
I did ask this myself and my answer to myself was “it will be amazing”. Not sure what else one could foresee and why.
From your wording, it’s quite unclear which my statement you mean here. Could please be more specific, with quotations?
Not yet. Also, it will not be called dom0 but Admin qube:
A “local copy” of an Admin qube (previously referred to as the “AdminVM”), used mainly to orchestrate VMs and make policing decisions for all the qubes within the Zone. This Admin qube can be in either “Master” or “Slave” mode, and there can only be one Admin qube running as Master across all the Zones in one Qubes system .
Perhaps I see where you are heading here. No, your conclusion is not logical. You can’t simply have “optional” access to the Admin qube by default. In this way, there is just no way to manage your operating system. If you install it, then there must be a way for you to manage it and there must be non-optional access of the Admin qube. Otherwise, Qubes would be not usable by anyone.
I expect that by default Qubes installation will be configured in the same way as currently: for the local usage.
If you want a cloud-related configuration, you would have to install Qubes on several devices and then configure which one(s) will be Admin qubes and which ones will follow the orders. In any case, you have the non-optional access to the Admin qube.
Here is the quote from the original link:
Rest assured that we will also discuss other solutions not involving the cloud. The beauty of Qubes Air, we believe, lies in the fact that all these solutions are largely isomorphic, from both an architecture and code point of view.
It strongly depends in which context you are mentioning the remote access to dom0. Default remote access was a disaster and is still a disaster. This would be against the whole Qubes approach to security, making all many-year work useless. From this point of view, nothing has changed: dom0 is still offline, unless you really want otherwise. If a hacker can install the remote access tool in your dom0, then you already lost the battle before it’s done and whether such package exists or not.
I see where you’re coming from. Indeed, many proprietary projects start as extremely useful, then extend their functionality to the cloud and then cut the offline option forcing the user into the cloud. One recent example coming to my mind is ReMarkable tablet. However, I do not know of any free-software-based projects going this way. Can you give an example? This is the whole point of the 4 freedoms of free software: you can’t just do this without loosing your users, because there is no walled garden keeping them in.
As I mentioned above, dom0 turns into Admin qube, which can physically reside on a different hardware. I think it’s explained in the Qubes Air article quite well.
I’ll be away for sometime and will not reply soon. But I thank you for your clarifications. They’re not of the value to me only, and you probably knew this even before you started to type.
Great example!
There is no mention anywhere (at least I didn’t see it) that the remote-controlled system will be default QubesOS installation with packages like qubes-remote-support preinstalled.
There is a difference between running dom0 remotely and controlling dom0 remotely.
When I said that it’s not possible to run dom0 remotely I was talking about network boot of dom0 by Xen with PXE or something. I don’t think it’s possible.
But remote control of dom0 - sure you can do this even without installing some package like qubes-remote-support:
From my point of view without direct access to dom0 mentioned in the docs meant the same thing as with Xen. You can’t access Xen directly and can only control it using interfaces that Xen gives to dom0. The same thing seems to be the goal for Qubes - you won’t be able to have direct access to dom0 and you’ll be able to control dom0 only from some AdminVM using interfaces that Qubes will give you.
I have some concern over this as well if you won’t have access from AdminVM to some of dom0 functions that won’t have implemented interfaces in AdminVM for some reason (not yet implemented because of low priority feature / disabled for security reasons). But there should be some hack to configure what you want in dom0 even if it’ll be a pain.
I don’t think the restricted access to dom0 in this case is about running dom0 remotely but by restricting it like Xen as I stated above.
It should still run on your hardware as Xen privileged guest:
https://wiki.xenproject.org/wiki/Xen_Project_Beginners_Guide
A “local copy” of an Admin qube (previously referred to as the “AdminVM”),
And AdminVM was never dom0, unlike vice versa. This is crucial thing that confuses me, and I’m referring to it again since you mentioned it
If you were right, wouldn’t Joanna wrote:
A “local copy” of an Admin qube (previously referred to as the "dom0”),
I don’t get you here. It is clearly stated in the docs
without direct access to dom0
These are not my words or assumption.
Based on what writing? Any qoute?
On the either hand the whole Joanna’s article you quoted too, is about "cloudification’ of Qubes.
And off the topic a bit, the main reason for Qubes Air is hardware compatibility, so the answer to this is:
Above, we discussed how it’s possible to move Qubes VMs from the user’s local machine to the cloud (or to physically separate computers) without the user having to notice. I think it will be a great milestone when we finally get there, as it will open up many new applications, as well as remove many obstacles that today prevent the easy deployment of Qubes OS (such as the need to find and maintain dedicated hardware).
OK, so who has the proper hardware to host Qubes on cloud?
The more I think, the more dilemmas. OK, I don’t have proper hardware. You have it and you host the Qubes on your hardware in the cloud. So, I have to rely on you that you have proper hardware, and that your Qubes won’t be compromised and then my VM too?
Or, next scenario, VM is considered to be compromised by default. This applies to wherever VM is. So, although you have a proper hardware, the VM you host for me is compromised anyway, and since I don’t have proper hardware, and I access compromised VM, I am again under the possible at least side channel attack. So, where is exactly the benefit for me you to host my VM?
Jesus Christ, I must be torn down by my age…
As @Sven would say - Cloud down, I’m down…
Discuss, unlike the statement from the above again:
Above, we discussed how it’s possible to move Qubes VMs from the user’s local machine to the cloud (or to physically separate computers) without the user having to notice. I think it will be a great milestone when we finally get there, …
So, no discussion about cloudification, but no-cloud - maybe, right? Or, it’s a language barrier?
Exactly. Am I finally comprehended. And to backup my fears, read my previous paragraph. With the slight correction - not cut off but to make local option so inferior to cloud, that it just would be pointless to use it. And for such scenarios, you probably heard about much more then for a total cut off.
Whole Joanna’s article is wrapped in a “convenience wafer”. So, let’s see if we’ll get increased security and/or privacy from clouded Qubes:
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.
Wow!
I’m not naive. So much went to the cloud, and finally, everything will. It’ll happen maybe after Qubes 6, or later most probably, just as GUI domain was first mentioned ten years ago and it happened. Nothing is mentioned by accident, and this doesn’t implies evil plans and evil devs. It implies legit roadmap I can like it or not. Why it looks to me that this is obvious yet denied (only by you and @adw)?
By the devs, it isn’t, I just find it offendable that explanation for the roadmap is - “it’s better for me”, or “no, it won’t happen”.
And I am very well aware that I’m acting as I found a giant jewel, and now afraid it’ll be cut into pieces and hosted in other’s vaults because it’s better for me…
I’ve been an advanced Qubes OS user for about 10 years since R1 days and have followed Joanna’s & Marek’s posts regularly and community discussions semi-regularly.
I absolutely hate The Cloud. I’m the type of user who customizes my Qubes for greater security and privacy, writing my own utilities and scripts to go well beyond what the already great Qubes OS provides by default. If the Qubes OS project ever made third-party cloud hosting of my Qubes mandatory, then I would barf inside of a cube and mail it to the devs, anonymously of course. Seriously, Fsk The Cloud (other people’s computers).
That said, I was pleasantly thrilled to read Joanna’s vision/plans for Qubes Air, and can’t wait for Qubes Air to come to fruition.
While these hybrid computing concepts can be confusing to the average-skilled user, it was quite clear by the original postings that there was no vision/plan for any mandatory third-party cloud requirements or limitations. It was also clear that locally-running Qubes OS (as it is today) shall always be possible.
However, even though I hate The Cloud with a passion, I am very eager to consistently use the cloud features of Qubes Air.
While I truly hate The Public Cloud, I do very much love My Private Cloud (secure local network of devices).
With Qubes Air, I can’t wait to have my local desktop machine act as a Qube Server, and my other mobile devices act as Qube Clients, such as my laptops, tablets, maybe phones one day, etc, running/integrating Qubes all within my own tightly controlled private cloud (local network of computing devices exclusively within my home).
This Qubes Air implementation would securely and privately alleviate numerous pain points with running several local Qubes OS devices together. By reading the original posts, this clearly was part of the original envisioned plans for Qubes Air, and as a hater of The Public Cloud, I can’t wait to run Qubes Air on My Private Cloud of local, networked, trustworthy devices.
From consistent behavior over 10+ years, it is clear that the Qubes OS devs and team also have a healthy respect, culture, and userbase that supports owner controlled computing principles. While it is totally fine that Qubes can be seamlessly networked together, whether across a LAN, WAN, or the internet, and whether across first-party or third-party infrastructure/computers, it is vital that no third-party internet requirements be mandatory. And it was very clear to me, from the original postings, that no such bad requirements would be mandatory, and that local Qubes OS computing would always be available as it is today.
Could there be some conspiracy to make Qubes OS into a third-party internet-cloud ONLY hosted system over time? That’s just an farfetched possibility that has no basis in the demonstrated reality of what the Qubes OS project and people are about. And the Qubes project is easily forked and re-released by us cloud-contageous local-loving community developers if the Qubes team were to ever sell out and stop supporting local-running Qubes. Build and sell Qubes as a Service all you want, but always allow Qubes OS to run offline, locally on one PC or optionally locally on multiple PCs/devices. After being with Qubes OS from since the early days, and reading the Qubes Air postings multiple times, I see no reasonable indication that the Qubes team is planning anything bad here, which I and others like me would dislike on our machines. Easy to fork and re-release, if some great conspiracy makes me wrong though.
Fear not, fellow community members, Qubes Air should be a great enhancement (and entirely optional), which can actually help us users who love our locally-running security and privacy systems, and who hate The Cloud with a passion.
Think of the very neat possibilities of running a Qubes Desktop Server and then branching (locally networking) off of that server with your mobile devices, such your laptops, tablets, and maybe phones one day, in order to have an integrated cross-device Qubes environment working seamlessly together, which is all locally networked and kept far away from The Public Cloud if you choose (or even totally air-gaped offline).
If you hate The Cloud like me, then you should still want Qubes Air, as it is optional and also very useful within Your Own Cloud (your own private/secure local network of devices).
I couldn’t agree more, I don’t see how anyone loses anything from the proposed design concepts.
If you don’t want or don’t need the cloud feature, I don’t see anything that would stop you from running the service locally without connecting it to any other systems. I don’t see how that would be a major change from what we have today.
I really can’t see how the option to use public or private cloud is going to hurt anyone.
The idea of having a powerful PC/Server at home which you can use from a secure laptop when away makes a lot of sense to me.
To this - amen from me. Until all the hardware is mine, dom0 is with me, and nothing is other’s.
Again, where exactly it says so? @fsflover tried to find it, but dom0 is never to be found in the article, only Admin qube was mentioned by Joanna and she referred to it as an “AdminVM”, and what “AdminVM” is you can read here:
and here:
for example
This is correct.
This is not yet the case, so saying “previously referred to” would be wrong here.
OK, this is a misunderstanding caused by a large number of the underlying context here.
Someone must have a full access to dom0/admin part of Qubes OS in order to manage the Qubes OS installation. Otherwise the OS would be useless for everyone, including any “evil corporation”, if it ever might seize the control. Conclusion: the controlling part (however it’s called) will always be a part of the OS.
If you have the full source code, including the “dom0/admin tools”, you can always install it such that you have the full control, cloud or not. Qubes OS license is GPLv2. Conclusion: You will always have the access to the source code and full control over the OS.
Rest assured that we will also discuss other solutions not involving the cloud. The beauty of Qubes Air, we believe, lies in the fact that all these solutions are largely isomorphic, from both an architecture and code point of view.
Isomorphic in this context means that, from the point of view of Qubes architecture, it does not matter whether your qubes run in RAM on this machine or they are completely different devices connected over a network. You design Qubes Air around the “cloud” but you can still use it in the same way on a single machine. It how you deploy that defines whether it’s a cloud or not, not the architecture. The linked article is about the architecture. To me, it has always been clear from the above wording.
This looks really scary indeed, because you forgot to make the other relevant part bold too:
it’s possible … without the user having to notice
doesn’t mean it’s the only possibility. You quote just says the same: “it will open many new applications” (which doesn’t imply that it will close existing applications).
I think you misunderstand what is said here. Indeed, it’s not expressed so clearly in this case, although in the context of other discussions, it’s clear to me. This is about a special use case: corporate deployment (see below).
No! Look, what do you think the main problem of Qubes OS right now is? Let me tell you: it’s the money! How do you get it? From the companies using Qubes OS and asking for support/development of new features. Many of them are really interested in secure computing, defense against ransomware, peace of mind when opening files from clients and so on. They are not interested in a local machine, where the user has full admin access. This is useless for them and also useless for the people working there who don’t want to administer the computers and only want to perform their own tasks. So in some sense you are right: the reason for Qubes Air is to make it possible to restrict the user access. Ordinary workers will not need dedicated machines from the Community-recommended list to run Qubes in this case. But please see above about the source code license and isomorphism.
This is exactly about the corporate use case. It does sound scary in the context of ordinary users and reminds the approach Windows has taken. However, there is no single example when free software with GPL was turned into such evil software as far as I’m aware. This is the whole point of the four freedoms! By the way, you ignored my question above about about it.
I need to clarify that I refuse to call it “the cloud”. That word is nothing but a marketing gimmick designed to make simpletons feel comfortable with the idea of storing their private stuff on other computers connected to the internet owned by people who don’t know you nor necessarily give a damn about you.
You’ll never hear me say that infernal word, unless it’s to describe how shockingly well it has worked on the general public…
You’ve never hosted anything, have you…
Give it a go with an old machine on your LAN! You’d be surprised at what you learn. Networking stuff is actually fun too 
Hardware isn’t the issue. I’d be more worried about your network connection…
Ok. *takes deep breath*…
(anyone who’s ever managed a server or large network, skip a few paragraphs)
So, the common misconception about servers is that they need to be incredibly powerful. Well, if you’ve got millions of people accessing the same thing every second (like this awesome forum), then yeah…
In terms of Qubes-Air, you could host this yourself if you wanted to, out of your own household internet connection.
Think “VNC in a Qube with a healthy dose of qrexec”, and the VNC part is running off a box in the corner of your bedroom/office/garage/data centre.
It’s highly likely that only one person would be accessing a remote Qube at any one time, so you would probably only need the same hardware resources that you’d need to run it locally. The only difference is that your usability would be limited by your network bandwidth.
Well, if you wanted to rack-and-stack Qubes-Air as a service and charge people for hosting them, well, I saw an old IBM z290 on eBay for $6k USD…
That would be very fun, though 
A fast reliable connection between your local machine and “the other end”
A connection that could cut out abruptly could cause your Qube to implode, resulting in loss of data, leakage, and just general bad vibes all around.
I’m sure there would be a way, but I haven’t given it much thought yet. I’m sure network engineers will be the first to tell me that there is a way and that they’ve been using it for years…
Well, technically yes, but it gets very messy very quickly if you start trying to safeguard against privacy…
Possibly, but there would be ways to mitigate it. For example, if you did any computing on their hardware, you’d be at the mercy of any vulnerabilities of their hardware. There’s also a chance that they’d be able to mess with it if they wanted to. Encrypted data isn’t really meant to be interacted with while it’s encrypted…
Potentially, but that doesn’t mean it couldn’t be presented to the user in the same form as the AppVMs we know and love.
Well, electronics with chips in them are being connected more and more. There doesn’t seem to be much anyone can do about this. It’s where the world is going.
It brings so many awesome and very cool things that our devices can do. When you aggregate every single electronic device on the planet, you can achieve things that simply were unthinkable before.
The issue is that we’re combining our devices which we’ve managed and configured, with devices belonging to other people that we don’t know, nor necessarily trust.
We’re sharing each other’s RAM, CPU, storage, and GPUs. We’re sharing each others printers and scanners, 3d printers and any other device you can think of.
The key to it being feasible for us is to figure out a way to be able to:
…while still…
…and…
Me too. It’s what I currently do, and it’s AWESOME.
Embrace, Extend, Extinguish?
Don’t you remember Java? And they nearly got away with releasing certain “special features” in binary-only form for Windows only for .NET. And WSL is easily the same thing…
But this is a bit off-topic
Qubes-Air will also have interesting implications for local backups too. You might even be able to transfer a Qube locally from one laptop to another while it’s still running. That would be really cool (and very handy for certain people).
So, your statement that dom0 will be called Admin qube must be wrong, because from Joanna’s statement it is obvious that AdminVM will be called Admin qube?
Who? The answer might be found even in your comprehension
But… it looks that this controlling part offered to us, regular users would be only AdminVMs (future Admin qubes) and not dom0! Remember: Qubes-as-a service. “Here’s your AdminVM and create your own templates and qubes, but the dom0 is with us…”
Let me try to strip it down to the bone here:
**Will Qubes be “aired”? It will be. In which form? Still discussed, but “aired”, right? So, we still don’t know how it’ll look. Will it be as transparent as Fedora flavors, for example? Will it be all-in-one, while today even single user platform suffers from the lack of dev’s resources. We don’t know. Which brings me to the point - if we don’t know this, we don’t know where the dom0 will be either, unlike Admin qube which is applicable in any model, thus mentioned. Which again leads me to conclusion that “we will see where the dom0 will be depending on the final model we choose” is current situation **
A wise man told me once when I was younger: whoever tells you that the money is problem job to be done, be sure it isn’t. Look for the problem on the other side.
And it was so true. Whoever works with money (and not exclusively who owns it), most probably knows this
And to tie this replying thought on your companies-money paragraph with the one that I allegedly “ignored your question”, I’d like to add an example of discontinuation of RHL in favor or RHEL. It doesn’t matter both were commercial. What it matters both were open sourced. I wouldn’t mind to pay for Qubes, I already stated this even in survey.
@alzer89
Thanks for you contribution, but I find it absolutely irrelevant if participant has advanced skills in particular IT area for this discussion. The question is simple - where in Qubes Air will be dom0? No skills needed to ask such a question. It is still rhetoric, since we witnessed only guessing, optimism, best wishes or ignoring/avoiding to answer.
But what’s the point of asking a question if you can’t be bothered making a effort to understand the answer…?
Wouldn’t listening to the answer to that question require at least a willingness to learn?
Otherwise you’d be wasting your breath on a stubborn imbecile…
EDIT: This is intended as a general statement, and was not implying in any way, shape or form whatsoever, that any participant involved in this discussion was being referred to with this statement. If this happens caused anyone offence, I apologise. It was not my intention.
It will be in magic land with the unicorns and rainbows, obviously. Where else would it be? 
Ok, now that I have your attention.
EDIT: This was intended purely as satirical humour, and if it has offended anyone, I apologise. It was not my intention.
I feel like this would be easier with diagrams, but that’s basically what it boils down to.
On a side-note, I’d love to host Qubes-Air as a service, but I would want to do it in a way that made sure that I was not able to see the contents of the Qubes.
I’d probably opt for the method of full on-site encryption, and making sure that I did not have any copies of decryption keys.
I’d also prefer it to have no VMs running in my servers. If they’re running, then that means that the decryption keys would be in my RAM…
(or at the very least, a gigantic disclaimer saying “If you run your VMs on my servers, I CAN SEE EVERYTHING, and so can law enforcement, potentially. So it’s not a good idea to do anything in these VMs that you don’t want anyone else to see!”)
It is not unthinkable that law enforcement would bash the door down and seize the servers. The last thing I want is to be considered an accessory to serious crime because I was holding/running someone’s Qube…
Ok, let’s demistify this (false?) statements.
So, what exactly I don’t understand from this example, no really?
Did you read whole topic at all? Honestly?
Of course. I’m trying to understand what? Local dom0, or something without user’s direct access to it, or just an interface to a service, or everything? Says where it will be like that, whatever is that?
I admit this was actually how I imagined Qubes as a service scenario. You have dom0, i have some kind of “stripped down” Qubes without dom0 features (or without direct access to it even being on my computer), but with some kind of VM serving to connect to your computer, and from there… you know.
Of course
Of course.
Of course. So here again to repeat my quote from the post #42
… and all we do, to add here.
And we still don’t know what ways there will be, right? And the fact concerns me, because it is not publicly decided so we’re not in the know.
Of course. I already said amen to that reacting on @RCQubes post.
Says who? Wouldn’t be possible to boot my machine from some stripped down version of Qubes, blaha, blah, I already wrote about that above?
I;m not talking about “betterness”. I’m just trying to realize will it be secured for me like I am satisfied with it now - it’s (almost) all in my hands and I have that sweet burden of full responsibility for my actions and data. For the first time in my digital life.
I hope that now you think that I understand what is written, that I’m trying to thinking through it and that diagrams aren’t needed. Thank you for your time to explain, really.
All of this will be possible for sure. It will just depend on your deployment strategy.
Until last October I used Qubes for several times for several days in a row, since R3. (so, tried for many years). Since then, Qubes is my daily driver and I suggest you to check my profile: it would be enough topics I created, and solutions I gave until this May to give you an answer to your question above.
I don’t get the context of this, definitely language barrier, but I don’t like wording, whether it’s benign or not.
I didn’t mean it like that….
But come on. At least make you Batman and me Robin…. 
Yes. I read it when it first came out back in 2018, and thought it was awesome (and it still is awesome).
That would also allow every Qubes-Air “client” to also simultaneously be a Qubes-Air “server” as well, which would be kind of cool.
Does it have to be only one way? Would multiple ways simultaneously working in harmony also be possible?
That way the user would be able to pick and choose based on their needs…
That’s what I meant. I mean, unless you wanted to have some sort of network boot (which would be kind of cool, to be honest)….
But in any case, the local machine would most likely need to support similar CPU features as a full Qubes OS install.
Yes, there would be a way to do it without hardware virtualisation, similar to Citrix Workspace, but I haven’t given that much thought.
It would be cool though…
@enmus , your name is legendary through the Qubes OS community. Seriously. The amount of help you give to new users, coupled with the deep understanding you have of the OS, including to the point that you’re actively contributing to its improvement; demands nothing but the highest respect.
It’s something that you don’t often see nowadays, and I commend you wholeheartedly for it
I don’t think it’s off-topic in the context of @enmus’s concerns. First, you cannot buy out Qubes OS, because for that you would have to get a written agreement from all its contributors, which is close to impossible. See also: https://www.quora.com/Why-isnt-Linux-bought-out-by-Microsoft. Even if you did, the FLOSS version would still be available to everyone. Second, despite WSL, Linux is still fine and (slowly) growing, so it did not turn Linux into Evil Software. It just turned Windows into more Evil.
This looks like just a semantics to me. You can call it however you like. Looking at my Qube Manager, I can see that currently, dom0 is AdminVM – it’s written right there. I got confused here as well. But what’s the point? If you possess a computer, then you control it, unless you yourself install some software which you don’t like. Also, “dom0” terminology comes from Xen “domain zero”, which will not be generally applicable to Qubes Air, hence the change of the naming will be necessary.
If you configure your future Qubes-Air in a way that your computer can be managed by another server (“the cloud”), then you will have “local AdminVM”, which has fewer permissions than the server. You can always change that by reinstalling if you wish, can’t you?
How you can run some free software on your computer without having full control of it? If you don’t like it, you just stop it and install something else, don’t you? Do you expect that someone can force you to run “Evil-Qubes” and not an earlier, “non-Evil” version?
Personal attacks are not helpful. I read the whole topic and I’m still mostly confused about what you are trying to ask.
See above: something with fewer permissions than the “main” dom0. What’s the problem with having this option? I would be happy to configure my relatives’ laptops like this.
Qubes OS is not the solution to all problems in the world. It’s just a free operating system, which allows to have freedom and security. If users install (or buy preinstalled) an “Evil-Qubes” version, there is no way Qubes developers could help here.
This is technically correct, but you also can’t conclude that Evil-Qubes is inevitable. This is just a baseless accusations of the developers and is not helpful. Also: see the argument about free software above.
What do you mean by “almost”?
OK, here we all agree then.
