https://bugs.kde.org/show_bug.cgi?id=448525
Bug ID: 448525
Summary: Set a maximum volume and maximum volume increase to
prevent physical harm (ear damage)
Product: plasma-pa
Version: 5.18.8
Platform: Debian stable
OS: Linux
Status: REPORTED
Severity: critical
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected]
Target Milestone: ---
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
--
You are receiving this mail because:
You are watching all bug changes.
