Laptop with dark screen and keyboard

Lock screens really should have keyboard input protection

Do you press the Enter key two–three times to wake up your computer? Or maybe you press Enter and then proceed with entering your password without waiting for the screen to come on? It’s really easy to inadvertently accept dialogs or send your password off somewhere it doesn’t belong as lock screens aren’t doing much to protect users.

I’ve got some bad keyboard habits when I sit down in front of a keyboard and a powered off screen. I usually either press Enter once, type my password, and then press Enter again; or I press Enter two–three times. The problem with both of these habits is that my screen isn’t always locked it may just be powered down. So I’m either blindly typing in my password somewhere I shouldn’t or dismissing dialogs I haven’t had a chance to read by repeatedly pressing Enter. For some reason, I never randomly click with the mouse or touchpad as I’m worried I’ll click on something I didn’t mean to by accident. I’ve got no idea why I treat the mouse and keyboard so differently in my computer-wakeup routine, but I never use the mouse. I don’t believe I’m alone in having these this kinds of system wake-up rituals, and I believe lock screens should do a better job in catering to their impatient users.

During the week when I was thinking of writing this article, I managed to send my login password onto an IRC chat room and type it into Bing web-search from the Windows Start menu. I also triggered a system update of my Mac that took 20 minutes to complete when I just wanted to check something quickly. These incidents happened even while I was hyper-aware of and actively thinking about these issues. I don’t trust my computer to wake up from hibernation the first time I press Enter, so I press the key two or three times out of habit to be sure.

Randomly accepting dialogs probably doesn’t seem like a big deal to many. However, it can be very inconvenient when the consequence is a 10–40-minute session of reboots and system updates; or when you accept installing some unwanted bundled software/crapware you never asked for. I’ve actually ran into this situation once where I had to reschedule a presentation because I thought I unlocked a MacBook but actually started a firmware update instead. Situations like this really doesn’t come off as very professional.

The crux of the issue here is that a powered-off screen could mean the computer is in one of many states. The screen or computer could be powered off or in another power-saving mode, the screen could be locked; unlocked; or in a grace period in between the two, or it could of course be set to the wrong input source if it’s an external monitor. Users have no indicator of what state the screen is in and no idea whether it will be locked or not. There are a few safe keys you can press to wake up a system, but the Caps Lock and Control keys are usually much smaller than Enter and Space. It can take one–four seconds to power on a screen out of power-saving mode, yet the operating systems usually accepts user input right away. Unless the computer was sleeping or powered off too, then it can take a little longer to for the computer to accept any more input than the wake up signal.

I believe a operating systems should handle this situation much better so that they actively prevent accidental password disclosures and unintentional input and interactions. For example, the window manager should refuse any mouse or keyboard events for the first one–three seconds after waking up the screen to give it time to actually power on and to give their human operators time to actually see what is going on on their screens. Maybe requiring the user to either wait some seconds or click on the password input field or press Tab to focus it to cancel the input time-out.

There is of course a huge risk of making this a frustrating experience for users who all want instantaneous reaction times and satisfaction from their computers. Anything that gets in the way of that experience risk being hated pretty universally. The impact of temporarily refusing to accept user input could be somewhat reduced by providing clear visual and audible feedback. For example by playing the action-not-allowed sound (the familiar “funk” and “thud” sounds) for every ignored key press, and by simultaneously blinking the three LED lights located on the keyboard two times.