Hello David, Thank you for the open feedback.
> I think you have some misconceptions here > - the main one being why people tend to use > Qubes OS: Segregation of data to application- > specific domains, i.e. impact of a domain > compromise is limited. You are right, regarding why people use Qubes. But depending on specific workflows there is a need to either work with cloud storage for collaboration or to switch the OS completely for this use case. Think about a (cloud based or on premise) storage service which is used by several people. My goal is to work 100% in Qubes and I think that splitting access of data and local storage offers a better security than having the data synced and stored in one AppVM. And I tried to build something that makes it easier to access data from various VMs in an easy way (knowing that it is less secure than using qvm-copy-to-vm). But using some scripts we can reduce the attack surface on nfs in such a way, that we only enable NFS/open ports when access is needed. I can't see how this approach is less secure than using one VM for syncing/storing/accessing the data? > Your idea however makes your Qubes > installation vulnerable to: - Any attacks > originating from that OS ("files should still be > accessible/decryption from other Operating > systems") True, but wouldn't this mean that the AppVM which is working as NFS Client must be compromised before NFS is attacked? > Nfs-based attacks (basically all your AppVMs > using nfs will be vulnerable to all nfs > vulnerabilities NFS access to the server is allowed on a per VM basis (firewall allow per IP), shouldn't this be enough to reduce NFS attack surface? > encfs based attacks which people can even > find on wikipedia. Yes true, it is a shame, that we still don't have a multiplatform open source encryption standard that could maybe also be adapted by cloud storage providers. But as mentioned the idea could also be implemented with other encryption solutions like CryFS, ... > if you don't want to add > another idea to the security circus > I'd reconsider either using Qubes OS, your > other OS or your architecture. Hmm ..., why should I abandon Qubes and use a much more less secure OS just because working with cloud/external storage is part of some (!) of my workflows? Even if all VMs which I use in the described solution are compromised, I can still have other VMs which are fine. So basically it's one more reason to use Qubes ;-)  -- 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 post to this group, send email to firstname.lastname@example.org. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/oZiNcfSwB33LIJmkEc-H483lwPzzbGTv-Wbwrq9BnvNnuyLKXbc1yshBcPkBf5MeimHjaCULUTr-XgLh70ZV_tMW4IJ68RG220hccF2Pqso%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.