Qubes-Air? Qubes in the cloud?

That’s a quite a narrow view, and is wrong. It’s not only about whether my system is secure and doesn’t leaks data. I’m/you’re not alone on this planet. If your contacts, or mine, doesn’t have the knowledge or willingness to secure their systems, or thoughtlessly put everything in the cloud because it’s so convenient, then it impacts yours/my security and/or privacy.

It seems to me that you advocate the notion that everybody who uses a computer has to be some sort of IT engineer (I might misinterpret you there). Following that logic that would mean that if you want to drive a car you have to be at least a car mechanic. Try to imagine what that would mean if everybody would have to study first before being allowed to use some sort of device.

For the vast majority of users the computer is just a tool; a device to do something they have to do or want to do. It’s not their passion or toy…

Therefore an OS provider has to take that into consideration and act accordingly. The provider could state this OS is only for advanced users, preferable IT professionals, suitable. But Qubes OS’s target group are average users, specifically are mentioned journalist, whistleblowers, activists…

1 Like

I fully agree with you here. I actually did not suggest that everyone must be a computer guru. I just don’t think that having an option for cloud forces anyone to use it and give up their freedom. As long as there are other options (including not using any cloud at all!), I find it’s fine and not interfering with our freedom. Some people will prefer to use a cloud and (I expect) many businesses will create their own Qubes cloud making Qubes a more popular OS. It’s a win-win situation. I don’t see why you are complaining.

Like ADW pointed out, those of us who have a well justified aversion to
the cloud (other peoples computers) don’t have to use it that way. I too
was shocked for a minute there, but I kept reading … :wink:

However the above quoted scenario has me giddy with anticipation: I
can’t wait to have my vault qube holding my keys and password manager
run on a USB Armory which I can keep physically on my person at all times.

I also very much like the idea of having PI’s be specialized qubes that
keep running even if I shutdown my PC.

/Sven

2 Likes

I fully agree with you here. I actually did not suggest that
everyone must be a computer guru.

Dito

I just don’t think that having an /option/ for cloud forces anyone
to use it and give up their freedom. As long as there are other
options (including not using any cloud at all!),

Agreed. However, where I agree with the OP is that unless you manage the
cloud yourself or someone you trust fully does it for you, it introduces
huge risks that non-geeks might have a hard time recognizing.

I find it’s fine and not interfering with our freedom. Some people
will prefer to use a cloud and (I expect) many businesses will create
their own Qubes cloud making Qubes a more popular OS. It’s a win-win
situation.

That’s exactly where the Qubes name might get watered down to
meaninglessness. That’s the worry from my perspective.

I don’t see why you are complaining.

I think I do. The core issue is: how to enable non-geeks to use Qubes.

Qubes Air is one approach and while I see cool use cases for geeks (see
my other post in this thread) that have me excited, I worry that
(non-self-)hosted Qubes instances introduce the potential of many bad
actors and I don’t see how this can be addressed by software. To me
that’s the point the OP is making.

The other approach are certified fully-owner controlled PCs and that’s
where things get really complicated and technical. I understand there
are at least two providers now offering ME-cleaned pre-installed Qubes
laptops and that’s one way a non-technical person could go.

But the basic issue remains that there is no fully open-source and
owner-controlled hardware. Personally I am hoping at some point in the
future we will have such (probably ARM-based) hardware and that Qubes
can be installed on them just as easy as one installs let’s say Windows
on a Lenovo PC. But that’s just a dream at this point …

/Sven

1 Like

So did I…I read all of them twice… :wink:

Exactly.

Another option would be that the Qubes OS team expands a bit to bundle laptop and Qubes OS. That would be then a certified system, and would create an income stream for the project as a whole.

The current Qubes team has already the expertise to pick one or maybe two laptops on which Qubes OS would run just fine. Everything open source except the hardware that wouldn’t be possible at this point; except maybe the firmware if Coreboot gets used. Furthermore everything should be fully documented. I’m not trying to indirectly say that the current documentation is bad, quite the opposite: It’s very good, except the part of the future direction and goals.

I would consider that a much cleaner and honest way to solve the funding problem of the project, and it wouldn’t introduce all the problems mentioned here.

Open source doesn’t mean free beer. :wink:

Let me get this straight. You’re accusing the Qubes OS Project of being dishonest and insinuating that we’re trying to sell out our users for money, and your evidence for this consists of a series of articles, the first two of which do not support your claim, (because you’re pulling quotations out of context, as we’ve repeatedly explained), and the latter two of which are about a completely different project? You do realize that Joanna is no longer active here, much less leading this project, right? It’s a mistake for you to interpret her work on completely different projects as an indication of where Qubes will go.

I’m starting to see a pattern here.

So you know that you’re misinterpreting things, but you intentionally do so anyway. Isn’t that the very definition of trolling?

Different projects, yes, but they collaborate. Document four mentioned 5 times; Document 3 third last paragraph:

(…)while Marek Marczykowski-Górecki (Qubes OS, Invisible Things Lab) and his team are building the first version of the protocol, using Joanna’s model as a reference. (…)

Document 2 last paragraph:

(…) Finally, decoupling support for VNC and other remote desktop capabilities opens the door to various server-based solutions in which Qubes can run on a remote server, and we can delegate some or all of our domains to other machines (potentially with faster harder and more resources). This is a another step toward Qubes Air.

Document 1 I quoted already.

I didn’t pull anything out of context everything is listed. On the other hand you do. In regard of accusing me to accuse the Qubes OS Project: I said it’s shady, and yes I find it dishonest not to state clearly that Qubes OS is part of a bigger project, which will include “economic framework” (Document 4 chapter 1.4 and 3.3). I do not said that the Qubes OS project intentionally did hide that fact, but I pointed it out to, so I hopped, get clear answer. Instead it’s denial, also the papers clear document it.
Again, I don’t see anything wrong with monetization as long as it is clearly pronounced. But that can still be done, right?

[quote=“adw, post:27, topic:921”]
I’m starting to see a pattern here.

Ah right, if arguments are missing the trolling argument comes up. Not very constructive…
My response to your quote: “Of course…” was sarcasm…I thought that was clear.

Constructive would be that the Qubes OS project makes a statement about monetization and how they see the future. Maybe some kind of social contract or manifesto. Something like this…maybe… :wink:

What exactly do you mean by “collaborate”?

I haven’t even had time to read those documents (since, again, they’re from a completely different project than the one I work on), but now I will.

Sure, but we already addressed this above. Support for some new capability does not mean you lose anything.

Sure you did:

You quoted that statement about “Qubes-as-a-Service” outside of the context that clarifies that it’s completely optional and wouldn’t prevent us from continuing to use Qubes on our own hardware, then used that quotation to draw the opposite conclusion of what the article actually says.

Where?

That’s news to me. As I mentioned, I haven’t had a chance to read that yet, but I will now. If the direction of the project has changed, no one told me. Anyway, that would be up to @marmarek to decide, not any other project. (However, since Qubes is open-source software, someone else could fork it if they wanted to.)

(Side note: Why can’t a denial be a clear answer? If someone asks you, “Did you steal my watch?” If you say “No,” that’s a denial, but it’s also a clear answer.)

Sure, of course. But, again, you seem to be thinking that Qubes will somehow herd current users into some cloud model, then charge them money for it when the switching costs are too high. As someone who has been working on this project of years, I’ve seen no evidence of that, and as someone who has been a Qubes users for even longer, I would be strongly against it.

I think you know that this wasn’t a substitute for an argument. We already advanced many clear arguments above.

Moderating your combative tone and inflammatory accusations based on flimsy evidence is certainly constructive. It helps to limit the spread of misinformation and maintains standards of discussion for the forum.

On the other hand, when someone takes the time to write out a sincere reply to your concerns, and you respond with a sarcastic remark, that’s generally not very constructive. At the very least, it’s not likely to garner any good will.

If this is what you were seeking all along, I think you would have had better luck simply asking for it in a calm, civil way in the first place.

2 Likes

This is the only mention of Qubes I could find in Document 3 (link).

Maybe the problem here is that you’re assuming “Invisible Things Lab = The Qubes OS Project” or that anything @marmarek works on is thereby directly associated with the Qubes OS Project.

  • Invisible Things Lab (ITL) and the Qubes OS Project are separate entities.
  • ITL is a private company, whereas the Qubes OS Project is an open-source software project.
  • ITL works on things other than Qubes.
  • In addition to being the Project Lead for the Qubes OS Project, @marmarek is also the Chief Technology Officer of ITL.
  • As a member of ITL, @marmarek may work on things for ITL that are not associated with Qubes.

This means we should not assume anything – merely on the basis of @marmarek’s involvement – about the relationship between The Qubes OS Project and Golem or Wildland. Instead, we should simply ask.

I’m happy to report that Document 4 (link) is not about Qubes at all. Qubes is mentioned only once in the body text and not in relation to any “economic model.” In fact, Qubes is mentioned just as an example of a “security-hardened system”:

In some more niche, but security-critical scenarios, we can also think of special security-hardened
systems or devices, devised as terminals for secure access and management of Wildland containers.
For example, it is tempting to consider security-hardened systems, such as Qubes OS [12] in this
context.4

And here’s that footnote 4:

4 Qubes OS has been, in fact, promoting thinking about its “qubes” (or VMs) as data-focused containers, rather than code-focused “microservices” for many years. Admittedly, this might not be entirely a complete coincidence. . . :wink:

Wow…In the 29th post you actually going to read what I was talking about. Nice…you should have taken the time…not trying to understand what the OP writing about is quite disrespectful…

The 3rd post wasn’t combative at all. If you had read the documents (in chronological order; that’s why I numbered the list) from which I quoted then we probably could have avoided half of the posts in this thread.

Maybe, but I started that whole thread with a question, because and that point I wanted to figure out whether that is known or not. It wasn’t. Now it is. Furthermore the way I did then (3rd post) revealed much more.

So you took about 30 minutes to read the documents. That’s fast…so you just skimmed / scanned the documents (yesterday 6:31 arrival post 29; yesterday 7:09 arrival post 30). Nah…at least you had a quick look.

The End.

Thank God!

4 Likes

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.

5 Likes

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.

1 Like

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.

5 Likes

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.

4 Likes

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…

2 Likes

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.