WARNING: Global themes and widgets created by 3rd party developers for Plasma can and will run arbitrary code. You are encouraged to exercise extreme caution when using these products

That will not help much because a malicious developer could just use some kind of automation to circumvent that.

I wonder if we can impose telemetry on 3rd party plugins in order to count the active number of installations. Only the fact that we impose telemetry (ie users data collected without prior consent) and making noise in social media about it could be enough to make users to think again :roll_eyes:

I guess just the social media noise would be good for usersā€™ awareness on that issue and we not even need to implement that telemetry after all. :slight_smile:

I understand people might think the KDE store is completely curated and only ā€œcleanā€ apps are there, but itā€™s completely opposite from the truth and that should probably be communicated better, but also in a way that does not completely scare everyone away.

People seems to put ā€œtheir blind trustā€ in that KDE somehow keeps their computer clean and reads every single line of code that gets installed. That is a good thing (that people trust KDE), but also a bad thing if the same people jumps to conclusions on how things work on the KDE store, because that is NOT curated by the KDE.

The question is not ā€œhow can I read the source codeā€ because if you know how, it is pretty easy to do. The problem is for users that do NOT know how, how do we make sure they are as safe as possible in their usage of KDE store?

Starting treating the users as children, doing everything for them (and spying on them with telemetry to make sure they are doing things ā€œrightā€) is not the way to go imho. That sounds very much like windoze or appfle.
An EDUCATED userbase is way better than a controlled userbase.

I reacted to this line because it is extremely true, but also very unfortunate.
So how do we make it so the risk is as minimal as possible?

1 Like

this should be the default ā€¦ or highest rated

having the default set to most recent only invites an exploit.

2 Likes

Someone needs to manually check any widgets that contain code. And this needs to be done on every update of the widget.

This is not spying on users. This is counting a widgetā€™s active installs.

1 Like

I do think it bears mentioning here that, AFAICT, for the user in question, the source of their interaction with the KDE Store to begin with wasnā€™t navigating to store.kde.org, but was through the ā€œGet Newā€¦ā€ buttons contained within Plasma itself.

This is very important. I always install themes through KCM and widgets through the Get New Widgets button in Plasma desktopā€™s Edit Mode. I only ever go to the website if something I want isnā€™t downloading through these means and I want it enough to do so manually. I believe that most users, especially most new users, probably also rely more on these built-in mechanisms than on opening a browser and going to the website.

Perhaps the Get New window should also have a Report button, in addition to the rewritten warning as @johnandmegh said.

And who is going to pay for that?
Or who is going to do that for free with the huge responsibility that places on them?
Not even canonical with their snaps does that, and they PROMOTE snaps to be safe. KDE does not.
This expectation is completely unrealistic.

It is, unless the user actively has to activate the telemetry, and then we are back to square one.
And counting application installs, how would that help anyone?
You need WAY more telemetry for it to be useful in this situation.
Besides, that would most likely just be a false sense of security, and once again putting the responsibility on KDE.
I think that is the wrong approach.

1 Like

Yeah! I agree. So better do nothing other than informing the users that thereā€™s no guarantee, something that is already expressed in all open source licenses, but who reads these?

Things can be done, Iā€™m sure. But at the end of the day, the responsibility lies upon the user.

I think the warning I get when installing from KDE is enough, both in the window I can download from, big blue text box at top warning me.

And can see it on the webpage too. But maybe an extra popup should appear when downloading or installing from the web page.
Other than that, not sure what more can be done in for of warnings.

Thatā€™s enough for you (and me), but times are changing. The developers are aware and they will take action as they think are apropriate. Here is the an excellent blog post by a KDE developer explaining the situation:

Lets not do too much speculating, I think we will receive further information soon enough.

What else can you do than what I suggested in my post?
Make the text cover the entire screen?
I was only talking about the actual textual warning.

Other implementations of protection might come into place, I have no problem with that, except for if it came to intrusive telemetry.
Telemetry used the correct way is an amazing feature, it if is possible, Iā€™m sure KDE will figure it out.
That could be one possible way, but there are probably multiple other ways the we are not thinking of here in this thread. But they will do something.

Hereā€™s what Iā€™d like to see:

Lock the ā€œGlobal Themesā€ window behind a popup.

The popup contains the following:

Button ā€œProceedā€(inactive), Button ā€œCancelā€(active)

The following text (or something similar):
I acknowledge that ā€œGlobal Themesā€ are not controlled or vetted by KDE and that by using any of the functionality provided in the ā€œGlobal Themesā€ there is a non zero chance that I might:

  1. Wipe, corrupt or expose my data
  2. Trash my system

Then a checkbox: I understand the risks and wish to unlock ā€œGlobal Themesā€.

Once the user clicks on the checkbox then the button ā€œProceedā€ becomes active.

The user can click ā€œProceedā€ and the popup disappears (forever for the current user) and ā€œGlobal Themesā€ is (forever) unlocked.

Overkill? Perhaps. But I think the current situation warrants it.

4 Likes

So this was the result of a faulty/buggy code or was it a malicious attempt hurting KDEā€™s Store/widgets/services reputation? Did anyone analyze the code?

Yes.
And it seems it was an honest mistake.
Some files in the library was not yet ported to plasma 6 so variables that was expected did not get sent.
And in one of the files, the line contained something like rm -rf ${HOME}/${variable} and no check if the variable was empty was made so if empty: rm -rf $HOME :open_mouth:

I did not analyze the code myself, I am just repeating what I have read online, and I can have mixed up things with the old one where steam ran an even worse version as root: rm -rf ${variable}/* > rm -rf /* :open_mouth:
The mistake is similar. A simple test on the variable to see if it was empty would have stopped it from happening.
In the steam version they even added a comment before the line with ā€œ#SCARY!ā€, so they were even AWARE of the risks but did not put in the one required line to make it safeā€¦ :person_facepalming:

Everything points to it being a mistake, nothing towards any malicious intent.

3 Likes