Comment on global shortcuts security

[Bill Spitzak]

On 09/30/2012 01:35 AM, Pekka Paalanen wrote:
> On Wed, 26 Sep 2012 08:21:44 +0200
> Daniel <danlist at terra.es> wrote:
>
>> El dt 25 de 09 de 2012 a les 11:15 -0400, en/na Kristian Høgsberg va
>> escriure:
>>> On Mon, Sep 24, 2012 at 04:53:20PM -0700, Bill Spitzak wrote:
>>>> Keystrokes should be sent to the application first. Only if the
>>>> application refuses them should they be considered global shortcuts.
>>>
>>> No.
>>
>> Could you elaborate a little bit the logic leading to this decission,
>> please?
>
> It is a roundtrip, which is already bad in itself.

All the normal keystorkes that a client handles are a roundtrip, so I 
really can't see this being a problem. I certainly agree with Wayland's 
design that once a client decides to change it's display, that it be 
able to do that with no further roundtrips. But that is different than 
event handling.

> Furthermore, it
> allows clients override global shortcuts of the compositor, which
> means that it would be impossible to have secure shortcuts, e.g.
> "kill this client" or "switch sessions".

There certainly would still be "secure shortcuts" like you describe. 
These are identifiable to the user as "you hold down lots of strange 
shift keys". For instance ctrl+alt+del. The reason "lots of strange 
shift keys" are needed is to avoid breaking applications by blocking a 
keystroke the application designer thought was available. My main 
concern is that we don't have to make *ALL* shortcuts "lots of strange 
shift keys".

The type of shortcuts I think me and Daniel are worrying about is the 
volume buttons. I would like hitting the volume button to change the 
volume in the current app that has focus, and only change the global 
volume if that app does not have a local control.

> Third, if the client
> hangs, it would mean global shortcuts would stop working, and you
> could not e.g. alt-tab away from a frozen window, which might be
> even fullscreen.

There would be a timeout, same as being suggested for the window drag 
controls, after which the shell acts as though the client ignored the 
keystroke.

> It would also mean, that every application would need additional
> code to cooperate with the compositor. Missing that code would by
> default stop all global shortcuts from working. Programmers would
> have to spend effort to not break the *whole* desktop, instead of
> just having their app working right with the desktop by no effort.

This just requires toolkits to require a "I used the key" return value 
from keystroke handlers. The amount of work for a programmer to support 
that is trivial (they are likely calling several functions that already 
return this information), and failure of the programmer to do this will 
result in obvious bad behavior of the application (such as breaking Tab 
navigation) even if there are no global shortcuts.

> You might invent elaborate schemes to overcome the latter cons,
> but even the roundtrip argument alone is a serious one, and there
> would have to be a serious benefit in doing so. This would just
> bring a lot more problems than it would solve.

I'm worried that a "shortcut registry" will add enormous complexity and 
bugs and make it difficult for programmers to get the behavior they want.