Small usability improvements to "QubesIncoming" folder

[bnvk]

Using the Qubes GUI, I spent a fair bit of time engaging with the QubesIncoming/ folder while moving data between VMs. I have a few ideas how to improve upon this crucial aspect of Qubes

• Rename QubesIncoming/ to just Incoming/
  • Makes it feel more of a native experience alongside Music, Videos, etc...
• Eliminate the sub-folders Incoming/work/ becomes just Incoming/
  • Less time spent looking inside of sub-folders which might be empty- I usually end up deleting empty folders to tidy up)
  • Unnecessary level of organization- I usually move files out of folders to better organize)
  • Is mostly irrelevant information- when moving files around, I know where they came from

[marmarek]

On Thu, Feb 25, 2016 at 09:58:32AM -0800, Brennan Novak wrote:

• Rename QubesIncoming/ to just Incoming/
  • Makes it feel more of a native experience alongside Music, Videos, etc...

No opinion here. But also not sure if that improve UX in any way. @bnvk
what do you think?

• Eliminate the sub-folders Incoming/work/ becomes just Incoming/

Strong opinion against this.

• Less time spent looking inside of sub-folders which might be empty- I usually end up deleting empty folders to tidy up)

I think this can be automated, which may be a good idea (periodically
clean empty directories in (Qubes)Incoming).

• Is mostly irrelevant information- when moving files around, I know where they came from

No, you do not. A malicious VM could send (see below why confirmation
isn't good enough for that) file with the same or very similar name. In
case of the same name, in the same time - you may notice it because the
other transfer would fail. But it could be "very similar" name, like
some additional space or something. If happening at the same time -
you'll see two similarly named files (and you may be able to choose the
right one, but not necessarily). But if happening with some delay, I bet
you'll find the file some other day and think "oh, here is that file, I
must have forgotten to move it out of Incomming".

So, the origin information is critical for security here.

Especially because we consider changing default policy for file transfer
from "ask" to "allow". See
#1166 (comment)
why. I bet you don't even read that confirmation prompt when you expect
some file transfer to be confirmed...

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Thu, Feb 25, 2016 at 09:58:32AM -0800, Brennan Novak wrote:

• Rename QubesIncoming/ to just Incoming/
  • Makes it feel more of a native experience alongside Music, Videos, etc...

No opinion here. But also not sure if that improve UX in any way. @bnvk
what do you think?

• Eliminate the sub-folders Incoming/work/ becomes just Incoming/

Strong opinion against this.

• Less time spent looking inside of sub-folders which might be empty- I usually end up deleting empty folders to tidy up)

I think this can be automated, which may be a good idea (periodically
clean empty directories in (Qubes)Incoming).

• Is mostly irrelevant information- when moving files around, I know where they came from

No, you do not. A malicious VM could send (see below why confirmation
isn't good enough for that) file with the same or very similar name. In
case of the same name, in the same time - you may notice it because the
other transfer would fail. But it could be "very similar" name, like
some additional space or something. If happening at the same time -
you'll see two similarly named files (and you may be able to choose the
right one, but not necessarily). But if happening with some delay, I bet
you'll find the file some other day and think "oh, here is that file, I
must have forgotten to move it out of Incomming".

So, the origin information is critical for security here.

Especially because we consider changing default policy for file transfer
from "ask" to "allow". See
#1166 (comment)
why. I bet you don't even read that confirmation prompt when you expect
some file transfer to be confirmed...

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[andrewdavidwong]

On Thu, Feb 25, 2016 at 09:58:32AM -0800, Brennan Novak wrote:

• Rename QubesIncoming/ to just Incoming/
  • Makes it feel more of a native experience alongside Music, Videos, etc...

No opinion here. But also not sure if that improve UX in any way. @bnvk
what do you think?

Wait... isn't @bnvk the one who just made that suggestion?

[andrewdavidwong]

On Thu, Feb 25, 2016 at 09:58:32AM -0800, Brennan Novak wrote:

• Rename QubesIncoming/ to just Incoming/
  • Makes it feel more of a native experience alongside Music, Videos, etc...

No opinion here. But also not sure if that improve UX in any way. @bnvk
what do you think?

Wait... isn't @bnvk the one who just made that suggestion?

[marmarek]

On Thu, Feb 25, 2016 at 06:58:20PM -0800, Axon wrote:

Wait... isn't @bnvk the one who just made that suggestion?

Ah, sorry. Haven't noticed it as previous N tickets were opened by
Michael...

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Thu, Feb 25, 2016 at 06:58:20PM -0800, Axon wrote:

Wait... isn't @bnvk the one who just made that suggestion?

Ah, sorry. Haven't noticed it as previous N tickets were opened by
Michael...

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Polygonbugs]

Why don't you add new features via customizing qubes-rpc policy (qubes.Filecopy) on dom0? Unless dom0 compromised, it wouldn't be security problem. BTW, It would be good if these features could be combined with group domain tag features newly implemented on Qubes 4.0

• Customzing default directory of "~/QubesIncoming" to user-defined directory.

• Moving keyfiles, which is stored on USB memory attached to qube A, to qube B on /tmp directory so that you don't need to manually remove and secure from human error.

• Moving huge files, which could be media data or qubes-backup files, bigger than maximun private storage of the qube to external cloud drive or your own NAS server.

• Directly moving several applications settings profiles to appropriate AppVM A (no internet) directory from AppVM B syncing from github.

---

• Change default QubesIncoming folder name to user-defined one.

• This could be good for improving privacy by removing one factor to determine that you are using Qubes-OS. Especially, when you are using cloud syncing software, antivirus, or Windows based OS.

[Polygonbugs]

Why don't you add new features via customizing qubes-rpc policy (qubes.Filecopy) on dom0? Unless dom0 compromised, it wouldn't be security problem. BTW, It would be good if these features could be combined with group domain tag features newly implemented on Qubes 4.0

• Customzing default directory of "~/QubesIncoming" to user-defined directory.

• Moving keyfiles, which is stored on USB memory attached to qube A, to qube B on /tmp directory so that you don't need to manually remove and secure from human error.

• Moving huge files, which could be media data or qubes-backup files, bigger than maximun private storage of the qube to external cloud drive or your own NAS server.

• Directly moving several applications settings profiles to appropriate AppVM A (no internet) directory from AppVM B syncing from github.

---

• Change default QubesIncoming folder name to user-defined one.

• This could be good for improving privacy by removing one factor to determine that you are using Qubes-OS. Especially, when you are using cloud syncing software, antivirus, or Windows based OS.

[andrewdavidwong]

Why don't you add new features via customizing qubes-rpc policy (qubes.Filecopy) on dom0? Unless dom0 compromised, it wouldn't be security problem. BTW, It would be good if these features could be combined with group domain tag features newly implemented on Qubes 4.0

• Customzing default directory of "~/QubesIncoming" to user-defined directory.

• Moving keyfiles, which is stored on USB memory attached to qube A, to qube B on /tmp directory so that you don't need to manually remove and secure from human error.

• Moving huge files, which could be media data or qubes-backup files, bigger than maximun private storage of the qube to external cloud drive or your own NAS server.

• Directly moving several applications settings profiles to appropriate AppVM A (no internet) directory from AppVM B syncing from github.

It sounds like these are all variations on making qvm-[copy|move] more like qvm-backup by allowing the user to specify an arbitrary destination (path or command) in the receiving VM (which may actually be a remote server via SSH, for example). It sounds like this would effectively give the sending VM control over the receiving VM. I take it that your argument is that this should be allowed in cases when the user explicitly allows it in a dom0 RPC policy. I wonder what @marmarek thinks about this.

• Change default QubesIncoming folder name to user-defined one.

• This could be good for improving privacy by removing one factor to determine that you are using Qubes-OS. Especially, when you are using cloud syncing software, antivirus, or Windows based OS.

There would still be far too many easy ways to detect that it's a Qubes VM. It would be impractical for us to try to eliminate even all of the trivially detectable ones in every type of domU distro. That's why we instead concentrate our privacy efforts on a single one: Whonix. When privacy is a concern, use Whonix.

[andrewdavidwong]

Why don't you add new features via customizing qubes-rpc policy (qubes.Filecopy) on dom0? Unless dom0 compromised, it wouldn't be security problem. BTW, It would be good if these features could be combined with group domain tag features newly implemented on Qubes 4.0

• Customzing default directory of "~/QubesIncoming" to user-defined directory.

• Moving keyfiles, which is stored on USB memory attached to qube A, to qube B on /tmp directory so that you don't need to manually remove and secure from human error.

• Moving huge files, which could be media data or qubes-backup files, bigger than maximun private storage of the qube to external cloud drive or your own NAS server.

• Directly moving several applications settings profiles to appropriate AppVM A (no internet) directory from AppVM B syncing from github.

It sounds like these are all variations on making qvm-[copy|move] more like qvm-backup by allowing the user to specify an arbitrary destination (path or command) in the receiving VM (which may actually be a remote server via SSH, for example). It sounds like this would effectively give the sending VM control over the receiving VM. I take it that your argument is that this should be allowed in cases when the user explicitly allows it in a dom0 RPC policy. I wonder what @marmarek thinks about this.

• Change default QubesIncoming folder name to user-defined one.

• This could be good for improving privacy by removing one factor to determine that you are using Qubes-OS. Especially, when you are using cloud syncing software, antivirus, or Windows based OS.

There would still be far too many easy ways to detect that it's a Qubes VM. It would be impractical for us to try to eliminate even all of the trivially detectable ones in every type of domU distro. That's why we instead concentrate our privacy efforts on a single one: Whonix. When privacy is a concern, use Whonix.

[marmarek]

Having source VM putting files in arbitrary location in destination VM controlled by that source VM, even with explicit user confirmation, is big, fat, no-go. We don't want to have any single "do you want to allow qube X to be compromised?" confirmation anywhere in the system.
What could be done, is a configuration in destination VM where files should be - instead of ~/QubesIncoming. Right now you can easily achieve similar thing using mount --bind. For example:

sudo mount --bind ~/Dropbox ~/QubesIncoming/personal

Maybe not the most convenient way, but it is just one line.
An improved version could be an argument to qfile-unpacker, so it would be possible to just modify /etc/qubes-rpc/qubes.Filecopy (or create new one as /etc/qubes-rpc/qubes.Filecopy+something).

[marmarek]

Having source VM putting files in arbitrary location in destination VM controlled by that source VM, even with explicit user confirmation, is big, fat, no-go. We don't want to have any single "do you want to allow qube X to be compromised?" confirmation anywhere in the system.
What could be done, is a configuration in destination VM where files should be - instead of ~/QubesIncoming. Right now you can easily achieve similar thing using mount --bind. For example:

sudo mount --bind ~/Dropbox ~/QubesIncoming/personal

Maybe not the most convenient way, but it is just one line.
An improved version could be an argument to qfile-unpacker, so it would be possible to just modify /etc/qubes-rpc/qubes.Filecopy (or create new one as /etc/qubes-rpc/qubes.Filecopy+something).

[Polygonbugs]

Customzing default directory of "~/QubesIncoming" to user-defined directory.

Yes, bad idea when it comes to security. Also there is another way like mount --bind

How about encrypting file before it goes to destination VM? qvm-copy-to-vm calls new dispVM and temporary move file. When moving files to temporay VM finishes, confirmation windows on dom0 calls user to type encryption passphrase and encryption goes. If encryption finishes successfully then finally move file to destination VM. Similar mechanism as a qvm-{pdf,img}-converter but the differences are encryption process rather than sanitizing and moving it to other domain. The result would be lowering the threat to compromise before user unlock file. Since not every malicious file are intended to have exploit on encryption process...

Also this option could be selected by user as a confirmation window on dom0 and changed by qubes-rpc policy.

[Polygonbugs]

Customzing default directory of "~/QubesIncoming" to user-defined directory.

Yes, bad idea when it comes to security. Also there is another way like mount --bind

How about encrypting file before it goes to destination VM? qvm-copy-to-vm calls new dispVM and temporary move file. When moving files to temporay VM finishes, confirmation windows on dom0 calls user to type encryption passphrase and encryption goes. If encryption finishes successfully then finally move file to destination VM. Similar mechanism as a qvm-{pdf,img}-converter but the differences are encryption process rather than sanitizing and moving it to other domain. The result would be lowering the threat to compromise before user unlock file. Since not every malicious file are intended to have exploit on encryption process...

Also this option could be selected by user as a confirmation window on dom0 and changed by qubes-rpc policy.

[v6ak]

If I understand it correctly, you suggest to use password-based-encryption as a confirmation mechanism. Is it right? If so, it is quite overkill. Some harder confirmation mechanism like retyping source/destination vm name could do the same.

…

On April 5, 2018 8:39:22 AM GMT+02:00, Polygonbugs ***@***.***> wrote: > Customzing default directory of "~/QubesIncoming" to user-defined directory. Yes, bad idea when it comes to security. Also there is another way like `mount --bind` How about encrypting file before it goes to destination VM? qvm-copy-to-vm calls new dispVM and temporary move file. When moving files to temporay VM finishes, confirmation windows on dom0 calls user to type encryption passphrase and encryption goes. If encryption finishes successfully then finally move file to destination VM. Similar mechanism as a qvm-{pdf,img}-converter but the difference is encryption process rather than sanitizing. The result would be lowering the threat to compromise before user unlock file. Since not every malicious file are intended to have exploit on encryption process... Also this option could be selected by user as a confirmation window on dom0 and changed by qubes-rpc policy. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #1780 (comment)

-- Sent from my fruity BlackBerry device with K-9 Mail. Please excuse my brevity.

[v6ak]

If I understand it correctly, you suggest to use password-based-encryption as a confirmation mechanism. Is it right? If so, it is quite overkill. Some harder confirmation mechanism like retyping source/destination vm name could do the same.

…

On April 5, 2018 8:39:22 AM GMT+02:00, Polygonbugs ***@***.***> wrote: > Customzing default directory of "~/QubesIncoming" to user-defined directory. Yes, bad idea when it comes to security. Also there is another way like `mount --bind` How about encrypting file before it goes to destination VM? qvm-copy-to-vm calls new dispVM and temporary move file. When moving files to temporay VM finishes, confirmation windows on dom0 calls user to type encryption passphrase and encryption goes. If encryption finishes successfully then finally move file to destination VM. Similar mechanism as a qvm-{pdf,img}-converter but the difference is encryption process rather than sanitizing. The result would be lowering the threat to compromise before user unlock file. Since not every malicious file are intended to have exploit on encryption process... Also this option could be selected by user as a confirmation window on dom0 and changed by qubes-rpc policy. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #1780 (comment)

-- Sent from my fruity BlackBerry device with K-9 Mail. Please excuse my brevity.

[Polygonbugs]

If I understand it correctly, you suggest to use password-based-encryption as a confirmation mechanism. Is it right?

Yes, you're right... But if it is implemented, it will shorten time than manually doing it. Maybe, it is also not good feature? I'm not sure that it is something very difficult. Wondering that I can do it with qvm-run command on dom0 and make some auto-script...

[Polygonbugs]

If I understand it correctly, you suggest to use password-based-encryption as a confirmation mechanism. Is it right?

Yes, you're right... But if it is implemented, it will shorten time than manually doing it. Maybe, it is also not good feature? I'm not sure that it is something very difficult. Wondering that I can do it with qvm-run command on dom0 and make some auto-script...

[v6ak]

I don't think it is too difficult to implement, it is rather too weird and user-unfriendly way to achieve such a goal: * You suggest to use encryption. The reason for encryption is not confidentiality or even authentication (despite encryption itself does not have to provide authentication). After all, if some attacker is able to read it at this moment, then the attacker must have access to one of those VMs or even to dom0, which means we have some bigger problems. You suggest to use encryption just for preventing the file to be used accidentally. * You suggest to use passwords, but typical password-related security suggestions don't apply there. In this case, some publicly-known password could do the same job as a completely random password. * Also, the user has to type the password twice, remembering it. I don't see any additional security in typing it twice. * Requiring the user to retype the source/target VM name (maybe both) could do a better job for user awareness and it is less confusing. Your proposed solution looks a bit like this: You want to copy some file within computer. So you are first asked for encryption password and then for decryption password, just in order to ensure you haven't copied the file to a bad directory. In both cases, encryption is not needed at all. Simply requiring the user to write the same text (I would not call it password) twice does the same from user perspective and provides the same protection. (They just differ in performance characteristics and in implementation effort.)

[v6ak]

I don't think it is too difficult to implement, it is rather too weird and user-unfriendly way to achieve such a goal: * You suggest to use encryption. The reason for encryption is not confidentiality or even authentication (despite encryption itself does not have to provide authentication). After all, if some attacker is able to read it at this moment, then the attacker must have access to one of those VMs or even to dom0, which means we have some bigger problems. You suggest to use encryption just for preventing the file to be used accidentally. * You suggest to use passwords, but typical password-related security suggestions don't apply there. In this case, some publicly-known password could do the same job as a completely random password. * Also, the user has to type the password twice, remembering it. I don't see any additional security in typing it twice. * Requiring the user to retype the source/target VM name (maybe both) could do a better job for user awareness and it is less confusing. Your proposed solution looks a bit like this: You want to copy some file within computer. So you are first asked for encryption password and then for decryption password, just in order to ensure you haven't copied the file to a bad directory. In both cases, encryption is not needed at all. Simply requiring the user to write the same text (I would not call it password) twice does the same from user perspective and provides the same protection. (They just differ in performance characteristics and in implementation effort.)

[andrewdavidwong]

Closing as "won't do." If anyone has a new argument for why this should be done, please leave a comment, and we'll be happy to take another look. Thank you.

[andrewdavidwong]

Closing as "won't do." If anyone has a new argument for why this should be done, please leave a comment, and we'll be happy to take another look. Thank you.

[andrewdavidwong]

(Technically, this was re-closed, since it had already been closed once before. I don't know the reason for the original closure, but it appears also to have been "won't do.")

[andrewdavidwong]

(Technically, this was re-closed, since it had already been closed once before. I don't know the reason for the original closure, but it appears also to have been "won't do.")