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

Exactly. A nice UI improvement when selecting sys-whonix for updates would be to explicitly list the checks that will still happen in the clear with an option to disable (along with a warning of the downsides). This would help match expectation with intention and help make the tradeoff easy to implement for the user. An additional column in qubes-manager with a tick box for update checks would also be handy.

I do all of this manually already, but routinely check for updates through the template. Allowing only whonix app vms to automatically check for updates provides a reliable enough signal for me (since I rarely use Fedora).

1 Like

When I start my computer, from the very first time.
When I login into my account. Qubes 4.2.2 starts with WiFi adapter turned on. Looking for connection.
When qubes starts, the WiFi connection always starts as turned on.
Without my doing anything.
WiFi will automatically connect to an open, unencrypted connection if Qubes WiFi adapter sees one.
Or If I have previously used an encrypted connection, like my own home router, and have entered the password. It will connect there.
A start of qubes can start with a connection, ON, to my own, encrypted home router.

I lived for a long time without home internet. When I started my laptop that used qubes, somehow qubes said it needed to accomplish an update.
Windows is infamous, IMO, for getting updates from others nearby computers, even if I have not agreed they are part of my home Network. Maybe that has changed, but.

You might also consider to reset the DNS, (Domain Name Server) inside sys-net, sys-firewall to be encrypted DNS. and I guess, one outside the country.

A long time ago, someone was talking to a fellow who did Network things. Or should I say, the friend installed, updated servers. Ordinary user was telling his friend, the networking guy, he saved and used the specific numbered IP address instead of using using a DNS lookup service. The Network specialist laughed and said, If you use my server, my ISP, whatever IP number you sent me, I can sent you wherever I choose on the internet,

Personally, I am supposing from that, our internet security relies on the browser certificates, and the encryption that comes with them.

You should not trust me, I am not an Networking person. I am sorta spreading rumors.

There are dongles that have a VPN pre built into them, unless those same dongles have been altered by the local government structure. then again, how much can you trust any VPN? Rumors of those who do not trust Tor are around. I am not competent to say. I am sure, Those guys who write, update Tor seem to know a great deal more technically than I do. They keep coming up with features, that when they describe the feature, sound like a great idea.

I see one can purchase some of the Qubes certified computers without a WiFI adapter inside. Guessing the user is planning on using a WiFi dongle later. My problem with that is, If I buy a WiFi dongle, carefully choosing the manufacturer/model chip inside. It comes on a slow boat from China, through my countries own package delivery system.

NitroKey, the company (I have no affiliation, no personal connection) sells a router that has some security features. and sells some other stuff that sounds interesting.

I thought some of this was peripherally interesting to the topic.

Likely, I am wrong… I am often wrong. and giving out of date information.

Anyway, if I was thinking of prevent my ISP from seeing I am using qubes. You could unplug your home router, but your qubes install, first time you start qubes, after the install (re-starting computer to desktop is really part of install) It will announce to all the local routers, hotspot connections. “Hi, I am your new neighbor.”

Those who break codes, from the old days, when it was still possible, used to say. Codes are usually broken in practice, not in theory.

That is, like in front line World War one. Stuff happens, Like an advance might yield a code book that is currently being used, and even the next code book to be used. When codebooks changed, one front-line enemy unit might not have then new codebook, and request messages be sent to them in the older code (giving a crib for the new one) and sometimes insist the message be “in the clear.” Meaning not encrypted at all.

Like, poor password protection. Sit in a coffee shop, enter your logins where others might be able to read what you did. Maybe use poorly chosen passwords. Like all those who used Fox Mulder’s password, “Trust No One”

“Conflation,” in this context, refers to erroneously treating two distinct concepts as one. Checking to see whether any updates are available for a piece of software is distinct from actually updating that software. It’s perhaps analogous to the difference between checking the balance in your bank account and actually withdrawing money from your bank account.

The original statement was:

Template based app qubes have no apparent need to check for updates because an upgrade of the app qube would not persist.

In a conventional operating system, there’s just one thing that checks for updates and, if available, updates. In Qubes OS, we have a special template system that separates the installing and updating of software (which happens in the template) from the running of software (which happens in the app qube).

The hidden assumption underlying the original statement is something like, “The thing that checks for updates also does the update.” That assumption is probably inherited from a mental model formed by long-term use of conventional operating systems, where it does apply. In that model, there’s no need to distinguish between updates and update checks. However, the architecture of Qubes OS is different, so the assumption does not apply.

+1.

5 Likes

Being able to hide the usage of qubes OS is a very important feature, especially for people women living in regimes where information is hard to access. Im currently living in Russia and I am scared that my door will be kicked down at any second because of my usage of Qubes OS. Please either allow users to disable all update checks (for future VMS as well) Or allow them to be forced through tor.

I think disabling update checks would be the easiest solution as long as you make sure it is possible for future VMs as well. Maybe even allow this in the installer before first boot?

5 Likes

I also concur and believe that even regardless of updates, Qubes OS should provide a way to hide the usage of Qubes from an ISP. This would work to keep users safe. As you guys know, even linux users were deemed as extremists by the NSA. Imagine what category Qubes users are in.

2 Likes

It is very difficult to hide the use of Qubes, and running update
checks/updates over Tor wont do it. The last time we checked this it
was relatively easy to fingerprint Qubes use given a sufficiently long
analysis period, and an ISP surely has that.

They will be forced through Tor if you use qubes through Tor. If you are
so concerned you should be doing that in any case.

One thing to do is to clone a stock template, remove the Qubes
repository definitions, and create a clearnet qube. That qube will
update in the clear, but only to normal repositories, so your traffic
will consist of somewhat normal use combined with Tor use. It’s simple
and effective in hiding Qubes update traffic - but not in “hiding” Qubes.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

1 Like

it looks like it’s not working for me, I opened an issue

1 Like

But as someone else pointed out, sys-net and sys-firewall can’t go through Tor, because sys-whonix goes through them. So, if sys-net and sys-firewall do update checks, those updates checks will necessarily be in the clear.

1 Like

Doing this over Tor (strictly) shouldn’t fingerprint the user as a QubesOS user, but as a Tor network user.

1 Like

Running over Tor is not a panacea - as I said, with sufficient traffic,
it is possible to fingerprint Qubes users in Tor traffic.

I never presume to speak for the Qubes team. When I comment in the Forum I speak for myself.

I thought that an earlier contribution specified blocking outbound
traffic from these qubes. I take this as a given for any one who wants
the level of privacy suggested in this thread.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

“with sufficient [INSERT-YOUR-QUALIFIER-HERE] it is possible to [INSERT-YOUR-SUPPOSITION-HERE].”

With sufficient “stuff”, anything is possible. Am I to stop using Tor just for because?

No one is suggesting that. Why would you think so?

I specifically referred to the case of an ISP who can monitor your
traffic. In that case, it is possible to identify a Qubes user from
Tor traffic, with a high level of certainty, after a relatively short
monitoring period. (The larger the corpus on which one can train models,
and this should not be an issue for an serious adversary, the better
the results will be.)

Note that the adversary already can identify Tor traffic, and the
analysis relies on features of a standard Qubes install, particularly
date and update checks. Running these through Tor does not prevent an
adversary at ISP level from identifying Qubes users from other Tor
users.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

To be fair, he said sufficient traffic, which is specific and well-defined in this context. Consider the difference between two statements:

  • With sufficient materials, I can get to the moon. (plausible)
  • With sufficient cheese, I can get to the moon. (implausible)

So, it’s not the case that every statement of the form, “With sufficient X, I can do Y” is vacuously true.

what if I have a vpn on my router?

if my qubes os device connects to my router which has a vpn installed. assuming no leaks, wouldn’t this hide my usage of qubes os?

or would an ISP still be able to somehow identify that I am using qubes os behind that vpn.

I ask because I know that an ISP can identify that a user is using tor even if they connect to a vpn first due to traffic analysis since tor has 512 bit cells. Not sure if theres anything that would be similar to this to identify a user is using qubes.

At first I wanted to argue, but then I suddenly realized:

With sufficient resources and determination (but definitely not with cheese only, thank you for that important clarification, @adw) it is possible to penetrate any system, including QubesOS.

I guess, there’s not much sense in using something that is not perfect (and will never become perfect) anyway :thinking:

1 Like

Because A does not equal B therefore A equals nothing? Logic doesn’t track here. If something is worthwhile, then even doing a little bit of that something is worthwhile. Ergo, reasonably secure is better than reasonably insecure.

1 Like

Consider the difference between two statements:

  • Using TOR generally considered a decent way for achieving some level of privacy, so it would be nice to be able to use it for hiding your use of mostly-security-but-many-users-expect-it-to-be-somewhat-privacy-focused OS, if you wish so, at least in some cases, despite being not perfect solution. (seems reasonable)

  • Having strong passwords is worthwhile, so having some strong passwords on your deeply exploited machine is somewhat worthwhile. (like eating apples, when you have a cancer).

So, it’s not the case that every statement of the form, “If something is worthwhile, then even doing a little bit of that something is worthwhile” is vacuously true.

That’s for sure. I call it sarcasm.

Summary

But actually I’m on the brink of installing Windows

Don’t allow the perfect to be the enemy of the good. In the real world, there are no perfect solutions. There are only best-available solutions.

1 Like