https://bugs.kde.org/show_bug.cgi?id=424118
--- Comment #10 from lestofant...@gmail.com --- I took a look at the XDG specification here: https://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html and there is no reference about user should or should not be asked for BUT after mount: > Autostart Of Applications After Mount > [...] > The desktop environment MUST prompt the user for confirmation before > automatically starting an application. so IMHO implementing a confirmation system is not against the XDG standard and not an horrible hack (that depends on implementation), as is quite clear the user can always disable the autostart by setting the Hidden flag; and automation of the process of discovery of new entry is just a nice feature (and actually potential security fix). I see how discussing with them for a correct/standardized solution can benefit > we will move to see more sandboxing of applications. I fail to see how this would help, if a sandboxed application want to autostart (and follow current XDG standard): - it always cant (bad user experience) - it always can (as of now) - ask the user (as proposed here) --------- also found the fanotify API: https://man7.org/linux/man-pages/man7/fanotify.7.html that can clean up the system proposed quite a bit, as it can intercept read/write/delete (not creation, but empty file should not be a problem), the advantage is the file permission and content does NOT need to change, so deletion of the file from the application will still work. @2wxsy58236r3: yes, a list of existing entry should be keep, and ideally also a list of "remember my decision" to avoid app that try to set those file in a loop to spam-bomb the user. If you used PrivacyGuard in Android to granular control permission, you probably know the issue -- You are receiving this mail because: You are watching all bug changes.
