Bug 369181

Summary: User session security vulnerability from screen lock being suppressed with power management
Product: [Plasma] Powerdevil Reporter: Boskote <boskote>
Component: generalAssignee: Plasma Development Mailing List <plasma-devel>
Status: RESOLVED WORKSFORME    
Severity: major CC: kde, thomas.pfeiffer
Priority: NOR Flags: kde: Usability?
Version: 5.6.4   
Target Milestone: ---   
Platform: Debian testing   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Boskote 2016-09-22 03:33:42 UTC
The problem is that applications (in my experience it has only been browsers, both firefox and chromium) request that power management be suppressed, which overrides an automatic screen lock timeout configured through power management. On its own this behaviour makes sense, but it can result in a silent failure of the timed automatic screen locking, which is a significant vulnerability for users who are depending on the auto screen lock for the security of their session. 

This problem is exacerbated by poorly designed websites that get the browser to request power management suppression for reasons that are not obvious to the user (a background webRTC PeerConnection in chromium is the recent example I saw).

I would expect that there would be an externally visible notification of when this suppression of power management occurs, so that a user who is depending on screen locking will be aware that it has been disabled. Alternatively, there could also be a way of configuring power management to override the suppression requests for users who value screen locking (and other power management features) over the convenience of the automatic suppression. 

It is possible to click on the "Battery and Brightness" tab of the system tray to see a message about suppression of power management, but there is no externally visible notification when the suppression occurs. It is too tedious to periodically click into this area to check if there is a suppression. 

It is also possible to configure a button or keyboard shortcut for quick screen locking and do this manually just in case the automatic screen lock is being suppressed. This is the workaround I am currently using, but it is basically just a replacement for a timed screen lock that can't be trusted to work as configured. 

Reproducible: Always

Steps to Reproduce:
1. Use power management to configure a short timeout on the screen lock
2. Open a poorly designed website in chromium or firefox that makes background requests to suppress power management (some pages from http://www.laprensa.hn/ in chromium containing background webrtc peerconnections, for example). 
3. Get up and leave the computer with that tab open. See how long it takes for someone to realize you left your session open and start digging around in your stuff :p

Actual Results:  
The screen lock will not work because the power management is suppressed. 

Expected Results:  
Popped up a notification (or have the option to enable such a notification) as soon as the power management is suppressed so that the offending website tab could be closed, or the screen could be manually locked.
Comment 1 Kai Uwe Broulik 2016-09-22 04:22:35 UTC
Adding usability team.
Comment 2 Thomas Pfeiffer 2016-09-23 15:06:05 UTC
You are right. Actually, this is a problem which we have already identified and even discussed solutions (the favorite in the end seems to have been an icon showing up in the systray whenever power management (and therefore screen locking) is being suspended.
Comment 3 Justin Zobel 2022-10-24 00:46:54 UTC
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Comment 4 Bug Janitor Service 2022-11-08 05:10:50 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 5 Bug Janitor Service 2022-11-23 05:17:19 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!