Possible shared installation identifiers between AppVMs using the same TemplateVM

General Discussion
1

Hi everyone,

I have a question about how TemplateVMs handle potential “installation identifiers” that some software might create during install time.

Here’s an example:

  • I have a Debian TemplateVM where I installed Google Chrome (using the official .deb package).
  • I then created four AppVMs based on that template. Each AppVM uses its own Chrome profile (stored in /home).

I understand that:

  • The Template’s root filesystem (/usr, /opt, etc.) is mounted read-only inside AppVMs.
  • Each AppVM has its own persistent /home and /rw directories.

However, I started wondering whether some programs — like Chrome — generate a unique installation identifier during installation (for example, in /opt/google/… or similar).
If so, that identifier would be shared across all AppVMs using the same TemplateVM, since they all use the same read-only system files. In this case, Google would know this as well…

I couldn’t find any documentation or discussion about this on the forum.
Has anyone ever thought about this, and besides creating a separate template per AppVM, do you have any solutions or workarounds?

2 Likes
2

Shouldn’t be a problem for security. As for privacy:

https://doc.qubes-os.org/en/latest/introduction/faq.html#what-about-privacy-in-non-whonix-qubes

3 Likes
3

Sure, StandaloneVMs are technically distinct from TemplateVMs or AppVMs:

4

@togoduke

However, I started wondering whether some programs — like Chrome — generate a unique installation identifier during installation (for example, in /opt/google/… or similar).

You can verify it:

Install the same browser in 2 separate templates. Check which files are put/changed on the system by the installer. Copy them to a VM and run diff. What is the result?

Has anyone ever thought about this, and besides creating a separate template per AppVM, do you have any solutions or workarounds?

A possible (wasteful) one is to install the browser package on AppVM start through a script in /rw/config/rc.local. However, that is not a panacea because if we assume browser X generates such ID, it really depends how it is generated. If it is based on data which is the same in all AppVMs (e.g. CPU model), that renders the whole exercise pointless.

Even if no ID is generated in a file, a sneaky browser X (or any other software) can still generate the ID internally (in RAM) and use it while running.

Bottom line: research is necessary.

2 Likes
5

Thank you this answer exactly my question.

2 Likes
6

I’ve tried the suggestion on this post and it works. It’s good protection against HW fingerprinting.

The thread of this post is a good discussion on this.

2 Likes
7

Yes, I also found a curious cookie when configuring avahi-daemon.service in template, like this:

Feb 24 00:22:45 rpi avahi-daemon[1438]: Server startup complete. Host name is rpi.local. Local service cookie is 2001195350.

Also Telegram:

1 Like