Comment on global shortcuts security

[Rick Stockton]

On 09/30/2012 09:08 AM, Bill Spitzak wrote:
>  << SNIP >>
I hope these comments are useful; if they're just a bunch of obvious 
"baggage", I apologize.

> 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.
>

You are suggesting a design with which I agree:

First-priority WM/Compositor shortcuts (e.g., switch from a frozen App 
Window; halt the entire user's Session) are "owned" by Weston, in an 
unconditional manner. Weston will act on these "lots of strange keys" 
Events before the App even gets a chance to see them events (Keyboard 
for usre; and maybe some user-specified Pointer Evts., if we do offer a 
"registry" implementation which users can modify for themselves.)

Second-Priority Weston shortcuts are "lots of strange keys" (AKA 
"keysequence" of length one, or more, events in the correct order) ... 
which were offered to the Application and returned to Weston (or another 
WM) as un-handled events. Or, they are directly generated within the 
application via logic (or GUI events), leading to an App request that 
the "shortcut" be used. This is the land of HIG, and IMO Weston/Wayland 
needs to create and document such guidelines: Analogous to a new column 
in the "shortcuts" which are understood by Qt, when a Qt Application 
runs within KWin versus Gnome or OS-X Window managers. (Reference 
http://qt-project.org/doc/qt-5.0/qkeysequence.html#StandardKey-enum.) 
For example, an Qt Application request to switch to "fullscreen" will 
pass Ctrl+Meta+F on OS-X, F11 on KDE (which can also use Ctrl+Shift+F), 
and Ctrl+F11 under Gnome. The program is compiled ONCE, and the 
alternative implementations of the corresponding keysequence are 
executed within the Qt library.

In the particular case which you're describing: This is not a 
"First-priority" WM shortcut. We should pass the volume button "press" 
evt. to the Application with keyboard, allowing it to process in a way 
which it chooses. If it ignores the key, then the key event should be 
RETURNED from the application (or even generated by the Application), 
"back" into the WM/Compositor, where we may apply it globally.

>> 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.

IIRC, The Qt/KDE design is the opposite: If they "USED" the key within 
some level of code (class or interface), then they suck it in and 
nothing comes back to Weston. If they want to ignore the key, then the 
keystroke event gets "pushed up" through all of the Application classes, 
eventually reaching the top-level window. And that Window passes it back 
to the WM/Compositor.
> 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.

That depends how complex/ sophisticated Weston intends to become. If 
Weston will eventually have spinning cubes of multiple Desktops and/or 
"workspaces", then we'll need to let users avoid "sequences" which 
applications want to use. And we'll need to have pointer support- for a 
number of buttons which is AT LEAST competitive with Compiz. If we want 
to leave Weston as a more limited Compositor,
- - - - -
With those introductory comments we get to the "guts" of my reply: 
Perhaps Weston/Wayland HIG should be defined with a clear distinction 
between those "Global Shortcuts" will be taken and executed by 
Wayland/Weston before an application can even see them, versus other 
"Global Shortcuts" which will only execute a global Wayland/Weston 
function when passed back, in a round trip, from an Application program 
which chose to ignore it.

And, OT:
Do you intend to support EMACS-style "keysequences" of separate events, 
or merely single-event combinations of modifiers with key(s)? The latter 
brings up issues of A18n .... if you're typing with a single-pointed 
tool in your mouth, it's REALLY HARD to hold "Ctrl" and "Alt" at the 
same time you press "Del" ;)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20121001/d606ceec/attachment.html>