Accessibility seems to be the only real weakness of the open source “contribution drives focus” ethos. If I don’t like the way the window manager ecosystem is growing, it is fine if the only thing that blocks me from fixing it is my own laziness. It must not be that big a concern.
But, if an ecosystem that excludes people through no fault of their own grows up, that sucks.
roenxi · 8h ago
> 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 · 7h ago
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 · 7h ago
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.)
zeta0134 · 5h ago
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 · 7h ago
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).
wslh · 7h ago
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 · 7h ago
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).
yjftsjthsd-h · 7h ago
> X11 never had a model to permit this for accessibility tooling while blocking it for other code. Wayland does, but suffers from the surrounding infrastructure not being well developed yet.
Does it? Because last I checked, Wayland did not, in fact, have the same features, and you don't get credit for "permitting" use of something that doesn't exist.
> When you read anything about Linux accessibility, ask yourself whether you're reading something written by either a user of the accessibility features, or a developer of them. If they're neither, ask yourself why they actually care and what they're doing to make the future better.
Okay: AFAIK, mjg59 is not a user of a11y features, and is not a developer of them (22 years ago yes, since then no). Ergo, by his own standards he isn't allowed to talk about this.
No comments yet
voidUpdate · 7h ago
What's an A11y? I cant find it in TFA or anything... l33tspeak for ally?
This is a great example of why replacing the middle of a word with numbers is a bad idea. it makes the word less accessible.
yjftsjthsd-h · 7h ago
accessibility
Imustaskforhelp · 8h ago
friend, its 403 forbidden. I do hope that you can fix it. I wish to read your article! Cheers
haolez · 8h ago
Broken for me as well
bear8642 · 8h ago
seems fixed
jen729w · 8h ago
Nope. iCloud Private Relay from Saigon, but doesn't work even if I unblock & show IP.
And I don't know why OP is being downvoted. What's the point of putting a website up if you 403 people who try to visit? That is FUBAR BROKEN and is inexcusable, sorry.
dsr_ · 7h ago
Dreamwidth pretty aggressively blocks attacking IPs, and has a long cooldown period.
It's completely excusable considering that they have been the target of a lot of bandwidth attacks... and that they don't owe you anything.
But, if an ecosystem that excludes people through no fault of their own grows up, that sucks.
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.
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
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.)
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).
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).
Does it? Because last I checked, Wayland did not, in fact, have the same features, and you don't get credit for "permitting" use of something that doesn't exist.
> When you read anything about Linux accessibility, ask yourself whether you're reading something written by either a user of the accessibility features, or a developer of them. If they're neither, ask yourself why they actually care and what they're doing to make the future better.
Okay: AFAIK, mjg59 is not a user of a11y features, and is not a developer of them (22 years ago yes, since then no). Ergo, by his own standards he isn't allowed to talk about this.
No comments yet
https://adrianroselli.com/2016/11/a11y-accessibility.html
And I don't know why OP is being downvoted. What's the point of putting a website up if you 403 people who try to visit? That is FUBAR BROKEN and is inexcusable, sorry.
It's completely excusable considering that they have been the target of a lot of bandwidth attacks... and that they don't owe you anything.