Re: WM enhancements to support accessible screen lock

[Lubos Lunak <l lunak suse cz>]

On Tuesday 23 of September 2003 22:04, Brian Cameron wrote:
> Perhaps the largest remaining accessibility hole on the GNOME desktop today
> is the lack of an accessible screen lock mechanism.  In order for the lock
> screen to be properly accessible, the relationship between the screensaver
> and the window manager will likely need to become more intimate.
[snip]
> Most current lock screen programs run as "override redirect" windows, to
> ensure that they get placed on top of all windows, and use GrabKey and
> GrabPointer in order to ensure that the screen lock program is
> appropriately secure.  However, I believe these mechanisms are simply too
> crude to support an AT program such as GOK.
>
> To support accessibility, the job of controlling window stacking order
> should perhaps instead be controlled by the window manager.  In other
> words, the screen saver would no longer run as "override redirect" and
> instead the screen manager would ensure that the screen lock program would
> be at the appropriate stacking order.

 It may be too crude, but it's the only way I'm aware of how to make the 
locking really work and not just be something laughable. If you don't grab 
the keyboard, you cannot really prevent other applications from getting 
keyboard input (e.g. global shortcuts). Even with mouse not being grabbed, 
the mouse could be used to get around the lock. And last but not least, 
without an override redirect window that's constantly kept at top, other 
applications could get higher, if they would use override redirect windows 
themselves.

 The last two problems could be perhaps handled by the window manager keeping 
the lock window very high as currently the locking programs do, but I don't 
think there's any solution for the keyboard problem. Moreover, I simply don't 
like the idea of using the window manager for this (based on personal 
experience, unfortunately - some KDE versions actually used a managed 
STAYS_ON_TOP window as the locking window and helped it to stay high by 
watching for ConfigureNotify events which were followed by XRaiseWindow(); it 
wasn't really that difficult to break it). In other words, I have certain 
doubts about quality and security of a screen locking application as complex 
as a window manager.

 Wouldn't it be much simpler if those accesibility windows had some property 
identifying them, but it would be the screen locking application that would 
take care of their stacking and similar things? (Not that this would be that 
secure either - anybody could set that property then, and get around the 
locking.)

 That way, those windows would be kept above the locking screen. The input 
events would probably have to be forwarded to them, mouse events should be 
simple, keyboard would be more difficult.

[snip]
-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/