Qubes Manager: Make it more difficult to delete VMs

[andrewdavidwong]

Idea for a newbie-friendly enhancement:

When clicking Remove AppVM in Qubes Manager, require the user to type the name of the VM to be deleted, then click OK before deleting the VM (instead of just clicking OK).

[DeltaHeavy]

Agree

[DeltaHeavy]

Agree

[adrelanos]

What about a more simple
Really delete VM <name of the VM>?
Yes | No [selected by default]
?

[adrelanos]

What about a more simple
Really delete VM <name of the VM>?
Yes | No [selected by default]
?

[andrewdavidwong]

A second Yes/Cancel prompt could work, but the message on the second should at least give some sort of additional warning to the user signifying the gravity of what's about to happen.

The first prompt already says:

Are you sure you want to remove the VM '<vm-name>'?
All data on this VM's private storage will be lost!
[Yes] [Cancel]

This is already how one would word the second prompt, so it's not clear how the actual second should be worded. Perhaps the second one could say something like:

**Warning:** This action is permanent and cannot be undone!
This is your final warning! Please confirm the permanent
deletion of the VM '<vm-name>'.
[Yes] [Cancel]

[andrewdavidwong]

A second Yes/Cancel prompt could work, but the message on the second should at least give some sort of additional warning to the user signifying the gravity of what's about to happen.

The first prompt already says:

Are you sure you want to remove the VM '<vm-name>'?
All data on this VM's private storage will be lost!
[Yes] [Cancel]

This is already how one would word the second prompt, so it's not clear how the actual second should be worded. Perhaps the second one could say something like:

**Warning:** This action is permanent and cannot be undone!
This is your final warning! Please confirm the permanent
deletion of the VM '<vm-name>'.
[Yes] [Cancel]

[DeltaHeavy]

Another solution is to have a check box in VM settings "Lock VM" or
"Protect VM" which enables secondary confirmation on deletion (or perhaps
just disables deletion until unchecked).
On Nov 2, 2015 11:39 AM, "Axon" notifications@github.com wrote:

A second Yes/Cancel prompt could work, but the message on the second
should at least give some sort of additional warning to the user signifying
the gravity of what's about to happen.

The first prompt already says:

Are you sure you want to remove the VM ''?
All data on this VM's private storage will be lost!
[Yes] [Cancel]

This is already how one would word the second prompt, so it's not clear
how the actual second should be worded. Perhaps the second one could say
something like:

Warning: This action is permanent and cannot be undone!
This is your final warning! Please confirm the permanent
deletion of the VM ''.
[Yes] [Cancel]

—
Reply to this email directly or view it on GitHub
#1329 (comment)
.

[DeltaHeavy]

Another solution is to have a check box in VM settings "Lock VM" or
"Protect VM" which enables secondary confirmation on deletion (or perhaps
just disables deletion until unchecked).
On Nov 2, 2015 11:39 AM, "Axon" notifications@github.com wrote:

A second Yes/Cancel prompt could work, but the message on the second
should at least give some sort of additional warning to the user signifying
the gravity of what's about to happen.

The first prompt already says:

Are you sure you want to remove the VM ''?
All data on this VM's private storage will be lost!
[Yes] [Cancel]

This is already how one would word the second prompt, so it's not clear
how the actual second should be worded. Perhaps the second one could say
something like:

Warning: This action is permanent and cannot be undone!
This is your final warning! Please confirm the permanent
deletion of the VM ''.
[Yes] [Cancel]

—
Reply to this email directly or view it on GitHub
#1329 (comment)
.

[marmarek]

I think the most efficient would be the initial idea - entering VM name
to confirm its removal.

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]

I think the most efficient would be the initial idea - entering VM name
to confirm its removal.

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?

[qubesos-bot]

Automated announcement from builder-github

The package qubes-manager-3.2.5-1.fc23 has been pushed to the r3.2 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-manager-3.2.5-1.fc23 has been pushed to the r3.2 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[emdete]

i don't like to force a user to manually retype some arbitrary word. instead i prefere transparency. if the user gets some inside to drive his decision "delete or not to delete" it would be helpful to show what she looses in case of delition. like "the rw/partition still contains 2GB of userdata with roughly 300 jpegs" (ok, just an example).

[emdete]

i don't like to force a user to manually retype some arbitrary word. instead i prefere transparency. if the user gets some inside to drive his decision "delete or not to delete" it would be helpful to show what she looses in case of delition. like "the rw/partition still contains 2GB of userdata with roughly 300 jpegs" (ok, just an example).

[andrewdavidwong]

i don't like to force a user to manually retype some arbitrary word.

But it's the opposite of arbitrary. It's the name that you, the user, specifically bestowed upon this VM.

[andrewdavidwong]

i don't like to force a user to manually retype some arbitrary word.

But it's the opposite of arbitrary. It's the name that you, the user, specifically bestowed upon this VM.

[jpouellet]

https://xkcd.com/1172/ ;)

[jpouellet]

https://xkcd.com/1172/ ;)

[emdete]

i meant "arbitrary" because it is choosen arbitrarily by qubes to use that word. any other would be fine. debian for example chooses "Yes, do as I say!" or the like if you do something potential dangerous. that's of no help but pesters the user. i like to get the information /why/ that operation is dangerous and /what/ can get wrong or lost. this is taking the use seriously and helps him to decide instead of a short stopper in the hope the user reconsiders his request.

[emdete]

i meant "arbitrary" because it is choosen arbitrarily by qubes to use that word. any other would be fine. debian for example chooses "Yes, do as I say!" or the like if you do something potential dangerous. that's of no help but pesters the user. i like to get the information /why/ that operation is dangerous and /what/ can get wrong or lost. this is taking the use seriously and helps him to decide instead of a short stopper in the hope the user reconsiders his request.

[andrewdavidwong]

i meant "arbitrary" because it is choosen arbitrarily by qubes to use that word.

No, it's not. It's not arbitrary to choose the name of the VM that's being deleted. This is common functionality. For example, you have to enter the name of a GitHub repo when attempting to delete it.

any other would be fine. debian for example chooses "Yes, do as I say!" or the like if you do something potential dangerous. that's of no help but pesters the user.

Why would anything else be fine? Moreover, how is it fine if it's "of no help but pesters the user"?

i like to get the information /why/ that operation is dangerous and /what/ can get wrong or lost. this is taking the use seriously and helps him to decide instead of a short stopper in the hope the user reconsiders his request.

Is it not obvious in this case? If you click "Remove VM," then what you risk losing is precisely that VM.

[andrewdavidwong]

i meant "arbitrary" because it is choosen arbitrarily by qubes to use that word.

No, it's not. It's not arbitrary to choose the name of the VM that's being deleted. This is common functionality. For example, you have to enter the name of a GitHub repo when attempting to delete it.

any other would be fine. debian for example chooses "Yes, do as I say!" or the like if you do something potential dangerous. that's of no help but pesters the user.

Why would anything else be fine? Moreover, how is it fine if it's "of no help but pesters the user"?

i like to get the information /why/ that operation is dangerous and /what/ can get wrong or lost. this is taking the use seriously and helps him to decide instead of a short stopper in the hope the user reconsiders his request.

Is it not obvious in this case? If you click "Remove VM," then what you risk losing is precisely that VM.

[emdete]

pfew... gui design is tricky. and discussions around even more. ;)

you got me wrong when i said "would be fine" - this meant instead of your suggestion to type in the name of the VM. i dont like that the user has to type in something whatever it is. the cause for asking him to type in something is to stop him a bit and to force some time for rethinking. but the user does not gain any new information to reconsider his request.

"that VM" is clear for you, the developer, technician, whatsoever. we talk about GUI for endusers and for an enduser additional information what "that VM" is would be helpful. what files will be lost after deletion. this is in qubes mainly the rw partition. my oppinion: if you want to help the user with his decision show him what he looses, don't torture him by asking to type in words.

[emdete]

pfew... gui design is tricky. and discussions around even more. ;)

you got me wrong when i said "would be fine" - this meant instead of your suggestion to type in the name of the VM. i dont like that the user has to type in something whatever it is. the cause for asking him to type in something is to stop him a bit and to force some time for rethinking. but the user does not gain any new information to reconsider his request.

"that VM" is clear for you, the developer, technician, whatsoever. we talk about GUI for endusers and for an enduser additional information what "that VM" is would be helpful. what files will be lost after deletion. this is in qubes mainly the rw partition. my oppinion: if you want to help the user with his decision show him what he looses, don't torture him by asking to type in words.

[andrewdavidwong]

you got me wrong when i said "would be fine" - this meant instead of your suggestion to type in the name of the VM. i dont like that the user has to type in something whatever it is. the cause for asking him to type in something is to stop him a bit and to force some time for rethinking. but the user does not gain any new information to reconsider his request.

Apologies for the misunderstanding. I do think that there should be a "never warn me again" option, but prompting is a better default.

"that VM" is clear for you, the developer, technician, whatsoever. we talk about GUI for endusers and for an enduser additional information what "that VM" is would be helpful. what files will be lost after deletion. this is in qubes mainly the rw partition. my oppinion: if you want to help the user with his decision show him what he looses, don't torture him by asking to type in words.

We're considering this from very different perspectives. From our perspective, the main point of this feature is to prevent misclicks (without this feature, you can easily double-click away a VM if you have a momentary finger spasm). From your perspective, the main point of the feature you're proposing would be to aid the user in deciding whether the user wants to delete the VM. These our two very different things.

[andrewdavidwong]

you got me wrong when i said "would be fine" - this meant instead of your suggestion to type in the name of the VM. i dont like that the user has to type in something whatever it is. the cause for asking him to type in something is to stop him a bit and to force some time for rethinking. but the user does not gain any new information to reconsider his request.

Apologies for the misunderstanding. I do think that there should be a "never warn me again" option, but prompting is a better default.

"that VM" is clear for you, the developer, technician, whatsoever. we talk about GUI for endusers and for an enduser additional information what "that VM" is would be helpful. what files will be lost after deletion. this is in qubes mainly the rw partition. my oppinion: if you want to help the user with his decision show him what he looses, don't torture him by asking to type in words.

We're considering this from very different perspectives. From our perspective, the main point of this feature is to prevent misclicks (without this feature, you can easily double-click away a VM if you have a momentary finger spasm). From your perspective, the main point of the feature you're proposing would be to aid the user in deciding whether the user wants to delete the VM. These our two very different things.

[emdete]

wasn't there a solution on a voting computer for - or better against wrong clicks? ;)

but you are right, i did not considere a wrong click as i assumed the dialog opens somewhere else and the 'yes' button won't be clicked when accidentally double clicking.

[emdete]

wasn't there a solution on a voting computer for - or better against wrong clicks? ;)

but you are right, i did not considere a wrong click as i assumed the dialog opens somewhere else and the 'yes' button won't be clicked when accidentally double clicking.

[qubesos-bot]

Automated announcement from builder-github

The package qubes-manager-3.2.5-1.fc23 has been pushed to the r3.2 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-manager-3.2.5-1.fc23 has been pushed to the r3.2 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update