Unfortunately this GUI not shown during install time, I’d say “it’s too late” once you opened the Global config GUI
3 Likes
This issue has been discussed at length in the past, and I continue to
be baffled.
I still fail to understand what gives rise to the “shock and
confusion”. I could understand that if you ran all your qube traffic
through Tor but saw update checks running outwith Tor. But that isnt
what is happening.
You choose to run qubes with traffic not going through Tor. Why are you
surprised that update checks do not go through Tor? (Automatic check
for updates are not a specific feature of Qubes - they are available
in many distros and OS.)
I’ve asked about this before and not got a convincing reply. Any one
able to fill that gap? (I understand that the UI should be clearer.)
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
In Qubes settings it says “Check for qubes updates”, you then check the box to automatically check for updates.
Below it, it says “Update proxy”, you are then instructed that updates will be downloaded over VPN/Tor if you pick such a qube.
When an update is downloaded, the repo is queried using VPN/Tor.
It is then easy to make the conclusion that scheduled checking for updates will also be done over VPN/Tor.
Why?
Because enabling a setting in Qubes settings makes it look like a special Qubes OS feature.
It seems like many people have come to the same conclusion, that Updates proxy will do the update checking and that this is a special Qubes OS feature.
I don’t see any other settings in Qubes Global Config that are not Qubes specific. This further creates the illusion of a Qubes OS feature, rather than an in operating system setting.
It is implied but never made clear in words, that networked qubes will use their own NetVM to check for updates while they are running and not the Updates proxy.
I hope this explains why:
- Many people make the assumption that this is a feature of Qubes OS - “route updates & update checking over VPN/Tor”.
- It is unclear that this modifies the template, and does not apply a setting from the “dom0 side of things”.
3 Likes
But why would someone who needs everything to go through Tor, not have Whonix as the netVM for all qubes?
1 Like
Since upgrades happen only in the templates (or standalones), it’s natural to assume that only these vms check for updates. Template based app qubes have no apparent need to check for updates because an upgrade of the app qube would not persist. So a choice of sys-whonix as the net-vm for updates reasonably indicates an intention that all update traffic be torrified. Understanding that this is not the case would require a close reading of the Qubes documentation, which is probably not very common. A clearer UI would prevent this mismatch between expectation and reality.
4 Likes
All of this was discussed thoroughly in the past. As I can reacll that is how we got update GUI window in v4.2.
But, I think what is overlooked here is that Qubes OS (meaning the devs) is not about anonymity, but about security. So, it’s your full responsibility to provide yourself with anonymity under Qubes, as under any other OS. Nobody related to Qubes promised anonymity ever.
Yeah, I’m still surprised when there appear guys who tries to use Qubes for games. 
But let’s be honest: who often needs security? Those who also needs anonimity. Qubes devs understood this well so that’s why they implemented Whonix support. But this is on their side - to make this integration well. Pool of users, who heed anonimity and security, has its own few, small needs. One of this needs is to know that Qubes OS doesn’t signal the ISP about its exisctance without user’s ecknowladge.
Only don’t say that devs developed Qubes not for anonimity. Saying this is like saying: “We developed a body armor, but it’s not for combats! Only for protection!”
I’d still rather encourage people to read quoted topic. I didn’t come to Qubes by coincidence, and more important, didn’t start to use it before I virtually dragged it through my threat model. I am clearly remembering I was preparing myself to use it for a way more than a year. During the time I read, and studied, then asked everything of an interest to my threat model, waited for some features to be implemented, and so on, and so on, eventually becoming so confident that I could allow myself even to experiment with it in so many different ways.
So, to conclude, when you’re buying “body armor” you’re the one to get the proper one for your “combat model”.
Not necessarily. If you’re not connected to the network on firstboot, then you can change this setting before any qube has a chance to check for updates. But I agree that the situation can be improved, hence #9406.
Please feel free to open another enhancement request for exposing this option in the installer too.
In general, a machine can’t check for updates unless it’s powered on. This also applies to templates. They can’t check for updates unless they’re running. But they’re usually not running, except when they’re being updated (or you’re installing software in them or customizing them). So, if only templates (and not template-based qubes) checked for updates, you’d probably never find you need to update until you actually try to update. In other words, update checking would become useless.
I think the confusion stems from conflating updates with update checks. You’re correct that template-based qubes generally don’t need to be updated themselves, but they’re usually the only ones running, so they’re usually the only ones who are able to check for updates (at least in a timely fashion and on a sufficiently regular basis).
That’s like saying, “What’s the point of bulletproof glass? After all, if you want something to be impervious to bullets, you certainly don’t want anyone to be able to see through it.”
That doesn’t follow, because security and privacy are distinct concepts that can come apart. Sometimes you want security. Sometimes you want privacy. Sometimes you want both.
This option should definitely be exposed in the installer. Not too long ago a friend of mine who is a journalist in a totalitarian country started using qubes os. Within the same week of this transition from Windows → Qubes, his home was raided and all his devices were seized. At the time we assumed that he had improperly set up his vpn or something of that sort when he set up his vpn → tor connection as he wanted to hide his tor usage from his ISP.
In hindsight, there is a big possibility that the ISP simply detected him using a nonstandard operating system due to qubes phoning home. And therefore this is the cause of him being raided.
Exposing the settings to not reveal qubes os usage to an ISP would be a great enhancement in the installer. Could save lives.
Grapheneos at the very least has documentation on how to hide grapheneos usage which is to turn their connectivity checks to “Off” or “Google” which is the default for android devices. This combined with vpn usage which updates go through, is enough to hide grapheneos usage from an ISP. If efforts aren’t made to include an enhancement in the installer, at the very least, the documentation should cover how a user can hide qubes os usage from their ISP, similar to how grapheneos does.
Head Dev of Whonix adrelanos opened a ticket for this a few years ago I believe, but no update on this from the qubes end…
3 Likes
If your friend’s life depends on the government not knowing he uses Qubes OS, why did he then specifically configure his qubes to connect to the internet without Tor?
The entire argument is just nonsensical, his qubes doesn’t just check for updates via clearnet, they are making all connections via clearnet.
There is nothing special about the update check, if the netVM is sys-net or sys-firewall everything including the update check is going through clearnet.
Even if the update-proxy was changed, it would do very little to protect your friend, seeing how he configure his qubes to not use Tor.
His qubes were set like this. sys net- > sys firewall → VPN qube → Sys whonix → Whonix workstation.
We don’t believe there was a leak from whonix workstation. We think that Qubes usage was simply detected either through updates or pings home from sys net. or sys firewall. The point is that even if whonix workstation updates were properly going through tor, if qubes OS usage is detected, then that is a problem for some users.
The main point being that many users think that updating thru sys whonix is a privacy feature that works to hide qubes os usage from their ISP.
Evidently, as explained by ADW, the feature wasn’t meant to be a privacy feature but rather a security feature. Regardless, of this, it is still useful for certain qubes OS users to be able to hide qubes os usage from their isp and seeing as many others who are also using the update through sys whonix feature believed that this was the case when selecting the option in the installer, I believe that an enhancement should be made for all update checks to go through sys whonix along with the ability to eliminate all calls home or any similar clearnet calls that could indicate to an ISP that ‘x’ user is qubes user. Adrelanos also has asked for a way to disable clearnet connections (For different privacy reasons) but nonetheless, it would benefit both sides.
2 Likes
In my case, I have debian qubes, which I use with clearnet. However, I want their update checks + update downloads to go through sys-whonix. QubesOS global config UI has lead me to believe that this is what it was doing and that’s why I got “surprised and shocked”.
2 Likes
It is fascinating that such splitting hairs is being labeled as “conflating” in part of the user. To the normal user, there is only UPDATES. There is no “conflation”.
5 Likes
This makes sense.
Because before I chose an update-proxy. And I knew that AppVM qubes don’t do updates anyway.
So I expected to be able to use AppVM as a regular linux distro over clearnet/VPN, while check and download (including qubes-specific) updates over chosen update-proxy through TOR.
As I said, this makes sense. But let’s not pretend that majority of Qubes userbase are not paranoids of different degrees. Looking at the replies at this topic, ability to check for updates through TOR is a pretty anticipated feature.
If it’s not realistically feasible or still makes no sense for developers, I propose as an easily implemented mitigation to make an option to disable update checks for all qubes including new qubes (if not making this default option when choosing disabling updates checks for all qubes). Because if users, who need this, will have to manually delete every new qube from the list of exceptions, they are doomed to fail at some point.
Then it would be possible for users to make some qubes-exceptions with Whonix as NetVM to check for updates, or do it manually running TemplateVM’s, or whatever they prefer.
And as it was said before, it would be nice to make it all more clear, because I am certainly not the only one who had this misconception.
3 Likes
Actually it could be great to sequentially start templates to check for updates once in a while instead of doing it in AppVM.
If you use N AppVM using the same templates, you will check N times for updates which wastes a lot of bandwidth.
If you have AppVM using a template but you not start them often, the next time you will start them they will certainly run out of date software, potentially vulnerable. if they find updates, the user need to trigger the update, and you will have to restart that AppVM, this can take a while and expose the user in some cases.
While if templates were checking for updates and updating if possible on a regular basis, this would improve security of qubes and everything would go through update proxies, making everyone happy.
2 Likes
If it’s so hard to add qubes-update-check service in the Service tab of a template’s Settings, and then uncheck it (which disables update check), then I am baffled how is that more complicated then using (switching to) Qubes?
Update checks are not done over clearnet or tor, but when the qube is online. If it’s online via sys-firewal, then it’s clear net, if it’s online via sys-whonix, it’s via tor (even this is not strictly correct, because clearnet is anything that is not .onion)
Isn’t this what the “Additional Update Check” in the Qubes OS Updater Settings does? It attempts to update qubes after n days without checking for updates. And it starts the template vm (not the app vm) to check for updates in a template.
I forgot about this feature, although now I’m checking it, it is set to 5 days for me but I have a qube in the list (it’s not a template) that was last checked/updated in May.
I usually force all my templates to update by checking them in the update, so I’m not sure this works even for templates. If someone could take a look at their setup, this may shed some light.