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?
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:
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.
Plug in Qubes-Air “Box” to LAN
Tell router to open port 1337 (if this Qubes Box wasn’t fancy and didn’t have uPNP)
Punch in your WAN IP (or clearnet domain name or .onion domain if you’ve got one) into your Qubes OS
Start using Qubes OS, potentially with “Buffering…” and “You have to download RealPlayer 7 to use this Qube…”
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
What are potential ways in which you could have one of your Qubes “off-machine”?
A local Qube that is essentially nothing more than a glorified X11 forwarder (but integrated into the XFCE desktop with multiple windows) that would connect to a VM running somewhere else
Throw in a bit of QUIC and IP addresses into the qrexec protocol, so that USB devices, block devices, etc. could be shared regardless of where the Qube was running
Potential for a detached LUKS header, which could even be encrypted on the local machine, which would also likely contain the location of the remote Qube
Could potentially be a “RAM hog”, depending on how much you want to safeguard against a dropped connection
A remote Qube in an encrypted state that is transferred entirely over to the local machine (or piece-by-piece) and run locally
Would mean that entire Qubes could be laying in a dormant and encrypted state when not being used
Would be similar to a 3rd-party hosted remote password manager. They lock up your passwords and store the encrypted data for you, and they don’t have the key. When you need it, you take the whole Qube, decrypt all of it, use it, then lock it back up and “give it back”.
Potential for a git-style merge sync between local and remote versions.
Some kind of hybrid of the two.
Can already be achieved with existing software (NFS, SSH, USPIP, and many others I fully don’t know about), but it just might not feel like good ol’ Qubes OS, you know?
What non-negotiable thing would you need to make these “work”?
A fast reliable connection between your local machine and “the other end”
Why?
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.
Is there a way to safeguard against this, like RAID in hard drives?
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…
Would multiple machines be able to “share” the same remote Qube?
Well, technically yes, but it gets very messy very quickly if you start trying to safeguard against privacy…
If I ran my remote Qube on someone else’s machine, would they be able to see everything I do?
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…
So why would I want to do this?
Perfect for border crossings. Nothing (or very little) is locally stored on your machine.
Qubes OS on a Chromebook from 10 years ago sounds pretty cool to me!
You automatically have a backup of data because of the way this works
You’re not limited by the resources inside your own hardware
Does this mean that every remote Qube would be an HVM?
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.
So what’s all the fuss about this “cloud” thing?
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:
Use each other’s stuff (including fibre optic cables laid around the planet that carry our internet)
…while still…
Keeping our own little bubble untainted
…and…
Making sure that outsiders only enter that bubble on YOUR terms
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.
Dom0 could still be run locally or remotely, or there could be multiple dom0s
If Dom0 was run remotely, there would still need to be something run locally to actually get your machine to turn on
Because of this, it wouldn’t really make sense to run a dom0 remotely, however it could be done
At the end of the day, for your computer to function, there needs to be a user/domain that can see and do everything on your machine. That is currently dom0.
An AdminVM would not replace dom0 (wherever that dom0 may be, local or remote). It would provide a way to interact with the dom0.
Because of this, it may not be necessary to allow the local user access to a remote dom0. This would allow Qubes-as-a-service to be a thing.
This does not mean that it is the only way that Qubes-Air could exist. If you hosted the entire thing yourself, then you would be the one with access to dom0.
If you were given only a remote AdminVM, then you’d still need your own local dom0 to actually boot your own machine, and you would likely treat this AdminVM as another one of your VMs.
There is no operational reason why either setup could be done, or why one setup was “better” than the other. They both have their advantages and disadvantages.
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…
Actually, under 4. and 5. I already knew a lot before, and that was exactly the reason why I asked under 1.
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.
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.
. This is awesome!