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
