Hi Steve, Thanks for your thoughtful response!
On Sun, 2020-11-15 at 16:31 -0500, Steve Coleman wrote: > My way of dealing with it is to just clone your pristine fedora-32 > template and add the required packages to that template clone, then > create an AppVM that uses that template. This way you limit any > potential data loss or damage to just that one AppVM which you then > use whenever you need one of those proprietary apps. The question now > is what data would they share in that AppVM and is it reasonable for > them to share the same AppVM? If the answer is yes then there is no > problem. If no, then create another AppVM based on the same template > for the other app. For proprietary apps packaged by their vendors, I don't trust the package installation scripts any more than the apps themselves. Thus, if I wouldn't be willing to run two apps in the same VM, I wouldn't be willing to install both apps in the same template either. This being so, the approach you suggest degenerates to the StandaloneVM approach I mentioned. (At the other extreme, if the apps were packaged by an entity that I trust to ensure that no proprietary code runs without user consent, then I could just install the packages in my main template and the whole problem would go away. Is there an intermediate scenario in which having a second template shared by multiple AppVMs is useful?) > The downside is you now have to update two templates instead of one, > but that of course can be automated. While I could probably get used to kicking off the dnf upgrade in all templates and letting it run unattended (it's often slow), my bigger concern is the custom tools and configuration changes in my main template that aren't currently packaged for dnf. I could probably package them and/or do without some of them in some proprietary-app VMs, but I think that would end up being a bigger hassle than developing and using my proposed tool. Also, I'm low on disk space and making many templates would make it worse, though maybe it's time that I just bought a bigger disk. > How many specialized AppVMs you create is then based on your own > risk/benefit analysis. I would think it's reasonable for instance to > have Zoom and Skype share the same memory space unless the topics > discussed in each app are highly confidential. You're probably right that the additional risk of sharing a VM between Zoom and Skype (for example) is small compared to the other unsolved security problems I currently have. However, inasmuch as I continue to use the proprietary apps, I'd be more inclined to just develop the tool to automate the use of separate VMs (anticipating that other people might reuse it) than to address this question. Matt -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/535e22152b2f63400aa59c22a971e6a19bbc19da.camel%40mattmccutchen.net.