Updates check over clearnet instead of sys-whonix and other strange decisions

[adw]

@fsflover

@adw

The point is that no amount of cheese alone can get me to the moon.

This is not exactly true. If I have infinite cheese, I could, eventually, earn enough money to buy a trip to the moon.

Then you’re no longer using cheese alone to get to the moon. You’re using a rocket ship.

Besides, price is determined by supply and demand. If I start dumping huge quantities of cheese on the market, that’s going to tank the price. “Just sell small amounts at a time so you don’t tank the price,” you might say. Sure, but that’ll take a lot longer, and my lifespan is finite, so it’s not obvious that I can earn enough by selling cheese to buy a trip to the moon before I kick the bucket.

@fsflover

@adw

Perhaps the question that’s important to you is whether such an attack is realistic or not.

This is exactly the problem with @unman’s statement. Even if one week of traffic analysis is sufficient, the user could still enjoy anonymity for a couple of days. So without any exact quantity it’s useless.

It’s not useless; it just doesn’t answer the specific question you’re currently interested in.

@gabaz

I don’t quite understand, why it would make sense to possibly have two different internet routes to update Qubes software - one is the AppVM qube’s netVM, the other one is the global update proxy. What has the AppVM to do with updates? Updates only persist in the template.

Already explained above:

Updates check over clearnet instead of sys-whonix and other strange decisions

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 ru…

@gabaz

Are there historical reasons for this decision?

Yes, already explained in the issue linked above:

Updates check over clearnet instead of sys-whonix and other strange decisions

Please feel free to open a bug report for this (if one doesn’t already exist). It already does inform the user. In the screenshot below, it’s a red box containing a “red shield with exclamation point” icon next to text stating that it applies only to existing qubes and that new qubes will have update checking enabled by default: [image] (However, I’ve noted a problem with this.) Probably because no one has opened an issue for it yet. I search…

Some users think that enabling updates over Tor in the installer will route all update checks over Tor

Specifically, this part:

Part of the reason some users have this mistaken expectation is because they believe that the only purpose of routing updates over Tor is for privacy (e.g., trying to hide the fact that they’re using Qubes OS from their ISP, government, or others). From their perspective, it makes no sense to route updates over Tor while routing update checks over clearnet. They’re not aware that there are specific security benefits to updating over Tor independent of any privacy benefits and that running update checks over clearnet doesn’t detract from these security benefits. They’re not aware that these security benefits (and not any purported privacy benefits) were the primary motivation for the implementation of this feature, which is why it currently works the way it does. If the current behavior isn’t changed, then the software UX and documentation should be updated to help users to understand why it’s implemented this way and thereby better set users’ expectations.