Re: WM enhancements to support accessible screen lock

[Brian Cameron <Brian Cameron Sun COM>]

Lubos:

Lubos Lunak wrote:
> On Wednesday 24 of September 2003 22:34, Brian Cameron wrote:
>  > Lubos:
>  >
>  > Lubos Lunak wrote:
> [snip]
>  > >
>  > >  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).
>  >
>  > Could you give an example of a global keyboard shortcut that would allow
>  > a problem behind the lockscreen window to grab focus.  It seems to me that
>  > the window manager could enforce that no prograb behind the lock screen
>  > window could get key/mouse focus under any circumstance.  But since you say
>  > otherwise, I must be overlooking something.
>
>  For example KDE's Ctrl+Alt+Esc, which provides the same functionality like
> xkill. Just press it, click on the screensaver window -> boom, lock is gone.
> This one is actually provided by the window manager, so that could be handled
> I guess. A different example might be a keyboard shortcut for logging out -
> KDE has both shortcut for direct logout without asking, and even with asking,
> the logout dialog actually performs grabs. Moreover it's not handled by the
> WM, so that's another problem.

Yes, I think it would be fairly reasonable to expect that the screensaver
could turn off special keys like Ctrl+Alt+Esc.  Perhaps the window manager
could set a message such as WM_SCREEN_LOCKED, and other programs could honor
this setting and disallow features like "direct logout" if this is set.  This
seems like a reasonable workaround.

>  Such things probably could be handled, but would it be possible to handle
> them all, and the effort be worth it?

I think so.  Remember that without doing this work that people with
disabilities will simply be unable to lock their screen.  To support such
users, the work is necessary and, I think, worth it.

>  >  > 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.
>  >
>  > Please share your doubts in more detail.  Your current concerns seem a
>  > little vague to me.
>
>  See above. Basically, window managers may be complicated applications, much
> more complicated than the locking ones, and it would take much more work to
> make sure it's done properly. You'd need to handle this, and take care of
> that, and not forget also that, and so on. That's why I don't like this -
> window managers are complicated enough even without it.

However, it is precisely the features of the window manager that make
supporting accessible appliation at lock screen time possible, so I think
that the extra complexity might be worth the ability to support people
with disabilities.

>  > >  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.)
>  >
>  > Yes, it really doesn't matter if the screen lock program or the window
>  > manager controls whether the AT programs stay on top.  Either way, though,
>  > I think we still need to create the appropriate WM specification for
>  > indicating what programs must remain on top.
>  >
>  > I recommend that the WM_TYPE_VISIBLE_WHEN_SCREEN_LOCKED message is only
>  > honored if it is set before the window is first shown on the screen (and
>  > managed by the window manager).  In other words, this message should not
>  > be dynamic.  The value of the message is set when a program starts, and
>  > changing it will have no effect.
>  >
>  > I would also recommend that no window that is started while the lock
>  > screen is displaying is ever shown on top of the lock screen, even if
>  > the WM_TYPE_VISIBLE_WHEN_SCREEN_LOCKED message is set.  This would prevent
>  > a malicious person from changing a window's
>  > WM_TYPE_VISIBLE_WHEN_SCREEN_LOCKED value and getting it to appear in front,
>  > or starting new applications and getting them to appear in front.  In other
>  > words, *only* programs with the WM_TYPE_VISIBLE_WHEN_SCREEN_LOCKED message
>  > set that were running before the user locked their screen should be allowed
>  > to be visible above the screen lock program.
>  >
>  > I think this makes things reasonably secure, since the user should be
>  > able to immediately identify any problem when they lock their screen.
>  > Also, I think that windows that have the WM_TYPE_VISIBLE_WHEN_SCREEN_LOCKED
>  > message set should be visibily different than other windows.  Perhaps with
>  > a different colored border, for example, or with a keyword in the window's
>  > title.  This way any such program can be immediately and easily identified
>  > as a program that will be visible when the screen is locked
>
>  This sounds better, even though I'm not sure if security concerned people
> would find this acceptable ... not that I'm one of them.

One thing worth remembering is that this solution is geared towards people
with disabilities who cannot use currently existing lock screen programs.  The
paranoid can use other products to lock their screens, if they felt they were
more secure.  Obviously there is a risk that their may be explots that could
disable a window-manager based lock screen.  However, I think that such issues
are addressable and a window-manager based lock screen could be made sucure.

I am very interested to hear from Havoc his thoughts about how realistic he
thinks this sort of approach would be.

>  Technically, it's probably not necessary to have special window type for such
> windows. I think it should be just enough to have one extra property
> KEEP_ME_ABOVE_LOCK or something like that. The locking application would just
> search all toplevel windows including override redirect ones, and take care
> of their stacking order. Hmm, no, that wouldn't work with non-override
> redirect ones, the WM would win. If that actually matters.

Bill Haneman pointed out to me that the WM_TYPE_VISIBLE_WHEN_SCREEN_LOCKED
or WM_KEEP_ME_ABOVE_LOCK aren't really good names, since there are other
situations where AT programs should be kept above various windows.  For
instance during the logout or when override-redirects are posted, etc.
The GNOME logout dialog is a good case in point.

I notice that David Bolter from the GOK team posted an email where he
suggested using _NET_WM_STATE_ABOVEALL, which seems a good alternative to me.

>  Perhaps we then could have special window type for such accessibility tools
> and similar windows, that should be always on top no matter what. What do
> others think?

Either a window type as I suggested earlier, or a window state as David Bolter
suggests.  I am not sure which makes the most sense.  Perhaps someone can
advise.

>  > >  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.
>  >
>  > Yes, a mechanism more sophisticated that the current grabs will likely
>  > be necessary to support an AT program like GOK.
>
>  Do any of those tools actually need keyboard input?

Currently the only program that needs to be above the lock screen in the
window stacking order is GOK.  GOK requires only mouse input, and not keyboard
input.  Therefore, we could perhaps get by with only mouse input.  However,
in the general case, there will likely be future AT programs that also require
key input.  On one hand, it might be good to just add key support now, so that
things just work later.  On the other hand, it is probably the best option to
just get things working for mouse input right now and add keyboard input
when and if it becomes needed.

--

Brian