Re: WM enhancements to support accessible screen lock

[Lubos Lunak <l lunak suse cz>]

On Tuesday 07 of October 2003 01:03, Brian Cameron wrote:
> Last month, there was some discussion regarding how accessible screen
> locking can be supported.  Although there was some debate regarding whether
> it is best for the locking to be managed by the window manager or a
> separate screen locking program.
>
> Either way, however, I think it was pretty much agreed upon that new window
> manager extensions would be needed in order to make clear which programs
> need to be visible on top of the screen lock program.  There were basically
> two
>
> David Bolter, the GOK maintainer had the following suggestion of adding
> a WM_STATE "_NET_WM_STATE_ABOVEALL indicates that the window should be
> on top of all windows, to be used when there would be disastrous results
> if the window were occluded"
>
> And the stacking order text might read:
>
> "Stacking order
>
> To obtain good interoperability between different Desktop Environments, the
> following layered stacking order is recommended, from the bottom:
>
>      * windows of type _NET_WM_TYPE_DESKTOP
>      * windows having state _NET_WM_STATE_BELOW
>      * windows not belonging in any other layer
>      * windows of type _NET_WM_TYPE_DOCK (unless they have state
>        _NET_WM_TYPE_BELOW) and windows having state _NET_WM_STATE_ABOVE
>      * focused windows having state _NET_WM_STATE_FULLSCREEN
>      * focused windows having state _NET_WM_STATE_ABOVEALL
>
> Windows that are transient for another window should be kept above this
> window.
>
> The window manager may choose* to put some windows in different stacking
> positions, for example to allow the user to bring currently a active window
> to the top and return it back when the window looses focus.
>
> *Except in the case of _NET_WM_STATE_ABOVEALL which must never be occluded

 I think this except clause is not really useful, as you should never say 
never :).

>
> In the case of multiple windows with _NET_WM_STATE_ABOVEALL, the most
> recently active window wins. This state should be used sparingly for such
> things as on-screen input software and screen magnifiers."
>
> It was also recommended that the _NET_WM_STATE_ABOVEALL would only be
> honored if this message were set before the screen is actually locked.  In
> other words, if the state is changed to _NET_WM_STATE_ABOVEALL after the
> screen is locked, that window would not be visible.  This would prevent a
> hacker from changing the state of a particular window and getting it to
> appear above the lock screen.
>
> It was also suggested that there should be a window manager message to
> indicate that the screen is currently in a locked state.  This message
> could be WM_SCREEN_LOCKED.  Other programs could listen for this message,
> and turn off certain features when the screen is locked.  For example, a
> program like GOK or Gnopernicus could turn off the ability to change
> preference settings in order to prevent a malicious user from changing the
> preferences to an unusable state for the person who locked the screen.
>
> Lastly, it was suggested that somehow windows that are of type
> _NET_WM_STATE_ABOVEALL should be visibly distinct from other windows.
> This way the user is always clear about which windows will be visible
> even when the screen is locked.  Perhaps there could be an additional
> icon in the menubar that indicates this state.  I would be open to
> suggestions here.

 Maybe this state should be rather a window type?

>
> There was still debate regarding whether the GrabKeyboard was necessary
> at lock screen time.  Generally people agreed that the GrabPointer could
> safely be removed.

 I can do a lot of things with just the mouse in KDE3.2 as long as it's not 
grabbed, regardless of what's visible on the screen. Moreover, the reasoning 
that grabs are actually useless was based on claiming that one can run apps 
that will get some information about the input even if the pointer is locked. 
However, I fail to see how such apps could be run with input grabbed (and if 
somebody lets somebody else to run it while the screen is not locked, it's 
not really the lock's problem). 

>  Since GOK is currently the main program that requires
> lock screen support, and since GOK only requires pointer input, then it
> seems like we might be approaching a solution that allows on-screen
> keyboards to be used at login time, which would be a big step in the
> right direction.
>
> There was debate regarding whether or not it would be more appropriate
> to have the screen lock handled by the window manager, or by a standalone
> lock program that honored this proposed protocol.  I think this is an
> implementation detail and can be ignored at this time.

 I'm afraid it's not an implementation. If both the WM and the locking program 
decide to manage those windows, they'll clash.

>
> At any rate, this topic seemed to end a few weeks ago.  I wanted to
> summarize the current state of the proposal, and to hopefully get
> further feedback.

 I think it would be interesting to see at least some kind of proof of concept 
implementation of this. I'm still not very convinced that locking the screen 
this way would really work, and seeing it for real could help proving me 
either right or wrong.

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