Re: [DNG] KUserFeedback
Hi tito, tito via Dng writes: > [... snip ...] > What possible solutions are there to avoid this [KDE telemetry support] and > [its] > abuse? > > Simple workarounds that I can think off: > > 1) allow removal of KUserFeedback by modifying deb deps (rather ineffective > as most user will not care to do so) > > 1a) allow removal of KUserFeedback by modifying deb deps and don't install > by default unless the way data is collected is changed so that data > are collected only if opted in > > 2) if the user opted out make /home/user/telemetry a tmpfs so that data stored > are forgotten at reboot (easy but not very effective as data could still > be >abused in the meanwhile) > > 3) if the user opted out create some kind of /dev/null folder (I suspect that > such > thing doesn't exist yet) to delete the data in realtime > > 4) if the user opted out run cron jobs or other autostart scripts to > periodically > (boot, login, logout, hourly etc) delete this data > > Comments and better ideas are welcome. Not necessarily simple, but what about filing bugs (Debian) against any packages that you absolutely cannot live without that would be removed when you apt remove libkuserfeedbackcore1 (assuming chimaera and) assuming that your APT configuration does not aggressively try to remove automatically installed packages? If your APT does aggressively remove automatically installed packages, you may want to mark (some of) the ones you want to keep manual. Just an idea, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
Hi tito, tito via Dng writes: > On Sun, 5 Sep 2021 22:40:23 +1000 > wirelessduck--- via Dng wrote: > >> >> > 3) if the user opted out create some kind of /dev/null folder (I suspect >> > that such >> > thing doesn't exist yet) to delete the data in realtime >> >> Is the data saved into the telemetry folder before being transmitted >> anywhere? Can you just delete the folder and recreate it as a symlink to >> /dev/null? > Hi, > They say it is not transmitted by them unless you opt-in but it is stored and > other applications with the same user permissions > could read it and send it if they want to. So periodically deleting the data > could be a mitigation but is sub-optimal. > You cannot link a directory to /dev/null, only files. > > To create a directory equivalent to /dev/null you need something like: > > https://github.com/abbbi/nullfsvfs > > nullfs > > a virtual file system that behaves like /dev/null I'd give mkdir /home/user/telemetry chmod /home/user/telemetry a try first and a read-only filesystem mounted on /home/user/telemetry next. All the while keeping a crontabbed eye on directory content, of which there should not be any. # You need root privileges to look for content after the chmod. If preventing writes breaks your KDE Plasma desktop, something is badly mis-engineered. If it still manages to write stuff to that directory, something "evil" is going on, in that the telemetry stuff is using elevated privileges, and it may be time to use nullfsvfs. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
HI tito, tito via Dng writes: > [... snip apparmor misgivings ...] > > one stupid question that struck my mind right now could > apparmor control itself? Even if it could, would you trust it to do what you told it to? > could you write an apparmor profile to limit what apparmor > is doing? Just thinking out loud, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
tito via Dng said on Sun, 5 Sep 2021 09:52:11 +0200 >Hi, >while reading the latest edition of the PCLinuxOS Magazine, >I've found this interesting article about KUserFeedback >at https://pclosmag.com/html/Issues/202109/page09.html >which relevant parts I copy here for ease of discussion: > >" Recently, there was a debate on the PCLinuxOS forum about KDE This is offtopic but I think it needs being said: I kicked all things KDE off my system for exactly the same reason I never let systemd on my system: A monolithic mess with gratuitious interconnections. The one difference between KDE and systemd is that at least KDE showed the good grace not to sabotage systems it was removed from. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sun, 05 Sep 2021 08:00:51 -0600 Gabe Stanton via Dng wrote: > On Sun, 2021-09-05 at 12:54 +0200, tito via Dng wrote: > > Hi, > > I'm not very fond of apparmor for various reasons: > > > > 1) I experienced unexpected behavior of programs > > silently failing to do something (log, run, etc) > > because the apparmor profile was wrong/bugged > > I experienced the same, as my first introduction to AppArmor, and a > couple times more before I did the same as you and purged it. > > > > > 2) unless you study every code path in the program you want to > > supervise the profiles used will not be safe but nobody really > > cares > > (e.g. maintainer adds a profile that works with the default > > setup > > of the distro (if it really works)) > > This is a great point and probably the biggest reason I remain unsure > about it, combined with the level of permissions it controls, it's like > giving another root-level program access to every bit of processing > that happens. Yes all programs have code that need to be understood to > be trusted, but a program with root-level authority that polices all > other programsI need to understand that program a lot better, > before trusting it, than I do basically any other program. Maybe there > are flaws in that thinking, but unless I misunderstand the level of > permission and control AppArmor has, I'm right to be weary of it. > > Also, the fact that it comes by default, and is enabled by default, and > has those permissions and capabilities, to me, that's the kind of > program that is likely to be exploited in the future, assuming it's not > exploited now and that the dev's or the project are exploitable one way > or another. The fact that it has such permissions and is enabled by > default, and that it was introduced recently, all of those things > justify suspicion as far as I'm concerned. To my unprofessional but > suspicious eyes, it reminds me of systemd. > > Maybe we're wrong, but until we take the time to look at and understand > every line of code, and get to know the project, it seems far safer to > rely on things like firewalls and other trusted security tools. > > > Gabe > Hi, one stupid question that struck my mind right now could apparmor control itself? could you write an apparmor profile to limit what apparmor is doing? Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sun, 2021-09-05 at 12:54 +0200, tito via Dng wrote: > Hi, > I'm not very fond of apparmor for various reasons: > > 1) I experienced unexpected behavior of programs > silently failing to do something (log, run, etc) > because the apparmor profile was wrong/bugged I experienced the same, as my first introduction to AppArmor, and a couple times more before I did the same as you and purged it. > > 2) unless you study every code path in the program you want to > supervise the profiles used will not be safe but nobody really > cares > (e.g. maintainer adds a profile that works with the default > setup > of the distro (if it really works)) This is a great point and probably the biggest reason I remain unsure about it, combined with the level of permissions it controls, it's like giving another root-level program access to every bit of processing that happens. Yes all programs have code that need to be understood to be trusted, but a program with root-level authority that polices all other programsI need to understand that program a lot better, before trusting it, than I do basically any other program. Maybe there are flaws in that thinking, but unless I misunderstand the level of permission and control AppArmor has, I'm right to be weary of it. Also, the fact that it comes by default, and is enabled by default, and has those permissions and capabilities, to me, that's the kind of program that is likely to be exploited in the future, assuming it's not exploited now and that the dev's or the project are exploitable one way or another. The fact that it has such permissions and is enabled by default, and that it was introduced recently, all of those things justify suspicion as far as I'm concerned. To my unprofessional but suspicious eyes, it reminds me of systemd. Maybe we're wrong, but until we take the time to look at and understand every line of code, and get to know the project, it seems far safer to rely on things like firewalls and other trusted security tools. Gabe ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sun, 5 Sep 2021 22:40:23 +1000 wirelessduck--- via Dng wrote: > > > 3) if the user opted out create some kind of /dev/null folder (I suspect > > that such > > thing doesn't exist yet) to delete the data in realtime > > Is the data saved into the telemetry folder before being transmitted > anywhere? Can you just delete the folder and recreate it as a symlink to > /dev/null? Hi, They say it is not transmitted by them unless you opt-in but it is stored and other applications with the same user permissions could read it and send it if they want to. So periodically deleting the data could be a mitigation but is sub-optimal. You cannot link a directory to /dev/null, only files. To create a directory equivalent to /dev/null you need something like: https://github.com/abbbi/nullfsvfs nullfs a virtual file system that behaves like /dev/null It can handle regular file operations like mkdir/rmdir/ln but writing to files does not store any data. The file size is however saved, so reading from the files behaves like reading from /dev/zero with a fixed size. Writing and reading is basically an NOOP, so it can be used for performance testing with applications that require directory structures. Implemented as kernel module, instead of using FUSE, there is absolutely no overhead for copying application data from user to kernel space while performing write or read operations. This one looks really good to me as the project seems to be active and has dkms support. I think I will test it as it comes handy to solve this and similar cases of data hoarding by sending the data directly into oblivion. Will add it to my private repo. Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sun, 05 Sep 2021 11:07:59 + g4sra via Dng wrote: > On Sunday, September 5th, 2021 at 11:54 AM, tito via Dng > wrote: > > On Sun, 05 Sep 2021 10:18:15 + > > g4sra via Dng dng@lists.dyne.org wrote: > > > On Sunday, September 5th, 2021 at 11:15 AM, tito farmat...@tiscali.it > > > wrote: > > > > On Sun, 05 Sep 2021 08:54:14 + > > > > g4sra via Dng dng@lists.dyne.org wrote: > > > > > <--snip--> > > > > > > Comments and better ideas are welcome. > > > > > > Apparmor > > > > > Hi, > > > > > the cure is worse than the disease ;-) > > > > > How is Apparmor abusive ? > > Hi, > > > > > I'm not very fond of apparmor for various reasons: > > 1. I experienced unexpected behavior of programs > > > silently failing to do something (log, run, etc > > > because the apparmor profile was wrong/bugged > > 2. unless you study every code path in the program you want to > > > supervise the profiles used will not be safe but nobody really cares > > > (e.g. maintainer adds a profile that works with the default setup > > > of the distro (if it really works)) > > 3. if you use a customized setup of services or other programs > > > it is highly probable that the profiles will not work for you > > > > > Summary: > > > > > apparmor gets in the way of doing stuff and > > > in the end adds just one more software layer > > > with a million code lines and the inevitable > > > programming errors, so in my humble opinion > > > it just adds complexity (bad!) with no guarantee of improving > > > security (not so good!) and makes linux more > > > windows-like (worse!!). > > > > > Addendum: > > > > > Quis custodiet ipsos custodes? > > > > > What will be the next evolutionary step, will we need > > > a new layer that secures apparmor? > > > > > My Solution: > > > > > To avoid all of this trouble and reduce complexity I pin -1 > > > apparmor in apt preferences, purge it and everything related > > > and disable it on the kernel command line with apparmor=0 > > > and everything is smooth, understandable and reliable again > > > as it has been "in saecula saeculorum". > > > > > Ciao, > > > > > Tito > > > > So to summarise... > The answer to my question 'What is abusive about Apparmor ?' is "nothing". The concept is abusive: 1) it is not KISS 2) it does not fix the underlying issues if there are any 3) who watches the watchdog? Ciao, Tito > > You don't like it because you find it overly complicated to configure. > Better throw overly complicated to configure KDE4 out (and Xorg, and ALSA, > and...) with the bathwater as well then, and then KUserFeedback becomes a > non-issue. > > I find them easier to configure than apparmor despite the fact they want to start to spy on me. > > > > > > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sunday 05 September 2021 at 14:46:34, tito via Dng wrote: > On Sun, 5 Sep 2021 13:25:58 +0200 Antony Stone wrote: > > > > You can say the same about network firewalls (or almost any security > > measure, in fact). Security is seldom aligned with convenience. > > Hi, > Yes and this makes security lucrative and unquestionable. Neither of those correlate with "not a good idea". > Could program xyz be subverted to do things that are not written in his > code or are unwanted then better fix xyz rather than add more code as > watchdog. Good idea to fix xyz (if you can), but also remember "security in depth". Antony. -- Most people have more than the average number of legs. Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sun, 5 Sep 2021 13:25:58 +0200 Antony Stone wrote: > On Sunday 05 September 2021 at 12:54:01, tito via Dng wrote: > > > On Sun, 05 Sep 2021 10:18:15 + g4sra wrote: > > > > > > How is Apparmor abusive ? > > > > I'm not very fond of apparmor for various reasons: > > > > 1) I experienced unexpected behavior of programs > > silently failing to do something (log, run, etc) > > because the apparmor profile was wrong/bugged > > > > 2) unless you study every code path in the program you want to > > supervise the profiles used will not be safe but nobody really cares > > (e.g. maintainer adds a profile that works with the default setup > > of the distro (if it really works)) > > > > 3) if you use a customized setup of services or other programs > > it is highly probable that the profiles will not work for you > > So, a bad configuration doesn't work as you would like. No surprise there, > really. > > Summary: > >apparmor gets in the way of doing stuff... > > You can say the same about network firewalls (or almost any security measure, > in fact). Security is seldom aligned with convenience. Hi, Yes and this makes security lucrative and unquestionable. > However, just as many people would not want to operate systems without a > network firewall, and are prepared to configure it correctly for their needs, > I All ports by default are in CLOSED state so the default is safe unless you want to run a service on a port and control or filter access to that service through this port. You don't need a watchdog by default to check if the ports are closed. This is security by design. > think apparmor has a valuable place in enforcing security within one system; > the price is that the system admin has to tell it to do the right job. The "right job" as I understand it is to let program apparmor tell program xyz to do what it is allowed to do, which program xyz already knows as it is written in his code. Could program xyz be subverted to do things that are not written in his code or are unwanted then better fix xyz rather than add more code as watchdog. Ciao, Tito > > Antony. > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
> 3) if the user opted out create some kind of /dev/null folder (I suspect that > such > thing doesn't exist yet) to delete the data in realtime Is the data saved into the telemetry folder before being transmitted anywhere? Can you just delete the folder and recreate it as a symlink to /dev/null? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sunday 05 September 2021 at 12:54:01, tito via Dng wrote: > On Sun, 05 Sep 2021 10:18:15 + g4sra wrote: > > > > How is Apparmor abusive ? > > I'm not very fond of apparmor for various reasons: > > 1) I experienced unexpected behavior of programs > silently failing to do something (log, run, etc) > because the apparmor profile was wrong/bugged > > 2) unless you study every code path in the program you want to > supervise the profiles used will not be safe but nobody really cares > (e.g. maintainer adds a profile that works with the default setup > of the distro (if it really works)) > > 3) if you use a customized setup of services or other programs > it is highly probable that the profiles will not work for you So, a bad configuration doesn't work as you would like. No surprise there, really. > Summary: >apparmor gets in the way of doing stuff... You can say the same about network firewalls (or almost any security measure, in fact). Security is seldom aligned with convenience. However, just as many people would not want to operate systems without a network firewall, and are prepared to configure it correctly for their needs, I think apparmor has a valuable place in enforcing security within one system; the price is that the system admin has to tell it to do the right job. Antony. -- Was ist braun, liegt ins Gras, und raucht? Ein Kaminchen... Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sunday, September 5th, 2021 at 11:54 AM, tito via Dng wrote: > On Sun, 05 Sep 2021 10:18:15 + > g4sra via Dng dng@lists.dyne.org wrote: > > On Sunday, September 5th, 2021 at 11:15 AM, tito farmat...@tiscali.it wrote: > > > On Sun, 05 Sep 2021 08:54:14 + > > > g4sra via Dng dng@lists.dyne.org wrote: > > > > <--snip--> > > > > > Comments and better ideas are welcome. > > > > Apparmor > > > > Hi, > > > > the cure is worse than the disease ;-) > > > > How is Apparmor abusive ? > Hi, > > I'm not very fond of apparmor for various reasons: > 1. I experienced unexpected behavior of programs > silently failing to do something (log, run, etc > because the apparmor profile was wrong/bugged > 2. unless you study every code path in the program you want to > supervise the profiles used will not be safe but nobody really cares > (e.g. maintainer adds a profile that works with the default setup > of the distro (if it really works)) > 3. if you use a customized setup of services or other programs > it is highly probable that the profiles will not work for you > > Summary: > > apparmor gets in the way of doing stuff and > in the end adds just one more software layer > with a million code lines and the inevitable > programming errors, so in my humble opinion > it just adds complexity (bad!) with no guarantee of improving > security (not so good!) and makes linux more > windows-like (worse!!). > > Addendum: > > Quis custodiet ipsos custodes? > > What will be the next evolutionary step, will we need > a new layer that secures apparmor? > > My Solution: > > To avoid all of this trouble and reduce complexity I pin -1 > apparmor in apt preferences, purge it and everything related > and disable it on the kernel command line with apparmor=0 > and everything is smooth, understandable and reliable again > as it has been "in saecula saeculorum". > > Ciao, > > Tito > So to summarise... The answer to my question 'What is abusive about Apparmor ?' is "nothing". You don't like it because you find it overly complicated to configure. Better throw overly complicated to configure KDE4 out (and Xorg, and ALSA, and...) with the bathwater as well then, and then KUserFeedback becomes a non-issue. publickey - g4sra@protonmail.com - 0x42E94623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sun, 5 Sep 2021 09:59:09 +0200 "Dr. Nikolaus Klepp via Dng" wrote: > Hi! > > Anno domini 2021 Sun, 5 Sep 09:52:11 +0200 > tito via Dng scripsit: > > Hi, > > while reading the latest edition of the PCLinuxOS Magazine, > > I've found this interesting article about KUserFeedback > > at https://pclosmag.com/html/Issues/202109/page09.html > > which relevant parts I copy here for ease of discussion: > > > > " Recently, there was a debate on the PCLinuxOS forum about KDE Plasma's > > implementation > > of telemetry through KUserFeedback. While in PCLinuxOS, we can remove it > > without any > > collateral effects to the system, while other users reported that doing > > the same in other > > distros (like Debian 11) results in the complete removal of KDE Plasma! > > Why force such > > an implementation, if, as KDE's developers say, it is just an innocuous, > > privacy-respecting > > measure? > > > > Coincidence or not, in the past years many popular Linux distributions > > started rolling out > > optional telemetry. Then it was the time of computer programs: news broke > > out in May > > regarding Audacity, a popular audio editing app, which announced it was > > starting the > > use of telemetry. The move was finally pushed back after users revolted > > against it. > > > > But in Plasma's case, it is not just an app or a single distro, but an > > entire desktop > > environment, employed in several Linux distributions, that is being shipped > > with > > telemetry. While many point out that the data collection is by opt-in and > > entirely > > anonymous, others have found that, even if you don't activate telemetry, > > data is > > still collected, using computer resources, registering "apps and boot, > > number of > > times used and duration in /home/user/telemetry folder." As such, they > > argue that, > > because of the way Linux permissions work, other programs could have access > > to these log files. KUserFeedback's FAQs page confirms this: > > > > 'KUserFeedback is designed to be compliant with KDE Telemetry Policy, which > > forbids > > the usage of unique identification. If you are using KUserFeedback outside > > of the > > scope of that policy, it's of course possible to add a custom data source > > generating > > and transmitting a unique id.' > > > > Not being an expert on such matters, it is anyway a little strange the step > > taken by > > KDE and the way it is being implemented by most mainstream distros, as if > > there > > was a certain consternation about it. To better understand the picture, let > > us give > > a look at the organization that maintains the Plasma desktop." > > > > What possible solutions are there to avoid this user data hoarding and > > their > > abuse? > > > > Simple workarounds that I can think off: > > > > 1) allow removal of KUserFeedback by modifying deb deps (rather ineffective > > as most user will not care to do so) > > > > 1a) allow removal of KUserFeedback by modifying deb deps and don't install > > by default unless the way data is collected is changed so that data > > are collected only if opted in > > > > 2) if the user opted out make /home/user/telemetry a tmpfs so that data > > stored > > are forgotten at reboot (easy but not very effective as data could > > still be > >abused in the meanwhile) > > > > 3) if the user opted out create some kind of /dev/null folder (I suspect > > that such > > thing doesn't exist yet) to delete the data in realtime > > > > 4) if the user opted out run cron jobs or other autostart scripts to > > periodically > > (boot, login, logout, hourly etc) delete this data > > > > Comments and better ideas are welcome. > > Don't think a lot of people here use KDE4 :) Hi, I do, that's a lot to me! .and we ship it in the repos that is a enough of a reason to care about it. cura ut valeas > Anyway, e.g. "audacity" has added "telemetry" and "lawful inspection" a while > ago and was promptly forked > https://www.theregister.com/2021/07/06/audacity_fork/ . Unpleasently there is > still audacity in the devuan/debian repository, so keep an eye open on the > new spyware. > > nik > > > > > Ciao, > > Tito > > > > > > ___ > > Dng mailing list > > Dng@lists.dyne.org > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > > > > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sun, 05 Sep 2021 10:18:15 + g4sra via Dng wrote: > On Sunday, September 5th, 2021 at 11:15 AM, tito wrote: > > On Sun, 05 Sep 2021 08:54:14 + > > g4sra via Dng dng@lists.dyne.org wrote: > > > <--snip--> > > > > Comments and better ideas are welcome. > > > Apparmor > > Hi, > > the cure is worse than the disease ;-) > How is Apparmor abusive ? > Hi, I'm not very fond of apparmor for various reasons: 1) I experienced unexpected behavior of programs silently failing to do something (log, run, etc) because the apparmor profile was wrong/bugged 2) unless you study every code path in the program you want to supervise the profiles used will not be safe but nobody really cares (e.g. maintainer adds a profile that works with the default setup of the distro (if it really works)) 3) if you use a customized setup of services or other programs it is highly probable that the profiles will not work for you Summary: apparmor gets in the way of doing stuff and in the end adds just one more software layer with a million code lines and the inevitable programming errors, so in my humble opinion it just adds complexity (bad!) with no guarantee of improving security (not so good!) and makes linux more windows-like (worse!!). Addendum: Quis custodiet ipsos custodes? What will be the next evolutionary step, will we need a new layer that secures apparmor? My Solution: To avoid all of this trouble and reduce complexity I pin -1 apparmor in apt preferences, purge it and everything related and disable it on the kernel command line with apparmor=0 and everything is smooth, understandable and reliable again as it has been "in saecula saeculorum". Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sunday, September 5th, 2021 at 11:15 AM, tito wrote: > On Sun, 05 Sep 2021 08:54:14 + > g4sra via Dng dng@lists.dyne.org wrote: > > <--snip--> > > > Comments and better ideas are welcome. > > Apparmor > Hi, > the cure is worse than the disease ;-) How is Apparmor abusive ? publickey - g4sra@protonmail.com - 0x42E94623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sun, 05 Sep 2021 08:54:14 + g4sra via Dng wrote: > <--snip--> > > Comments and better ideas are welcome. > > Apparmor Hi, the cure is worse than the disease ;-) Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
<--snip--> > Comments and better ideas are welcome. Apparmor publickey - g4sra@protonmail.com - 0x42E94623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
Hi! Anno domini 2021 Sun, 5 Sep 09:52:11 +0200 tito via Dng scripsit: > Hi, > while reading the latest edition of the PCLinuxOS Magazine, > I've found this interesting article about KUserFeedback > at https://pclosmag.com/html/Issues/202109/page09.html > which relevant parts I copy here for ease of discussion: > > " Recently, there was a debate on the PCLinuxOS forum about KDE Plasma's > implementation > of telemetry through KUserFeedback. While in PCLinuxOS, we can remove it > without any > collateral effects to the system, while other users reported that doing the > same in other > distros (like Debian 11) results in the complete removal of KDE Plasma! Why > force such > an implementation, if, as KDE's developers say, it is just an innocuous, > privacy-respecting > measure? > > Coincidence or not, in the past years many popular Linux distributions > started rolling out > optional telemetry. Then it was the time of computer programs: news broke out > in May > regarding Audacity, a popular audio editing app, which announced it was > starting the > use of telemetry. The move was finally pushed back after users revolted > against it. > > But in Plasma's case, it is not just an app or a single distro, but an entire > desktop > environment, employed in several Linux distributions, that is being shipped > with > telemetry. While many point out that the data collection is by opt-in and > entirely > anonymous, others have found that, even if you don't activate telemetry, data > is > still collected, using computer resources, registering "apps and boot, number > of > times used and duration in /home/user/telemetry folder." As such, they argue > that, > because of the way Linux permissions work, other programs could have access > to these log files. KUserFeedback's FAQs page confirms this: > > 'KUserFeedback is designed to be compliant with KDE Telemetry Policy, which > forbids > the usage of unique identification. If you are using KUserFeedback outside of > the > scope of that policy, it's of course possible to add a custom data source > generating > and transmitting a unique id.' > > Not being an expert on such matters, it is anyway a little strange the step > taken by > KDE and the way it is being implemented by most mainstream distros, as if > there > was a certain consternation about it. To better understand the picture, let > us give > a look at the organization that maintains the Plasma desktop." > > What possible solutions are there to avoid this user data hoarding and their > abuse? > > Simple workarounds that I can think off: > > 1) allow removal of KUserFeedback by modifying deb deps (rather ineffective > as most user will not care to do so) > > 1a) allow removal of KUserFeedback by modifying deb deps and don't install > by default unless the way data is collected is changed so that data > are collected only if opted in > > 2) if the user opted out make /home/user/telemetry a tmpfs so that data stored > are forgotten at reboot (easy but not very effective as data could still > be >abused in the meanwhile) > > 3) if the user opted out create some kind of /dev/null folder (I suspect that > such > thing doesn't exist yet) to delete the data in realtime > > 4) if the user opted out run cron jobs or other autostart scripts to > periodically > (boot, login, logout, hourly etc) delete this data > > Comments and better ideas are welcome. Don't think a lot of people here use KDE4 :) Anyway, e.g. "audacity" has added "telemetry" and "lawful inspection" a while ago and was promptly forked https://www.theregister.com/2021/07/06/audacity_fork/ . Unpleasently there is still audacity in the devuan/debian repository, so keep an eye open on the new spyware. nik > > Ciao, > Tito > > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] KUserFeedback
Hi, while reading the latest edition of the PCLinuxOS Magazine, I've found this interesting article about KUserFeedback at https://pclosmag.com/html/Issues/202109/page09.html which relevant parts I copy here for ease of discussion: " Recently, there was a debate on the PCLinuxOS forum about KDE Plasma's implementation of telemetry through KUserFeedback. While in PCLinuxOS, we can remove it without any collateral effects to the system, while other users reported that doing the same in other distros (like Debian 11) results in the complete removal of KDE Plasma! Why force such an implementation, if, as KDE's developers say, it is just an innocuous, privacy-respecting measure? Coincidence or not, in the past years many popular Linux distributions started rolling out optional telemetry. Then it was the time of computer programs: news broke out in May regarding Audacity, a popular audio editing app, which announced it was starting the use of telemetry. The move was finally pushed back after users revolted against it. But in Plasma's case, it is not just an app or a single distro, but an entire desktop environment, employed in several Linux distributions, that is being shipped with telemetry. While many point out that the data collection is by opt-in and entirely anonymous, others have found that, even if you don't activate telemetry, data is still collected, using computer resources, registering "apps and boot, number of times used and duration in /home/user/telemetry folder." As such, they argue that, because of the way Linux permissions work, other programs could have access to these log files. KUserFeedback's FAQs page confirms this: 'KUserFeedback is designed to be compliant with KDE Telemetry Policy, which forbids the usage of unique identification. If you are using KUserFeedback outside of the scope of that policy, it's of course possible to add a custom data source generating and transmitting a unique id.' Not being an expert on such matters, it is anyway a little strange the step taken by KDE and the way it is being implemented by most mainstream distros, as if there was a certain consternation about it. To better understand the picture, let us give a look at the organization that maintains the Plasma desktop." What possible solutions are there to avoid this user data hoarding and their abuse? Simple workarounds that I can think off: 1) allow removal of KUserFeedback by modifying deb deps (rather ineffective as most user will not care to do so) 1a) allow removal of KUserFeedback by modifying deb deps and don't install by default unless the way data is collected is changed so that data are collected only if opted in 2) if the user opted out make /home/user/telemetry a tmpfs so that data stored are forgotten at reboot (easy but not very effective as data could still be abused in the meanwhile) 3) if the user opted out create some kind of /dev/null folder (I suspect that such thing doesn't exist yet) to delete the data in realtime 4) if the user opted out run cron jobs or other autostart scripts to periodically (boot, login, logout, hourly etc) delete this data Comments and better ideas are welcome. Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
