Comment on global shortcuts security

[Timothée Ravier]

Le 25/09/2012 01:53, Bill Spitzak a écrit :
> Keystrokes should be sent to the application first. Only if the
> application refuses them should they be considered global shortcuts.


According to me, the main goal is to _never_ have global shortcuts.
That's why each applications should register the semantic keys they want
to listen to.

Following your idea, an application could selectively "deny" input which
would be really confusing to the user, and raise other security concerns
(sending input "globally" while printing stars in a password input field
for example).


> I think this will fix most of the security problems you raise. It also
> means there can be simpler shortcuts, currenlty global shortcuts require
> the holding down of an excessive number of shift keys to avoid conflicts
> with any possible shortcut in a program.


This is a distribution/desktop environment default configuration
problem. I don't think there is a simple solution for this.


> Piotr Rak wrote:
>> It is probably not great discovery, but I believe that minimal
>> requirement for given combination of keys, to be allowed as global
>> shortcut is that is not printable and not whitespace given currently
>> selected keyboard layout. Such combination should never be delivered
>> to application, that doesn't have active keyboard focus.

[...]

>> Let's imagine that compositor Y becomes most popular compositor, or
>> even better, most of compositors use some library for their semantic
>> binding handling. It (compositor or library) is shipped usable enough
>> configuration for keys and their actions - (that's ofc one of reasons
>> that it is so popular :->). Now, most users or distros developers
>> won't be tempted to change this config - people are lazy, and that's
>> why civilization can progress at all .
>> If I want sniff their input - I have knowledge what this semantic
>> word use for sniffing given sequence, using knowledge of default
>> configuration.


The semantic approach means that only a special set of key combos will
be available for applications to register.

Those key combos will most likely correspond to non-printable characters
as users would be annoyed by the double effect of one key.

It could even be imagine that those keys would be captured by the
compositor and send only to the applications requesting them. This may
however break in-focused-application shortcuts.

Finally, it should be reminded that those keys are in a limited number
as it generally correspond to special hardware keys
(play/next/previous/volume control/back-light control/display control)
that some keyboards provides. The user should never be able to use those
in a password and it should expect them to work only with special
applications (media players, screen back light control...).

I may have overlooked some use cases; please correct me if I'm wrong.

Tim