The point was that the keyword “sufficient” introduces unman’s argument a degree of subjectivity that he can always fall backdown to. “I said SUFFICIENT [blahblahblah] and that sufficient amount enables some stuff to happen”.
Cheese is also a material, and we don’t know what “sufficient” mean to you in your example. I don’t have a way to measure it. Maybe you, or unman, was talking about practiically infinite sufficiency of cheese that allows you to construct a cheese-stairway to the moon.
Whatever, the whole thing around “SUFFICIENT TRAFFIC NULLIFIES TOR” is unfalsifiable, because of the word “sufficient” introducing a degree of non-measurable subjectivity. Such an argumentation shouldn’t be used for degrading the users’ desire to use sys-whonix for CHECKING AND DOWNLOADING (for christ’s sakes!) the updates.
No, the statement could be true or false even if the amount of traffic is never specified. For example, if it were to turn out that no amount of traffic is sufficient, then the statement would simply be false without any need to specify a quantity of traffic.
Perhaps the question that’s important to you is whether such an attack is realistic or not. If the amount of traffic required is something that an adversary could gather in a week, a month, or even a year, then the attack may be a relevant concern. But if, on the other hand, the amount of traffic would require millions of years worth of normal usage, then the attack would be impractical.
It’s not that the word “sufficient” is subjective. Rather, it’s unspecific. It merely says that there exists some threshold value that counts as enough. Either such a threshold exists, or it does not. But if the threshold is high enough, you may not care that it exists.
The point is that no amount of cheese alone can get me to the moon. Even with an infinite amount of cheese, I don’t think I can construct a cheese stairway that will get me to the moon. (For one thing, cheese by itself probably doesn’t have the structural integrity to maintain such a large construction. For another thing, cheese alone wouldn’t allow me to breathe after I leave the atmosphere.)
It’s not that “sufficient” has some meaning for me that might be different from its meaning for you. It’s not subjective in that way. Either there exists some minimum quantity of cheese that satisfies the requirement, or there doesn’t. You can’t measure “sufficient,” because “sufficient” isn’t itself the sort of thing that can be measured. It’s a category mistake.
It’s like saying “largest” is subjective and can’t be measured. It’s not subjective if we’re talking about physical objects under ordinary conditions. We can’t measure it because it’s not the sort of thing you can measure. You can measure the largest object in a given collection of objects, but you can’t measure “largest” itself.
This is not exactly true. If I have infinite cheese, I could, eventually, earn enough money to buy a trip to the moon.
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.
Coming back from general Tor discussion to OP’s question:
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.
Are there historical reasons for this decision? In my opinion this is disadvantageous from security, privacy and maintainance perspective due to leak potential, as illustrated. This model is also harder to understand for users, which need to be aware of conditions, under which one or the other route is taken. (There definitely is some room for community to contribute better documentation, too.)
What about this idea:
An AppVM qube A with parent template T should just trigger an update check request via qrexec (default: 5 minutes after qube startup), it should not consult its own NetVM. dom0 then starts T in order to actually do the update check. T is fully responsible for its update source/network. Per default it just takes the (global) Qubes update proxy, as templates usually don’t have NetVMs assigned.
Advantages:
Unambigious update channel, easy to understand
Get automatic update checks for templates of offline qubes as well.
Update traffic network source (check + download) can be configured by single global setting under Updates → Update proxy → Default update proxy , e.g. sys-whonix for Tor updates
Would be curious, how much effort this change would require.
Yep, checking for updates from template seems definitely better than from app qube.
So for now we could disable qube updates (+ have a setting to enforce this for new qubes) and do checks manually with template.
It then would be good to automate this update check for templates, either periodically (that might be scripted by cron, systemd, etc.) or - what I like with current approach - triggered some time after corresponding app qube has been started. Latter basically is the idea I tried to describe.
I really enjoy discussions about cheese space elevators, but talking about realistic approaches:
Making an option to disable updates for all qubes including new is the most cost-efficient way of solving this problem, I believe. Combined with more straightforward explanation of how updates over TOR actually work.
, but it doesn’t create an output. There doesn’t seem to exist a toggle in qube settings either.
And follow-up question: Given “Enable checking for updates for all existing qubes” is the active choice in Global config, is clicking on “Enable checking for updates for all existing qubes” followed by re-clicking on “Enable checking for updates for all existing qubes” a workaround to disable all qube auto update checks?
If yes, a workaround would be to toggle this setting manually each time a new qube is created.
To answer own question: This service has no explicit value on a vanilla system (qvm-service does not return any value). The implicit default is to enable update checks for each qube, despite no value given.
should disable all qubes from update checks again.
Qubes Global Config → Updates → Check for qube updates → Disable checking for updates for all existing qubes will add an explicit qubes-update-check service entry for all qubes with the value off (unchecked).
To look up current qube setting, either
qvm-service myqube qubes-update-check
or go to Qube settings → Services and look for this entry. Both ways are equivalent, former is the CLI way.
Adding exceptions for globally disabled update checks via Qubes Global Config somehow did not work (Apply took long time, and had no effect). What I did was then to manually go to Qube settings and re-check the qubes-update-check service.
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.
It’s not useless; it just doesn’t answer the specific question you’re currently interested in.
Already explained above:
Yes, already explained in the issue linked above:
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.
It would be a flaw to assume that privacy and security are mutually exclusive, even from historical standpoint. We already could read sad stories in this thread. A privacy leak does mean more information available for a potential attacker and bigger attack surface, if you will.
Yes, it doesn’t answer to any relevant question for me and for the OP’s problem, which is exactly what I meant by “useless” in my comment.
Cheese is expensive!
According to ChatGPT (), the cheese industry’s value is about $100 billion. Let’s say, you could get 1% of that if you have infinite cheese. About $1 million is the price to go to space as a tourist. If you expect that going to the Moon would be a couple of orders of magnitude more expensive, then you should still be able to get there with the infinite cheese.
This is just another proof for you that the relative statements are useless for actual applications without actual numbers, like the one by @unman.
The name of the Issue looks a bit strange to me. It looks as if the users are the problem and not the wording of the options
this is an issue that comes from a misunderstanding of a badly explained feature/process, so it could be seen as both (user problem or UX problem) depending your side
I think you are missing the point, because I was not clear. The initial
traffic analysis is performed on a larg(ish) corpus of data, including
Tor, Qubes and Whonix-Qubes data. To achieve a good FPR in identifying
Whonix-Qubes it is sufficient to monitor user data for 6-8 hours. If a
worse FPR is acceptable, (and presumably repressive monitors will settle
for that), then a shorter monitoring period will do.
Note that all I am talking about here is identifying Whonix-Qubes users,
not “breaking anonymity”, and it assumes that some entity is able to
monitor traffic upstream from sys-net, whether at ISP or VPN provider.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I think tor has a padding option to add randomness to packet size and delay, isn’t it helping?
In addition, playing a stream audio or video in background (with a variable bitrate) should make fingerprinting a lot harder? (it’s not a statement, just an idea)