[roenxi]

> A lot of the Linux accessibility support depended on X11 behaviour that is now widely regarded as a set of misfeatures. It's not actually good to be able to inject arbitrary input into an arbitrary window, and it's not good to be able to arbitrarily scrape out its contents.

While that may be true, I'd suggest that it is not a consensus view and, more specifically, there is probably a consensus that the capability to do arbitrary scrapes and inputs needs to exist in a controlled fashion. Wayland had a bizarre stillbirth where the core team resisted screenshots, I can't remember when the Wayland ecosystem started getting serious about enabling screen sharing but I've got a memory that it was post-COVID.

It goes to show how challenging the space is that Wayland managed to keep trudging on, but it was nothing to do with "woke" and a lot to do with "I don't accept that screenshots are a significant development hurdle". I still flat out don't trust them to have resolved all the issues crippling things like autoclickers but I'm hopeful I'm just very out of date. The initial take was poorly designed and that bit Wayland's adoption hard.

The ecosystem may eventually reach the level of capability that X had in a standardised and secure way. Maybe it even has (I doubt it). But there is no consensus that security trumps having a usable desktop. I'm happy with an insecure desktop, anyone serious who wants to spy on me can use my phone. It is wildly insecure as far as I care and I carry it with me most hours. People trade this stuff off for convenience. Every time I've tried Wayland I discovered it had been secured against me using my system to get things done.

[wongarsu]

One clear sign that classifying them as misfeatures is not a consensus view is that every major OS has those features.

The security model changed drastically, and with them how those features are presented. For example Windows, being developed to the threat model of the early 90s with some stuff tacked on in the aughts, has powerful APIs for reading window content in a structured way, for getting screenshots and for injecting arbitrary inputs, and only has some tacked-on protections that protect higher-privileged processes from lower-privileged ones (e.g. task manager runs with admin privileges, and you can't inject inputs into it or read mouse events of a cursor over it unless you run with the same or higher privileges). Android was built to the threat model of the aughts with additions in the 2010s and 2020s and has great APIs for reading window contents in a structured way, getting screen content, adding overlays and injecting inputs, but they are gated behind strong capability-based permission systems, review in the most common app distribution system (play store) and require the human to jump through various hoops to confirm this is really their intent. iOS ... restricts a lot of that to Apple, because they don't trust app developers.

X.Org does all of that with a permission model similar to that of Windows NT4, without the added restrictions Microsoft added later. That is the misfeature. Wayland looked at that, looked at the ability to make something better in the somewhat disjointed linux/*nix ecosystem and decided to just not have those features rather than have a good security/permission model

[rcxdude]

This is more or less the headache, I think. A complete lack of urgency around the idea that wayland did need to have _standard_ interfaces for doing pretty much all the things that people were doing with X11. Yes, it's more difficult to design them in a secure manner, but there seems to be just a strong attitude of 'well, you don't actually want to X because...' which has proven to be a massive barrier to adoption (at least, I think it puts people off and slows progess much more than 'we understand it's important but haven't had the time to sort it out, sorry'). This has been especially bad in matters of taste where some projects or members thereof don't like some concept or another which developers and users have gotten very used to (and can in fact be done securely and with respect for the user), so it just gets stonewalled and disrupted at every turn.

As a result, generally the answer to 'how do I do X in wayland' is 'you don't. here's how you do it in KDE, here's the extension you need to install in GNOME to be able to do it, and you're rolling the dice on any other DE'. And that's as a developer, if you're a user there's a good chance the developer has gone 'fuck it, I'm sticking with X11'.

(This fragmentation is even worse when it comes to configuration. e.g. for something like graphics tablets, where there is a relatively complex configuration of how the features on the hardware map to delivered input events, it's left up the the compositor to handle how that's configured. Which means that there's basically no standard way for you to configure your tablet, and there's no complete option: you are either forced into GNOME or KDE because you need some option one supports and the other doesn't, and if you're on a smaller one, you have basically no chance. X11's architecture meant this tended to be much more standardised, and while each DE had its own UI for configuring an input device, you could in practice always fall back to another tool, even if it was usually an arcance CLI, to get what you want.)

[okanat]

I think the failure wasn't Wayland itself but the failure of building another layer on top of it that unified desktop use case. Wayland could have stayed as the protocol to allocate buffer on the screen and passing events to them.

Wayland was designed by people who worked on embedded / mobile systems (some of the Xorg devs who created Wayland were MeeGo developers). It is fine to forego window management and other complex things on embedded systems and leave it to things that build upon them. For desktop another library like libdesktop-window-managment-features would be alright.

The problem arose when GNOME, with their infinite stubborn wisdom, used the lack of various desktop features in Wayland to further their mission to provide a barely functional desktop. Since they also maintain GTK / Cairo / Glib (which both Firefox and Chromium rely on to display things on Linux) everybody else was forced to obey GNOME's crappy world view.

The other DEs and toolkits are prevented from forking the entire Linux desktop environment unless they also want to foot the cost of porting both browser engines to another desktop toolkit / window management system and many popular GTK apps like Inkscape, Libreoffice and Gimp. They definitely have less funding at the moment.

All in all though, without a hard fork away from GNOME and GTK, Linux desktop systems will only cause unnecessary pain upon themselves and their users. They need to find partners like Valve (which already work with KDE) who will fund the projects and move away from GTK / Freedesktop to found something better.

[wslh]

Yes, I always find these kinds of screenshot restrictions more of a friction than real security. After all, anyone can still take a photo of the screen, less convenient, but it bypasses the restriction entirely. I understand the goal is to prevent malware from taking screenshots, but true security should come from a better model, like customizable capabilities. If needed, add 2FA or some form of consent before allowing a screenshot: the solution should be smarter, not just restrictive.

[hollerith]

On (version 47 of) Gnome/Wayland, any program can take a screenshot (by calling out to gnome-screenshot) but the screenshot is accompanied by a flashing of the screen to alert the user that it is happening.

Gnome probably attempts to restrict taking a screenshot without flashing the screen (and I'm currently trying to figure out how to bypass the restriction).

[zeta0134]

This came up in the anti-cheat thread, and honestly it's a really good point that counters my initial security reaction. Accessibility features *can* break the security model if, and only if, the user permits them to do so. That's not a broken system, that's a feature working as intended. Powerful features can always be misused, but if this is being done in service of the user, with that user's informed consent, then the features can certainly still exist. Whether something is an "exploit" largely comes down to intent.

[p_l]

Wayland early on decided that security is hard and the way forward is to just... not have the functionality. I remember when there was serious discussion copy-paste should be handled by D-Bus service provided by DE and implemented by "major toolkits". Same for anything else that might require permissions (this is how we got portals and their brokeness).

And yeah, nothing in it was related to "woke" (that's just certain dev's personal weirdness), and a lot was related to really weird community situation that X.Org (which is not X11 itself) got itself in, like the costly and failed switch to autotools (they switched, but didn't get the results they undertook that pain for). Meanwhile they were operating from "lowest common denominator" code base that got extended a lot but never truly redone (compare Xsgi, which was a compositing X server and made extensive use of multiple visuals to ensure optimal resource usage).