SUMMARY With this command one can easily change the volume: > pactl set-sink-volume @DEFAULT_SINK@ +2% The command works even if audio is currently playing, is applied immediately and does not require sudo. The problem is that you can enter any value where it says 2%. This can cause physiological damage to humans. I'm surprised there aren't yet reports of people who got their ears damaged or even went deaf due to this. It allows you to configure the volume to be at any level above 100% even if "Raise maximum volume" is not checked in the settings (if it is checked it only displays the maximum volume to be 150% and limits the volume accordingly when changing it via the applet but doesn't affect changes via this command). Note that this command is fairly well known as it's often needed to change the volume via keyboard shortcuts or for example a mouse wheel. Maybe it was better if this bug was only visible to developers. It's more of a general GNU/Linux bug than a KDE/plasma-pa one and I thought about asking about this on unix.stackexchange.com but this way more people may become aware of this physical vulnerability before even KDE has implemented a solution and I think it could get solved preliminarily at the Plasma/KDE level. Like with many other security vulnerabilities, you don't necessarily have to have physical access to another person's computer (or GNU/Linux phone) to exploit it. It's very rare for vulnerabilities to have the potential to directly, rather than indirectly, cause physiological damage. This puts many people at risk. I intend to test this with a broken headphone later and see if it explodes, fries, caps the volume at a very high level, just stops working or none of these. I think this probably varies per value and headphone but I'll update this issue once I tested it. This doesn't require people to use headphones to be a physically dangerous bug, in fact without headphones it could cause physical damage to even more people at once. ___________ I probably can't overstate how important this vulnerability is: I think this is the one and only most severe known issue that GNU/Linux currently has. I think it's in a category of severity of its own in which only issues as severe as the recent Log4j security vulnerability are. I don't think I created any issue anywhere so far that I classified to necessarily have a severity anything higher than "normal". I think it's a necessity that this issue is solved before widespread adoption (I think I also had this as a "barriers to adoption" at the bottom of https://myndstream.github.io/Switch2Linux/dist/spa/index.html#/). While I'm all for a larger market share of desktop GNU/Linux and measures to increase adoption, even I could agree with that this isn't a good idea/goal if this issue remains unsolved. I'm slightly ashamed that the GNU/Linux community(ies) hasn't addressed and solved this yet (and I couldn't even find bug reports about it, albeit I didn't research it for long). You could also comment here to name other repo/s where this issue should be raised. Maybe there are also other commands that can also raise the volume to very high levels (in cases where PulseAudio isn't used). Due to the importance of this bug, I apologize for probably having phrased it suboptimally and for not filing it earlier. STEPS TO REPRODUCE 1. Read this warning: reproducing this bug could cause physiological damage so don't test it. I'm not liable for any damage caused by this and this report may be needed for solving this problem. 2. On Debian11/KDE run pactl set-sink-volume @DEFAULT_SINK@ +4% in the console while audio (like music) is playing or without *ALL* notifications being disabled. OBSERVED RESULT No constraints on the (maximum) volume and (maximum) rate of volume increase for volume changes via this command. EXPECTED RESULT A set by-default maximum volume (like 200%) and a by-default maximum volume increase (like 50% per 2 seconds) which can only be raised up to a maximum volume (like 400%) and maximum volume increase (like 70% per second) using sudo (maybe via the plasma-pa GUI which could prompt the user for the sudo password when these settings are changed). The maximum for notification sounds should probably be lower and implemented separately. Disabling all notification sounds with an easy-to-find and reliable setting would be a separate issue (for example I noticed that one has to separately disable "Play audio feedback for changes to: Audio volume" in plasma-pa even when notification sounds are already supposed to be turned off). Maybe it would also be good if there was a warning icon in the taskbar and/or a notification when the volume was changed to a level beyond a limit and/or a prompt that one needs to confirm whenever one raises the volume to anything above a certain limit but still beneath a certain limit. Even if this gets implemented on a GNU/Linux level, there could be additional Plasma constraints, like those described here, that are applied (as a second layer of protection) as long as these GNU/Linux limits don't take effect. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian 11 KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 plasma-pa: 5.20.5-1 ADDITIONAL INFORMATION
> It's more of a general GNU/Linux bug than a KDE/plasma-pa one Indeed. There isn't anything we can do about this in KDE, unfortunately. The diversity of hardware available to people ensures that there isn't a "one size fits all" maximum volume that we could impose. Some people have loud honkin' speakers that can blow out your eardrums, for which a maximum volume below the physically possible maximum volume might be a good idea. But some people have weak laptop speakers that you have to crank up to 150% volume just to hear anything. I would recommend you start a conversation at a lower layer of the audio stack, possibly with the PulseAudio or PipeWire developers.
(In reply to Nate Graham from comment #1) > I would recommend you start a conversation at a lower layer of the audio > stack, possibly with the PulseAudio or PipeWire developers. Done: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1331 I haven't tested this with PipeWire. I still think there should be a limit on the KDE level. Then there could be additional security precautions on the level of pulseaudio and a third limit in the operating system / kernel. This way even if one limit fails or gets maliciously changed/removed there would be additional measures that make sure that physiological harm is prevented.
I'm considering creating a new issue about this (more or less): on the KDE level there could still be measures that could help prevent physiological harm (ear damage) beyond volume and volume-increase limits: for example there could be forms of notifications that warn the user when the volume is very loud or gets/got increased a lot.
We won't do that for the same reason I already gave you: we have no way of measuring the *actual* volume because all audio hardware is different, so a "this might be too loud" notification could be misleading and would definitely be annoying to pretty much everyone who isn't you. :) Did you suffer ear hearing damage from the volume on your computer being too loud at some point?
(In reply to Nate Graham from comment #4) > We won't do that for the same reason I already gave you: we have no way of > measuring the *actual* volume because all audio hardware is different, so a > "this might be too loud" notification could be misleading and would > definitely be annoying to pretty much everyone who isn't you. :) Measuring the *actual* volume is absolutely unnecessary to solve this. It's already capped at 150% in the GUI so the notification could only show at 200% which you can't even configure without running the command above. Scenario 1) a person gains remote access to a computer but does not have root access to it: he can directly and easily cause physiological harm with this Scenario 2) a person gains physical access to a computer but does not have root access to it: he can directly and easily cause physiological harm with this Scenario 3) a person gains physical access to a mobile phone running GNU/Linux but does not have root access to it: he can directly and easily cause physiological harm with this
These are extraordinarily unlikely scenarios, and if a nefarious person has unauthorized remote root or unauthorized non-root local access to the machine, you're already screwed in 500,000 other ways too. It's like if there are already armed intruders in your house; you're way beyond the point of notifications and warnings being heplful. The solution is to prevent unauthorized access of that sort from happening.
(In reply to Nate Graham from comment #6) > These are extraordinarily unlikely scenarios What? They aren't. There's way more effort in preventing other kinds of vulnerabilities that require prior access to a machine such as all privilege escalation vulnerabilities such as the recent PwnKit. Not only that but you could also leave your phone unattended but unlocked for a few seconds or some roommate may want to do a "prank" etc. This is more than irresponsible. > and if a nefarious person has unauthorized remote root or unauthorized non-root local access to the machine, you're already screwed in 500,000 other ways too. It's like if there are already armed intruders in your house; you're way beyond the point of notifications and warnings being heplful. The solution is to prevent unauthorized access of that sort from happening. Completely false too: here you can still limit the damage. For example, we still have things like laws and law enforcement which (among other things) can mitigate the amount of damage in this scenario, *especially* if that particular damage is theoretically very easy to inflict for basically everyone (no advanced tech-skills required or alike) and can directly cause large physiological damage (while other damage may not be physiological or often end up not causing harm).