Comment 3 for bug 938076

Given the security implications for users who do use full-disk encryption, I strongly object to "wishlist" importance here -- this represents a major regression, in my mind (and for my personal machines), which will force me to work around in an annoying way if it is not fixed.

In addition, I would argue that autologin is entirely the wrong setting to look at here. Instead, if a user has configured the screensaver to lock the screen when idle, then the machine should also lock on suspend, and vice versa. This is certainly the behavior I had always assumed Ubuntu had, and am surprised to hear it is not.

Autologin is a *very* poor proxy for "Is the state of this machine while suspended worth password-protecting?". Encrypted disks are an obvious reason, but there are also things like keys stored in the keyring that a user has decrypted once with a password, but are now stored in-RAM in the clear. Similarly, networked credentials like Kerberos tickets might be present on a suspended, that would not be present if an attacker rebooted the machine.

There is also the simpler issue of social conventions and expectations -- My roommates and I might leave laptops around shared space in an apartment with the implicit convention of "If the screen is locked, don't use it; but if it unlocks when you poke it, feel free to use my web browser to look something up". In such a case, the lock screen is not a security mechanism at all, but just a social indicator of the expected use for this laptop. Currently, I can control the lock behavior if the machine is left idle for five minutes via the screensaver; Why should I not be able to do so when the machine suspends? Or, even better, why should it not be the same setting?