This is especially amazing given how much of wayland friction is in the name of security ("Why would we ever standardise a way to intercept and send keystrokes? it's not secure!")
The "friction" is that Wayland developers don't want a sandboxed application with access to the Wayland socket to pwn your machine.
Trying to isolate applications within the same UNIX user is essentially unfixable since there's ptrace, LD_PRELOAD, /proc/$pid, .bashrc drop-ins, etc.
The author must know about all of this, as it's mentioned in the LD_PRELOAD note in the end. In my view, the model he proposes is security by obscurity (putting hurdles on top of a fundamentally insecure system).
At the same time a malware can just get all of your passwords without even asking using d-bus or read all of your files since it's running as your uid.
Thats not exactly true since this requires the application to have permission to talk to the secrets service (if using Flatpak)
[1]: https://flatkill.org/ [2]: https://hanako.codeberg.page/
No security boundary can prevent bad permissions just like in android.
They both create an illusion of safety. We all know that X.org had no security model and it sucks. Wayland put restrictions that would make sense if the rest of the desktop ecosystem was made with security in mind, but it wasn't. I've heard way too many claims like "Wayland makes keyloggers impossible" that are technically true but irrelevant in the real world, because a desktop environment is not just Wayland.
Flatpack is also misleading and its sanboxing is just not great, regardless of the problem with X11.
> No security boundary can prevent bad permissions just like in android.
Good bringing this up: in Android the applications ask the user for permissions, in flatpak permissions are granted based on what the developed asked. That's just bad.
Such portals exist for some permissions like screensharing and other are planned.
Are you sure about this? My belief was that all flatpak apps run inside a bubblewrap (bwrap) sandbox. I just checked and that's exactly how it runs for me.
> so if I were to make a malicious flatpak I will just ask for full file system access or d-bus.
This is done at install time. The application inside the flatpak can't change it on its own. Reputed repositories like Flathub check the permissions and flag them if they are too broad. And you can also change it using something like FlatSeal. This is almost the same permissions model followed by Android.
All my apps by defaults have no /home and no network access. I do this by writing to .local/share/flatpak/overrides/global (per user) or /var/lib/flatpak/overrides/global for the system. I wish this was publicized more. The defacto app for flatpak permissions, flatseal, doesn't have this capability yet to my knowledge.
In GNOME. There is a protocol to set your window icon, and it will be respected by the Wayland compositors which are considering that there is value at having custom icons for each window. GNOME also considers it's confusing to have multiple windows from the same program with different icons, especially since the only places those icons could be displayed on GNOME are in the dock and in the Alt+Tab menu, but you pin apps to the dock, so those custom icons cannot be displayed there when there are multiple windows from the same app.