Meeting on store content distribution after Monday's Plasma meeting

[Nate Graham]

On 3/21/24 04:50, David Edmundson wrote:
> The topic of store content has come up repeatedly throughout last
> year. It's clear what we're showing to users now doesn't meet modern
> expectations and our messaging is not the clearest. It's in the
> spotlight currently, we can use that energy to do something
> productive.
> 
> Lets discuss this in a video call on Monday after the normal Plasma
> meeting (which is at 4pm CET) and see what initial steps we want to
> take for 6.1.
> 
> David


Good idea.

For background information, what happened was that a user used the "Get 
New [thing]" integration for pling.com in System Setting to download a 
global theme that they didn't reasonably expect would run executable 
code, and it did via the executable data engine in a bundled widget, and 
it broke in the worst possible way.


For the purpose of stimulating ideas and discussion in the meeting, let 
me note down a few complementary routes that I could see us going down:



# Moderation
have trusted experts filter out dangerous or broken content so it 
doesn't get distributed to unsuspecting users in the first place. 
Example: the distro packaging model.

This would have to be done on pling.com. It would look like a 
fundamentally different upload process involving new content being 
checked automatically against templates of allowed files and folder 
structures, and humans manually reviewing and verifying everything. 
**Feasible now, but doesn't scale well, or at all (as evidenced by the 
lack of anyone volunteering to do it during the time it's been known 
that this was an issue)**



# Restriction
Limit the damage that dangerous or broken content on the user's system 
can cause. Here are some examples of what could be done on the KDE side:

1. Only allow the executable data engine to be run by widgets, not any 
other kind of QML code (e.g. logout greeters and OSDs). **Probably 
feasible**
2. Because it's so security-sensitive, prevent Plasma from loading 
custom lockscreen QML code in Global Themes (as we did for custom 
KRunner QML in Plasma 5 times). **Feasible but would disable themed 
lockscreens until we roll out a new no-code theming engine**
3. Run all 3rd-party widgets in a Flatpak-like sandboxed process and 
make them use portals to interact with various parts the system **Maybe 
feasible and would only break some widgets?**
3. Change the `ConfigFile()` feature of Plasma scripting so that it's 
only able to touch an allow-listed set of config files in Plasma and 
maybe other KDE software, not arbitrary ones on the system. **Maybe 
feasible and would only break some Global Themes**
4. Remove or disable the executable data engine and force widgets to use 
Plasma and KWin scripting APIs, or else prompt for confirmation every 
time it's used. **Probably unfeasible as it would break most 3rd-party 
widgets and/or be super annoying to users**



# Segregation
This would also be done on the KDE side and look like any of these:

1. Show a much more scary warning for content that can run arbitrary 
code, such as QML Widgets and Dolphin servicemenu entries. **Feasible now**
2. Show a less scary warning for content that can't. **Feasible now**
3. When Global Themes include widgets, notify the user about this and 
show the "can run arbitrary code" scary warning. Prompt them to either 
acknowledge the potential danger and explicitly proceed, or filter out 
the widgets. **Feasible now**



# Remove unneeded themability
An example is splash screens, 99.99% of which could be a static or 
animated image, or maybe one overlaid on top of a fixed background. If 
we let the user choose their own image, then we could remove splash 
screen themability entirely. We could also just leave SDDM visible until 
Plasma is ready and do an animated transition there, deleting the 
concept of the Plasma splash screen.



Nate