The idea was to plan an experiment together, with both of them agreeing on every single tiny detail. They would then go to a laboratory and set it up, again both keeping close eyes on one another. Finally, they would conduct the experiment in a series of different batches. Half the batches (randomly assigned) would be conducted by Dr. Schlitz, the other half by Dr. Wiseman. Because the two authors had very carefully standardized the setting, apparatus and procedure beforehand, “conducted by” pretty much just meant greeting the participants, giving the experimental instructions, and doing the staring.

The results? Schlitz’s trials found strong evidence of psychic powers, Wiseman’s trials found no evidence whatsoever.

Take a second to reflect on how this makes no sense. Two experimenters in the same laboratory, using the same apparatus, having no contact with the subjects except to introduce themselves and flip a few switches – and whether one or the other was there that day completely altered the result. For a good time, watch the gymnastics they have to do to in the paper to make this sound sufficiently sensical to even get published. This is the only journal article I’ve ever read where, in the part of the Discussion section where you’re supposed to propose possible reasons for your findings, both authors suggest maybe their co-author hacked into the computer and altered the results.

But time engaged in indoor sports had no such protective association; and time outdoors did, whether children had played sports, attended picnics or simply read on the beach. And children who spent more time outside were not necessarily spending less time with books, screens and close work.... Close work might still have some effect, but what seemed to matter most was the eye's exposure to bright light.

why are you letting jwz do your thinking for you?

If you disagree, please address why security is something that should be handled by screensavers, instead of the display manager.

So, you want xscreensaver to invoke the "unlock dialog" program and wait for a response. The unlocker would use a GUI toolkit, and would be linked against the various security libraries. Perhaps the way it would work is that it would print either "yes" or "no" on stdout, depending on whether a password was correctly entered. Were it to crash, the daemon would take that that to mean "no"...

In fact, this approach would actually reduce the number of libraries (and thus, lines of code) in the daemon itself, since the daemon would not need to link against things like PAM and crypto. That's a good thing.

So that doesn't sound hard so far, except that the xscreensaver daemon has the keyboard grabbed. It's pretty important that it hold that grab, because otherwise keystrokes tend to go "through" the xscreensaver window and reach random desktop windows underneath.

This [raises] the question of, how do the keystrokes get to the unlock dialog at all? That's a difficult question. Understanding how to do that right requires a lot of knowledge about X (which I have) but also probably a lot of knowledge about foreign-language input methods and screen readers and other accessibility-ware (which I do not have.) ...

In the current system, where the same process is the creator of both the screen-blanking window and the unlock dialog, this is not a problem: that process gets all the events it wants. But when they are in different processes, we need a way for the keyboard and mouse events to get to the process driving the unlock dialog. So you'd like to transfer the grabs from the xscreensaver daemon to the unlock dialog, and then transfer them back afterward. Unfortunately, there is no way to transfer grabs atomically in X. ...

Another possibility is for the xscreensaver daemon to keep its grabs, meaning that all keyboard and mouse events would go to it; but then for it to use XSendEvent() to generate synthetic events on the lock dialog window. That is, the xscreensaver daemon would read a KeyPress, and then would simulate an exact duplicate of that KeyPress on the lock dialog window.

[arguments against this: Applications can tell the difference between real and synthetic events, so might reject synthetic events as a security measure. Input methods need to be embedded in the dialog, rather than as a separate window] ...

In Summary

Making the xscreensaver unlock dialog securely use a toolkit is difficult, but possible, were a knowledgeable person to do the work. If the work were done well (by which I mean: clearly commented and documented, and with obvious attention paid to the security implications) I would be happy to incorporate those changes into the xscreensaver distribution.

Making the unlock dialog also be able to take advantage of accessibility tools is probably a lot harder. I don't know how much harder, because I'm not an accessibility expert. But anyone intending to implement that had better be both an expert on accessibility, and well versed in secure X11 programming, because the security implications of getting it wrong would be dire indeed.

That's why I implemented the unlock dialog using only Xlib: not because I think Xlib is a good way to write user interfaces, but because I think this was the safest way. The amount of code in Xlib is very small, and has been extensively security audited. It is very unlikely that there are crashing bugs lurking in Xlib itself. The same cannot be said for larger, more featureful libraries. So, by making minimal use of Xlib (the dialog box is drawn using only the lowest level text-printing and rectangle-drawing routines) we can keep the code path short and auditable.

I am as close to certain as I can be that there is no action a user can take on their input devices that will cause the current Xlib-based lock dialog in xscreensaver to unlock. That's because it's a small amount of code that I have stared at and tested for a very long time. It is a small enough piece of code that I (believe I) know every possible path through it.

Introduce N layers of widget library, general text field handling, compose processing, input methods, I18N... and all bets are off. Who knows what bugs wait lurking in there; who knows which particular combinations of which libraries are a security-bug timebomb.

Let me put that another way:

The GTK and GNOME libraries have never been security-audited to the extent that their maintainers would be willing to make the claim, "under no circumstances will this library ever crash."

One can, within a reasonable doubt, make that claim about libc, or even about Xlib, but not about anything the size of GTK. It's just too big to be sure. This is not a criticism of GTK or GNOME or their authors: it's simply a truth about any piece of software of that size.

Like GNOME, KDE also decided to invent their own screen saver framework from scratch instead of simply using xscreensaver.

Guess what, they did it again! Ubuntu Unity's screen-locking framework is yet another rewrite, and it is completely broken, bug-ridden and insecure. At this time I don't have any information on how to turn it off and use xscreensaver instead. If you do, let me know.