[UIFe]Auto-lock on suspend is still needed when encrypting file system

Hmm, I expected launchpad to ask me about the version number of the software and the release that is affected. Apparently, it doesn't do that.

So, here we go:

gnome-settings-daemon-3.3.90

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu precise (development branch)"

Status changed to 'Confirmed' because the bug affects multiple users.

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?

Ubuntu has always let the user disable the automatic screen lock without having an impact on locking when using suspend. When this stopped being the case, we had a lot of complaints which led to different patches being attempted. It seems there are a few different use cases:

1- User wants password to login, wants the screen to lock automatically at periods of inactivity, and wants screen to lock on suspend.

2- User wants a password to login, but doesn't want screen to lock automatically because typing in a password multiple times a day is annoying, but if suspending the laptop, wants the screen to lock as the laptop may be travelling.

3- User uses autologin, doesn't want the screen to lock, doesn't want the screen to lock on suspend.

4- User uses crypto disk with password on boot, uses autologin, wants the screen to lock automatically, wants the laptop to lock on suspend.

5- User uses crypto disk with password on boot, uses autologin, doesn't want the screen to lock automatically, wants the laptop to lock on suspend.

Clearly grouping all of these scenarios into upstream's single "lock-enabled" setting isn't enough.

6- User wants password to login, doesn't want the screen to lock automatically, doesn't want the screen to lock on suspend (yes, some people have requested this)

How about if the brightness and lock applet got the "Lock" slider changed to "Lock on suspend", and the "Lock screen after" drop down always stayed active and had a "Never" entry?

Ccing mpt for input, hey Matthew, what do you think about Marc's proposal?

> if a user has configured the screensaver to lock the screen when idle, then the machine should also lock on suspend, and vice versa.

No it should not, lot of people don't need their computer to lock just because they are in a call at their desk and don't type on the keyboard to 15 minutes but they still want to lock it when closing the lid or suspending before going away later on

@Mark, that would work for me but I would prefer to get input from mpt on that ;-)

OK, I have had some more time to think this over. My proposal in comment #6 is very intrusive and would change a lot of upstream code this late in the cycle. Here is an even better proposal:

1- Add a new gsettings key called "lock-on-suspend", which defaults to true. This would revert us back to Oneiric behaviour

2- If we can get a UI exception, we simply add a new toggle switch to the brightness and lock applet with a "Lock screen on suspend" label

This should take care of all the usage scenarios, while minimizing the changes to the upstream gnome code.

mpt, would that be acceptable?

Please correct me if this summary of the problem is wrong:
1. If startup requires a password, waking from suspend should require that password too.
2. However, Ubuntu (unlike OS X, for example) isn't smart enough to tell or specify whether startup requires a password, let alone to use the same password automatically.
3. Therefore, Ubuntu should offer the next best thing -- an extra option to require your login password when waking from suspend.
4. Turning on this option should not also require entering your password when returning from the display turning off, because that's much more likely to be a momentary accident than going into suspend is.

If that summary is correct, the main problem is the step from 2 to 3. You would have to enter one password when returning from suspend, and a different password in a different UI when returning from hibernate, and that would be silly.

If that's the way you want to go, though, here's a sketch of how it could be presented in the current panel. (Disclaimer: this sketch is not an endorsement of the idea of putting brightness and lock settings in the same panel, which is obviously bonkers. I'm assuming moving them at this point would be too invasive.)

Behavior notes:
- Whenever "Turn off the screen when inactive" is unchecked, its own menu and "Turning the screen on again" should both be insensitive.
- Whenever "Turn off the screen when inactive" is checked, the "Inactive for:" menu should not contain any periods shorter than the current "Turn off the screen when inactive for:" value, because they would have no effect. And if the previous selection was one of the values that is removed, "Inactive for" should become unchecked.

Yes, that would accurately describe scenarios 4 and 5, when someone is using full disk encryption. Of course, someone who _is_ using full disk encryption would probably argue that they _want_ a different password for encryption than for their login password for security reasons, unlike OS X that only uses a single password.

However, scenario 2 also requires more than one user preference for screen locking, so we aren't just working around startup (encryption) passwords.

I like your proposed design, and it would fix the issue for all scenarios.

Since we are late in the cycle, we have come to a compromise for precise, until the dialog gets a proper redesign in P+1:

<mpt> mdeslaur, seb128: A minimal option would be to leave the current design and add one more checkbox
<seb128> mpt, what would the box say?
<mpt> mdeslaur, seb128: "Require my password when waking from suspend"
<seb128> works for me

OK, I have uploaded test packages to add the new settings to my PPA here:

https://launchpad.net/~mdeslaur/+archive/testing

Attached are the proposed debdiffs, and a screenshot of the applet with the new option.

I would like to request a FeatureFreeze and a UserInterfaceFreeze to correct this bug.

The only way of correctly locking the screen on suspend that complies with all the use cases is to add an extra option to the control center applet. See the attached screenshot.

The attached debdiffs are minimal, and are simpler than the logic we had before of automatically following autologin.

Sent notification to ubuntu-doc and ubuntu-translators:

https://lists.ubuntu.com/archives/ubuntu-doc/2012-March/016410.html
https://lists.ubuntu.com/archives/ubuntu-translators/2012-March/005204.html

<ScottK> mdeslaur: For your screen locking UIFe you need to inform the docs and translation teams about it.
<ScottK> Other than that, I think it's good.
<mdeslaur> ScottK: I've sent emails to their list ....

Approved contingent on you being willing to provide any updated screen shots the docs team might need (I think it's unlikely.

Hey! This is trivial but important: use a checkbox instead of a GtkSwitch, since the switch is not aligned with anything on the screen and accorging to Gnome HIG a checkbox is more appropiate in this cases.

This bug was fixed in the package gsettings-desktop-schemas - 3.3.90-0ubuntu2

---------------
gsettings-desktop-schemas (3.3.90-0ubuntu2) precise; urgency=low

  * debian/patches/ubuntu_overlay-scrollbars.patch:
    - define "org.gnome.desktop.interface ubuntu-overlay-scrollbars" to
      let disable the overlay scrollbars, thanks Andrea Cimitan
      (lp: #934123)
  * debian/patches/ubuntu_lock-on-suspend.patch:
    - use ubuntu- prefix to avoid downstream,upstream confusion
    - the key is "org.gnome.desktop.screensaver ubuntu-lock-on-suspend"

  [ Marc Deslauriers ]
  * debian/patches/ubuntu_lock-on-suspend.patch: Add a new preference to lock
    the screen when the system suspends. (LP: #938076)
 -- Sebastien Bacher <email address hidden> Fri, 09 Mar 2012 15:42:58 +0100

Ah, yes, a checkbox would look better than a GtkSwitch.

Attached is an updated debdiff and screenshot for g-c-c that uses a checkbox instead of a switch, greatly improving the layout.

This bug was fixed in the package gnome-settings-daemon - 3.3.91-0ubuntu3

---------------
gnome-settings-daemon (3.3.91-0ubuntu3) precise; urgency=low

  * debian/control.in:
    - updated gsettings-desktop-schemas requirement for the lock key
  * debian/patches/61_unity_use_application_indicator.patch:
    - updated indicators ids, combined with the libappindicator new version
      that should give the correct wm_class to the fallback gtkstatusicon
      which should fix some gnome-shell issues (lp: #878951)
    - use set_icon_full() with "Keyboard" as a11y description (lp: #740726)

  [ Marc Deslauriers ]
  * Add a new preference to lock the screen when the system suspends.
    (LP: #938076)
    - 51_lock_screen_on_suspend.patch: use lock-on-suspend gsettings to
      determine if screen should be locked.
    - 51_always_lock_screen_on_suspend.patch: removed.
    - 54_lazily_connect_to_screensaver.patch: refreshed.
    - 60_unity_hide_status_icon.patch: refreshed.
 -- Sebastien Bacher <email address hidden> Fri, 09 Mar 2012 18:25:40 +0100

This bug was fixed in the package gnome-control-center - 1:3.3.91-0ubuntu3

---------------
gnome-control-center (1:3.3.91-0ubuntu3) precise; urgency=low

  * debian/patches/04_new_appearance_settings.patch,
    debian/patches/63_normal_scrollbar_in_a11y.patch:
    - disable overlay scrollbars with a11y themes by setting the gsettings
      to false, thanks Andrea Cimitan (lp: #934123)

  [ Marc Deslauriers ]
  * debian/patches/99_add_lock-on-suspend.patch: Add a new preference to
    lock the screen when the system suspends. (LP: #938076)
  * debian/control.in: bump gsettings-desktop-schemas Depends
 -- Sebastien Bacher <email address hidden> Fri, 09 Mar 2012 19:41:38 +0100

Thank you Marc!

Thanks for the suggestion Fitoschido :)

Somehow, this doesn't work for me. "ubuntu-lock-on-suspend" is enabled, but the screen is not locked. How can I debug this issue?

@Whoopie: could you please open a new bug for your issue, this bug is currently closed.