Depending on the Qubes Security Bulletin #37 (https://www.qubes-os.org/news/2018/01/11/qsb-37/) it should be theoretically possible to get information about the system and in long term also about the user behind qubes. Because as described in QSB #37 at '## All attacks are read-only', '## Only running VMs are vulnerable', '## Only running VMs are vulnerable' and especially (!) '## Disk encryption and screenlocker passwords are at risk', it is possible to identify someone using any OS (not only linux or a qubes distribution).

It is also reboot resistent.

Each qubes user (not only) does have an individual storage encrytion password.
This individual password alone helps to remember an attacker, if this user is known and the password already stolen. Even the same screenlocker password on dom0 can identify an user, if the password is known or probably what language the user is using, if the password is fetched in cleartext.

The statement in QSB, that to make use of a stolen secret, the attacker would have to conduct physical attack on the user's computer is true but not closed.
Profiles can be set up to remember users with their not changing passwords and collect usage and connection statistics. Even whonix should be affected, if the attacker gets spectre bugs to work on the target machine.

All it needs to get this attack working, seems to depend on the surface (the template VM, used programs and the user behavior) and known bugs/exploits to get in touch with the Spectre Bug on Intel processors.

It is possible inside an AppVM do scramble information?
Like only get around (randomly choosen) 92 to 98 percent of cpu power to noise tiny cpu speed differences.
Change/Fake processor information given to any VM.
Add randomly choosen amount of datastorage not writeable. In example constantly giving 17 GB of private storage should be changed upwards (to i.e. 24GB, 19GB, 54GB) each VM start, but it is not writeable to prevent data loss.
The last point is probably not necessary because all qubes users would have the same amount of space in their disposal VM if storage settings are untouched.

About passwords:
Use/create a program which adds a salt created each reboot and is added silently to the screen password, to change memory/cpu processed passwords in their checksum or encrypted form.
It is possible to exchange a currently used decryption password (bypass?) by the running system to something randomly created?
So each Qubes OS after successful bootup would add a good password to the luks-keychain and change in realtime to this key.

These are my ideas so far.

Gedanken experiment completed.

Discussion in qubes-users, workarounds and program progress in github-issues?
Github link, same text: https://github.com/QubesOS/qubes-issues/issues/3977

> It is possible inside an AppVM do scramble information?

> Like only get around (randomly choosen) 92 to 98 percent of cpu power to
> noise tiny cpu speed differences.
> Change/Fake processor information given to any VM.
> Add randomly choosen amount of datastorage not writeable. In example
> constantly giving 17 GB of private storage should be changed upwards (to
> i.e. 24GB, 19GB, 54GB) each VM start, but it is not writeable to prevent
> data loss.

> The last point is probably not necessary because all qubes users would
> have the same amount of space in their disposal VM if storage settings are
> untouched.

> About passwords:
> Use/create a program which adds a salt created each reboot and is added
> silently to the screen password, to change memory/cpu processed passwords
> in their checksum or encrypted form.
> It is possible to exchange a currently used decryption password (bypass?)
> by the running system to something randomly created?
> So each Qubes OS after successful bootup would add a good password to the
> luks-keychain and change in realtime to this key.

Right. If an AppVM can be infiltrated, information like /proc/cpuinfo is from the dom0 cpu, not something standard xen dummy cpu like.
Most qubes users would need the same cpu not to be categorized by surveillance.
CPU info can help an attacker to find an explicit exploit for my machine more quickly.
Even for third party software or firefox performance options the cpu model is the most interesting part for metadata.
So, an user who is using an intel i7 cpu laptop unregular and the same qubes VM with their logins or software on an intel XEON workstation between 8am and 14 pm on workdays would tell a lot...
I think I do not have to tell more, even if most qubes users would not use qubes on more than one machine, would they?
To avoid telling the exact cpu model but using a standard which is supported in most software like firefox is as important as limiting cpu speed for VMs (qubes).
Qubes already supports limiting cpu cores, why not also cpu power?
This blog shows the possibility: https://deranfangvomende.wordpress.com/2011/05/11/slice-your-xen-with-automatic-resource-limits/

This is not much, but in another post (https://www.webhostingtalk.com/showthread.php?t=1048039&highlight=cpucap) the topic is about monitoring and cut resources if a guest is using too much.
Because of some tests, I never got it working to annoy qubes OS with 100 percent cpu usage on all cores in an AppVM. In dom0 I always could kill the VM.
But if I use a lot of storage read and writes, all VMs including dom0 is nearly unusable. Something  I want to think about and start playing with these scripts.

RAM encryption in VMs is something waiting for us in the near future.

>
> > Like only get around (randomly choosen) 92 to 98 percent of cpu power to
> > noise tiny cpu speed differences.
> > Change/Fake processor information given to any VM.
> > Add randomly choosen amount of datastorage not writeable. In example
> > constantly giving 17 GB of private storage should be changed upwards (to
> > i.e. 24GB, 19GB, 54GB) each VM start, but it is not writeable to prevent
> > data loss.
>
> See https://github.com/QubesOS/qubes-issues/issues/1142,
> https://github.com/QubesOS/qubes-issues/issues/2361, probably some more I
> missed/am forgetting!
>
> > The last point is probably not necessary because all qubes users would
> > have the same amount of space in their disposal VM if storage settings are
> > untouched.
>
> I think Qubes is more concerned about security than getting fingerprinted
> as a Qubes user. Like you mention, though, using a disposable VM with the
> same configuration as everyone else goes a long way.

Anonymity can increase security for not telling information about used hardware.
If an AI can intercept most data traffic and also fetch information through investigating or leaked information through the browser, a never changing storage password can identify the user as well and furthermore fill the log of entry points with the internet if clearnet is used.
Within a few weeks a whole profile can be created from the collected metadata. And the first meltdown/spectre bugs was 7 months known to intel (not only, probably) before become famous.

>
> > About passwords:
> > Use/create a program which adds a salt created each reboot and is added
> > silently to the screen password, to change memory/cpu processed passwords
> > in their checksum or encrypted form.
> > It is possible to exchange a currently used decryption password (bypass?)
> > by the running system to something randomly created?
> > So each Qubes OS after successful bootup would add a good password to the
> > luks-keychain and change in realtime to this key.
>
> Both of these are interesting but seem like it would make data recovery
> difficult or even impossible if Qubes crashes?

No, why should it? Luks Keychain can, as far as I remember, store maximum 8 different passwords for a storage. Qubes itself would just need 1 keyslot for a randomly created password and immediately switching to it, if dm-crypt allows this.
I am currently reading more and more (and maybe asking dm-crypt devs) what key is being used for de-, encrypting and/or what key is hold in memory.
If the key hold in memory is readable for an attacker but can be switched in runtime, the qubes user can use the own key to unlock and qubes os switches to a self generated key in another keyslot after successful boot into the system.
With the --key-slot option in luks dm-crypt qubes could always use the last keyslot and just forget the key or delete it (?) at shutdown, also overwrite the keyslot after successful boot up.
The more Qubes OS replaces user information at runtime with self generated stuff without affecting an user-friendly interface the qubes user feel comfortable with and does not want to be changed, the better the key aspect of Qubes.