I agree that filtering the trusted sound is very fragile, especially if you
don't want to add a latency. I'd say this is virtually no way.
this problem maybe could be solved without filtering:
* on setup the user chooses a notification sound (maybe one for each
color)
* the sounds should be random generated (here i don't know how easy it
is to generate easy distinguishable randomized notification sounds)
* since most users will use the default selection, it should be
randomized.
* every time the focus changes, the notification sound is played (if
different sounds are chosen for each color, the user even knows the
color of the active dom)
* if the user presses a key-combination (intercepted by dom0), the
sound is played again (maybe followed by some tts component saying the
vmname).
since the attacker can't know the the sound (if it is possible to create
such random sounds well enough), it can't be faked (except brute force
is used, which could be detected by the user).
the user maybe could choose a sequence of sounds.
as already posted, all other sounds should be muted when the
notification sound is played.
maybe the best way would be to get the user to configure the
confirmation sound by recording some custom sound with a microphone.
this would be much harder to fake than random sounds.
especially if the user records her/himself saying the vmname (and i
guess this would be the most secure way).
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/9be359ae-60e6-6427-cef4-b1e24f330ad6%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
