Re: WM enhancements to support accessible screen lock

[Brian Cameron <Brian Cameron Sun COM>]

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

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.

There was still debate regarding whether the GrabKeyboard was necessary
at lock screen time.  Generally people agreed that the GrabPointer could
safely be removed.  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.

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.

Thanks!

--

Brian