Bug#1068829: Disabling the autostart of KDE Connect and screenreader KAccessible
Package: kde-plasma-desktop
Version: 5:142
These aren't needed for most users and are a privacy and security risk. In principle, it makes sense to only autostart things one actually needs to reduce the likelihood of crashes, the number of irrelevant log entries, the hardware resource consumption, and the attack surface (for example due to potential vulnerabilities in any of the software, especially if they constantly listen on some port).
Many people are looking for ways to disable these autostarts and don't like that they're just enabled by default, see for example https://unix.stackexchange.com/questions/384306/why-does-kdeconnect-listen-on-port-1716-tcp-all-the-time-how-to-close-the-port and https://discuss.kde.org/t/how-to-disable-kde-connect/7686/3 (there two devs clarified that this is not a KDE issue but "a distribution issue" which is why I'm filing it here).
I thought Debian was a distro with great regard for security and stability and that it considers privacy and actual user needs/practices.
A major issue with these autostarts is that there is no proper way to disable them. See https://unix.stackexchange.com/questions/774190/how-to-permanently-disable-autostarting-of-applications-on-linux-debian
These methods do not only require time and are inconvenient (it's not even clear which one to use), they also get reset when the packages get upgraded such as during a distro upgrade. KDE Connect constantly listens on some ports and according to the second link has been a known vector for a DOS attack.
I think "Calendar Reminders", screenreader "Orca", and "geoclue-2.0" also should not autostart but this issue is only about wireless file/device sharing app KDE Connection and KDE Accessible.
I don't think these autostarts were enabled to give people a reason to get educated on autostarts and autostart-prevention and to harden these two apps. If that's why they were automatically starting by default so far, then they should still be disabled now. If needed, the user could be asked if they want to have these autostart during initial installation.
Rather than bundling security-reducing bloat autostarts, I suggest that if these are installed by default at all, they are not configured to autostart. The user can easily configure them to autostart if they actually want that in the "Autostart" settings.
Reply to: