How to hide the fact that I'm Qubes OS from Telegram

I’ve done some troubleshooting between Qubes (Fedora/Debian) and Whonix, and I can report that I know where it’s coming from, and it’s not a Qubes problem at all. For some reason, Whonix has set the $XDG_CURRENT_DESKTOP env to X-QUBES where classic Fedora/Debian qubes set it to XFCE (which is how they appear in telegram too).

This means that the solution to this is to simply set the variable to XFCE (/rw/config/rc.local):

echo "XDG_CURRENT_DESKTOP=XFCE" >> /etc/environment
2 Likes

I’ll check it out.

If you have more time, I was asking one person on the forum about changing the system identifier and he sent me this information.

The first thing he told me was to look at this file and this lib and what this file does and how this lib gets the data
tdesktop/Telegram/SourceFiles/boxes/sessions_box.cpp at 3adbfb1fb50695702c041cb3384582b64091e803 · telegramdesktop/tdesktop · GitHub
lib_base/base/platform/linux/base_info_linux.cpp at f69758da1906b204c156ea6ad254eacd61210a42 · desktop-app/lib_base · GitHub

Then he provided me with this - cat /sys/class/dmi/id/*
And said that this way I’d figure out where the data from the telegram session was coming from

Then he said to look over here

Then this
https://github.com/search?q=repo%3Axen-project%2Fxen%20bios&type=code

And then this and compare the search query to this
https://github.com/search?q=repo%3Axen-project%2Fxen+bios_vendor&type=code
and see what’s in the folder:
ls -lh /sys/class/dmi/id
cat /sys/class/dmi/id/bios_vendor

Then go to this

And the last thing he sent me was this

I don’t know how to read code and don’t understand anything about it, maybe someone here understands it and will watch all this and say something interesting.

No, it’s not, I have Debian saying X-QUBES too

I had already changed it with my tests while writing and forgot. Only Fedora returns XFCE by default. Anyway, it’s not a problem if Debian returns something else, since it’s not used for any privacy related activities.

For your other post, I don’t see the point of changing this information, what you want to achieve here is to hide Qubes, not the hypervisor itself.

Yes, it’s a big problem, the hypervisor shows in telegram too

Xen is not related to Qubes at all. It’s used by many people and companies around the world. What’s less used here are Qubes modifications and applications, which is something completely different.

1 Like

That’s right, what about this old shit: GitHub - isbheis/seabios-antivm: qemu antivm part for default seabios, remove all signatures about qemu, virtio, kvm, xen, seabios .etc
It’s still possible remove all signatures if the Qubes developers wanted it, isn’t it?

Again, Qubes is not privacy/anonymity oriented, it is security oriented. Changing this is useless from a security standpoint. So there is no reason for developers to waste time hiding the hypervisor.

1 Like

There can be no security without privacy and anonymity. But I understand you, maybe someone wants to hide these identifiers (like me), but not all coders and can do it themselves.

1 Like

Privacy/Anonymity adds up on top of security.
Qubes provides security.
Whonix provides a better level of privacy/anonymity on top of what Qubes provides by default.
I understand what you want, but Whonix is not Qubes and there are things they can’t do without breaking things for everyone.

1 Like

Anyway thank you for helping, maybe someone else here will post an interesting opinion about all this

1 Like
4 Likes

How do you figure that? Imagine a perfectly secure transparent box. It’s impossible to break into the box from the outside, but everyone outside the box can see everything that happens inside the box. It’s perfectly secure but not at all private. Now imagine the equivalent for a computing system. Everything that happens on the system is visible to everyone, but no one can compromise the system or exert any kind of unauthorized control over it. Again, perfectly secure, but not at all private.

(Before anyone says, “But perfect security is impossible,” please understand that this is a purely conceptual argument. The claim under consideration is, “There can be no security without privacy and anonymity.” That is a conceptual claim about the relationship between security and privacy. The thought experiments above are intended to provide counterexamples.)

3 Likes

I wouldn’t use tor to log in with any account of mine that matters. I wouldn’t use tor to log in at all if it’s possible.

well its too late now. But what i’m suggesting is what you could have done. If u didnt want to download the telegram app on your phone, you could have downloaded it on an android vm. Anytime you sign up on browser, you could use the app on the vm to sign in instead of relying on a sms enabled phone.

Anyhow, there litereally isnt anything u can do about it now other than making a new tg account

how is trusting web.telegram.org different than trusting the APKs they signed?

1 Like

The APK signed by telegram and served by Google Play can’t be used for targeted attack since the same APK will be served to everyone and someone will verify the APK since it should support reproducible builds:

For desktop client - it could be used for targeted attack since you can’t verify them. But you can install the telegram desktop from your OS repository and avoid possible targeted attack.
But for web page it’s very easy for them to serve malicious javascript to a specific person for a specific session and it’s much more harder to catch them doing it.

3 Likes

interesting…

The feature you’re looking for and detailed reasoning why this cannot be implemented has been documented just now:

4 Likes

When you use desktop Telegram in Tails it sees all your real hardware information. Does it? But now, thinking about amount of people using Qubes + Whonix + Telegram, I already don’t know what’s better. :face_with_diagonal_mouth: