On Mon, 2014-01-13 at 12:22 -0800, Adam Williamson wrote: > > ...where they have an actual point, which is to prevent accidental > > interaction with a 'live' interface 'behind' them. > > > > If the 'live' interface behind the shield is a password entry dialog > > which it's very unlikely you'll be able to do anything damaging to > > accidentally, and the OS is running on a device where accidental > > interaction with a UI is unlikely, it is unclear what benefit the shield > > is providing to anyone. > > Further note that on Android this behaviour is configurable, and I've > noticed that it's fairly common for people to configure it the way I do: > if you enable some form of actual device locking (a PIN, pattern lock, > whatever), you disable the 'shield' lock screen so you don't have to > double-unlock. I have my phone encrypted and set to always lock on idle > or power button press, so I have the 'drag across to unlock' shield-y > screen disabled as it serves no purpose for me, and just have the actual > unlock screen (PIN lock) do dual duty. > > What GNOME currently has looks a lot like mandatory double-unlocking, to > no obvious purpose: yes, you can clear the shield by hitting any > 'active' key, but most people do not appear to have got this message, > seeing as how these threads keep happening and we keep having to tell > people this fact directly (which is a method of information transmission > that doesn't really scale terribly well). In case anyone is looking for the reference, btw, the 'shield' design appears to be documented at: https://wiki.gnome.org/Design/OS/ScreenLock it defines the objectives as: Shield system from stray taps and clicks when locked Protect the security of the user's session Display important system status information (battery, network) Display the name of the user Display the current time Display important (defined by the user) notifications Display urgent system notifications (low power) Display personalized user content (background image) Provide access to media controls Provide access to display (brightness, etc) controls Use the preferred language, keyboard, and input methods for the user The page doesn't seem to explain _particularly_ clearly (at least, by my reading) what the shield/curtain actually provides that the "real" lock screen doesn't, when the user has a password or other form of actual lock mechanism to complete before actually accessing the running desktop. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
