SUMMARY Kwin identifies application using the application provided app_id, whereas on GNOME the sandbox provided one takes priority. Possible use case is to group all windows with a sandbox provided app-id to prevent generic icon or malicious applications spoofs their identity as other apps. Also without stable window mapping background portal can terminate applications mistakenly STEPS TO REPRODUCE 1. Install KDE and gtk4-demo on Arch 2. Install aur/portable and aur/wechat 3. Run `wechat.sh --actions debug-shell connect-tty` to enter the sandbox, and then start gtk4-demo inside the sandbox. OBSERVED RESULT The window is not mapped to aur/wechat's desktop file, instead it shows as GTK demo. EXPECTED RESULT Like GNOME, the app is shown as WeChat with WeChat's icon. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux rolling KDE Plasma Version: 6.3.3 KDE Frameworks Version: 6.12.0 Qt Version: 6.8.3
>Like GNOME, the app is shown as WeChat with WeChat's icon. Having gtk4-demo appear as wechat doesn't exactly sound right either! I would bet Gnome devs get bug reports on that too. It's always a tough balance when it comes to security and user-centric goals. Given we support client provided icons anyway, I'm not sure we gain too much from this. > Also without stable window mapping background portal can terminate applications mistakenly Was that something you saw with our portal? I didn't think we did that.
> Having gtk4-demo appear as wechat doesn't exactly sound right either! I would bet Gnome devs get bug reports on that too. It's just a demo that applications inside the sandbox is able make themselves like they're another application's window, aka spoofing .desktop file name, which can be a security issue? > Was that something you saw with our portal? I didn't think we did that. Obsidian sandboxed by portable can be terminated incorrectly if the background permission is disabled.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.
bump to Re Open
Sorry to disturb. Had a little talk in [XDG Desktop Portals Matrix room], and I think preferring the sandbox supplied application ID is beneficial. It can eliminate generic "Wayland" icons, which is sometimes shown in the decoration or Alt Tab menu (and it's inconsistent). And it also fixes the problem that the background portal may terminate applications even it has visible window, because sometimes application and sandbox provide different APP IDs. Currently we are doing a D-Bus call in portable to make sure sandboxed application is able to run in the background, but that's not optimal IMO. As for the icon thing, the toplevel icon Wayland protocol may be more suitable.
Had a discussion in KWin Matrix room yesterday, quoting @zamundaaa:kde.org: We could fall back to the sandbox app id when the one the app sets explicitly on the window is either nonsense or doesn't match to the sandbox Yes. `org.libreoffice.LibreOffice.Writer` should work if the sandbox app id is `org.libreoffice.LibreOffice` But zen-browser-portable could be ignored in favor of org.mozilla.zen https://matrix.to/#/!xdwRmYgjAuZSEhsheE:kde.org/$d1F2cNr07I1Xsgn0Tf_Sb705td4psW3-O_GiZsNK0ow?via=kde.org&via=matrix.org&via=im.kde.org I think this is the better approach to not only prevent spoofing but also allowing different apps inside the same sandbox.