Back

@mort There is. Steam is just not using the API to enable it. Steam is proprietary so there's not much we can do other than tell Valve to use this API. Which we've done.

https://github.com/ValveSoftware/steam-for-linux/issues/10442#issuecomment-2297463781

@AdrianVovk Uh I'm pretty sure GNOME is what's putting up the dialog, which means GNOME has the ability to provide an "always allow" option. Am I wrong?

@mort You are wrong. Steam needs to tell GNOME that it supports remembering that permission was granted. Then GNOME will show the checkbox to remember your choice. Once you grant the permission to Steam, if you checked the option to remember your choice GNOME gives Steam a big random number to write down. When Steam wants to take over the system again, it says "hey! I want to regain control. My random number was: $NUMBER". If the number is right, GNOME grants the permission without asking again

@AdrianVovk Okay but currently, Steam presumably says to GNOME, "Hey I wanna emulate user input, tho I don't know anything about that token business". And then, it's GNOME which takes that to mean, "I should show a dialog to the user with a checkbox".

There's nothing technically preventing GNOME from just not showing that checkbox, right? It could have had a setting to just always allow requests to emulate input, like X.Org did, right?

@mort Sure, I guess in theory GNOME could grant the permission to take control of your system to any app that asks, without asking you first. Actually, this is exactly what Steam OS does, as far as I know.

But that's not gonna happen. It's a terrible idea for system security. The ability to inject input is part of the reason that X11 is considered to be inherently insecure. If anything, GNOME should ratelimit and auto-deny the permission

Steam just needs to use the features the OS provides

@AdrianVovk I'm fine with the security risks. I'm not running malware. I lived happily with this "security risk" in X11, and I would happily live with it in Wayland. As it stands, this is a severe and user-hostile regression from X11 to Wayland.

@mort Instead of asking a free software project to introduce weaknesses into the OS's security guarantees, perhaps you should be asking the multi-billion dollar company to port to the appropriate API that the OS provides for it.

The trade off here isn't good. Cost: any app can take over your system at any time. Benefit: Valve doesn't have to spend ~2 man-hours

It probably took them the same amount of time (if not more) to work around the API in SteamOS than it would take to fix Steam properly

@AdrianVovk I'm sorry but the operating system's job is to work for the user. I'm not asking them to "introduce a weakness", I'm asking it to have an *option* to work the way I want.

Your rhetoric here is indistinguishable from phone vendors who argue that they lock down their bootloader for "safety". Why should they introduce an option to make the system "insecure", just because the user foolishly want to run unsigned software? It's despicable.

(PS: I don't have much sway with Valve.)

@AdrianVovk There's probably not much use in continuing this discussion. I appreciate the context you provided. But I fundamentally disagree with denying people the ability to have their computer work the way they want "for their own good". Provide secure defaults and have scary warnings, but ultimately provide users the option to do "insecure" things. This is a fundamental value I hold with regards to computing broadly, and it saddens me that so many people disagree.

@mort As a user you're free to replace the implementation of the portal with your own or someone else's, that has whatever behavior you want. So the option you want exists, it's just not an on/off switch that's built into the OS. Seems like nobody has volunteered the time to implement a workaround (not even Valve - I just checked an apparently they just use X11 in desktop mode)

If you want to work on this I'd be happy to give pointers. But GNOME proper won't have this kind of backdoor access

@AdrianVovk On the one hand, you're against some hidden option to always allow remote control, but on the other hand you'd have no problem with someone making another portal implementation so that if you 'dnf install' that portal and change your portals.conf, you'd always allow remote control? How are these things different? Letting the user work around this issue by 'dnf install'ing a portal and changing portals.conf is exactly the kind of configuration option I'm advocating for here.

@AdrianVovk Actually, let me re-word this in a less antagonistic way, that tone was unnecessary.

I think it would be a great middle-ground to make a separate portal implementation which always allows applications to emulate input. I think having to install a separate portal implementation and changing portals.conf is an appropriate level of obstacles for an OS to put in the way of a user who wants to always allow remote control. I may try making something like it, I've worked with dbus some