First, I’d like you to know that I extremly appreciate your time and your responsivness. I am sure all the rest or most of us do, too. Thanks for explaining in details your concept. The idea is absolutely clear and it indeed makes me rethink over and over again how I see and understand Qubes and why I use it at all. I hope you’ll find time to read my thoughts on it and eventually to respond again. As to a newbie, it would help me to test my comprehensions.
So, where the data came from? Generated in vault or/and came somewhere from outside? Which way the latter?
This means the data was generated in vault then? Then, how to generate and store invaluable received emails, photos, videos etc in vault, for example?
But let us assume that your scenario was set for the data generated in the vault only. Then it makes full sense to me. But…
Unless I do something irresponsible like this (again convenience, ehm?), by doing that (which I of course wouldn’t), why it isn’t enough what we already have built-in? This is the most important answer I would like to get at the moment.
Now, I absolutely understand that your policies prevent picking up the wrong qube in the dialog box gui, but aren’t such wrongdoings out of scope of everything and everyone we interract with, not only of Qubes and vault? There couldn't be as many policies as needed to help us with this. Instead of setting the policy wherever we might pick up the wrong thing, wouldn’t be more effective to invest that time in training the mind to focus – one step at a time, for example (this is rather rethoric)? We to forget multitasking, rather than “set to forget”?
Regarding sharing qube: I’d never put files there that I’d care enough for. Music, movies, wallpapers, etc - yes. Emails, personal photos, etc - nope! So when it gets compromized - I don’t care about the data in it. That was about the data aspect. Now, since the sharing qube is compromized, what’s the use of your policies in terms of security of other qubes?
Since shared qube isn’t meant to acces other qubes, which control exactly will “save” those qubes from compromizing by already compromized shared qube?
Isn’t the only thing that is the real threat is to take the data from compromized qube and process it in other not compromized qube - which is actually the ultimate reason for me not to have shared qube/folder.
Btw,
all the data is by default copied to QubesIncoming folder (of a shared qube). Since I wouldn’t copy data to there I would care for, why would I set policies for each folder in QubesIncoming (or elsewhere)? On the other hand, when the data/source qube was compromized prior to copy it to uncompromized shared qube, why would I need the policies?
As I see this: when the qube, I’m copy data from to a shared qube, is already compromized, when it escapes the default QubesIncoming folder, wouldn’t it will be able to escape any other folder set by your policy? Or are we counting that it will compromize only the data in a folder set by your policy and will not escape that folder?
So, even with that, my ultimate, unwritten policy is - if I use shared qube, I don’t care about the data in it, I access it, copy/paste to/from it and proces data from it only with TBDVMs. I don’t care if any data/tbdvm/shared qube is compromized.
Would I need any additional policies for my vision/concept of a shared qube and why? Lateral or escaping towards Xen in this workflow are out of scope of shared qube discussing anyway - it’s a general issue.
On armoring in my previous post, I meant setting your policies, and not wearing the seat belt was meant for being lazy to fire up dedicated qubes for the purposes shared folder/qubes were proposed for, meaning prioritizing and forcing convenience. I might here add that I consider built-ins as the default air-bag add-ons.
I already tried here to emphesize Information Security as a broader perspective. I was lucky enough to become familiar with this field’s standards, and from that point of view its part - IT Security, is almost insignificant not to say irrelevant segment. Not to me, it’s by the standard, and many notorious xkbds are just desribing this in a funny way. Unfortunately, instead of being taken with responsible consideration by ITS people it is mostly taken as disrispectfull and ignorant. And people wouldn’t believe what info could be get only by offering a coffe or a beer to someone (doesn’t matter if accepted).
That say, the most is on us and the quality of our risk assesment, not on the (power of the) controls which are at our disposal.
So I’d be delighted one day to find an announcment here that Qubes Team got a new member in a newly opened postion - IS Specialist. I haven’t found any team so far to have such a specialist.