Idea: Wayland firewall between applications and compositor

[probonopd]

The windowing system is not the place to restrict what applications are and are not allowed to do.

Some types of users or use cases may require some level of sandboxing (restricting what applications can do). However, I think this concern should be addressed on another level. Just like in the Internet, all packets flow from A to B by default, and then there are separate things called firewalls that deal with blocking certain unwanted packets.

Wayland should work by default (like X11 does), and blocking things should be a separate concern, just like how the Internet works.

Unfortunately, Wayland today seems to get this backward - it appears to be more concerned with restricting, compartmentalizing and generally removing freedoms than to make things just work.

Application that is forced to use Portals <-> Wayland compositor that does not fully work without Portals

So I propose this architecture:

Application <-> Optional Wayland firewall(s) that may or may not use Portals <-> Wayland compositor

In this architecture, the "restricting what users can do" stuff would not be a separate component, Portals would be nicely separated and not tied directly to applications nor the Wayland compositor, and would be entirely optional.

The optional Wayland firewall(s) might decide to use Portals if they are available, or block access with a warning that a certain Portal is missing, or (at the user's configuration choice) just let through requests uninterrupted (that would otherwise require a Portal).

This would essentially allow Gnome to operate just like today (they would simply write a "bubbleland" Wayland firewall that would use all of their Portals) where as, e.g., GNUstep or helloDesktop might choose to ship without a Wayland firewall by default.

[ssokolow]

I think the inspiration for the Wayland approach was that Google Chrome/Chromium would crash if you tried to run it with the Wayland-like X11 security extension enabled and Google's response was "Not a supported configuration. Turn that extension off."

(i.e. Force Google to accept it as a supported configuration.)

[myownfriend]

Most software works completely fine within Wayland's security restrictions. Most software doesn't need to see the contents of other application windows, receive input when it's not the active window, or control input so why flip it's security model default to benefit a far less common scenario?

In this architecture, the "restricting what users can do" stuff would not be a separate component, Portals would be nicely separated and not tied directly to applications nor the Wayland compositor, and would be entirely optional.

It's not restricting what user's can do. You're misrepresenting the scenario to sound like a freedom fighter or something. What you're complaining about is the method that app developers are able to implement certain features. The reason for requiring an application to get permission to do something that could be a security risk is so that the user has more control over the application, not the other way around.

What you're suggesting is something like a reverse sudo: instead of requiring applications to prompt for a password when they need super user privileges, you're idea is like letting all applications work with super user permissions by default and requiring the user to manually restrict them.

Some types of users or use cases may require some level of sandboxing (restricting what applications can do). However, I think this concern should be addressed on another level. Just like in the Internet, all packets flow from A to B by default, and then there are separate things called firewalls that deal with blocking certain unwanted packets.

This isn't remotely like the Internet though. The Internet isn't the Internet unless it can communicate with another computer . That's not just the common way the Internet works, it's the only way. Selectively restricting packets via a firewall makes sense there.

That being said, the Internet isn't completely open with the absence of firewalls. Web APIs have a lot of restrictions for security purposes. A web browser won't even let you drag and drop or upload a file to an JS application running locally because of the Cross-Origin Resource Sharing (CORS) policies. For security purposes CSS Paint only lets you use a subset of the canvas 2D API without the ability to draw text. Web browsers also don't have a standardized way to display the contents of what element in the background of another. Every browser also asks for your permission if a website want to capture your screen or audio.

[probonopd]

Most software works completely fine within Wayland's security restrictions.

Mine doesn't. I will happily accept your pull requests to make it work.

It's not restricting what user's can do. You're misrepresenting the scenario to sound like a freedom fighter or something.

Then please inform me how my application, under Wayland, can:

• Set arbitrary icons on windows
• Position windows at arbitrary pixel coordinates on the screen just to name some examples.

Stuff that is entirely non-controversial and easy to do in other environments.

If I sound like a freedom fighter, then it is because I am. I am trying to preserve my freedom to create my desktop environment and applications like I want, and not have dictated by the display manager people that my software has to work like Gnome.

And how can I do all the screen capturing and sharing stuff without getting Portals and Pipewire forced onto me? My goal is to have a GLib-free desktop.

[myownfriend]

Mine doesn't. I will happily accept your pull requests to make it work. That's because you're creating a DE made out of a bunch of client applications. You can do that in X11 because clients can do anything and everything to anything and everything.

That isn't how a Wayland desktop works though. The top bar and dash in Gnome aren't just Wayland clients that are positioned at the top of bottom of the screen and panels in Plasma don't work that way either. They're parts of the shell which runs atop the compositor.

If you create HelloSystems as a shell with Menu and Filer as components then you can place those components wherever you want without having to deal with Wayland because those components would be privileged.

Then please inform me how my application, under Wayland, can:

* Set arbitrary icons on windows

* Position windows at arbitrary pixel coordinates on the screen
  just to name some examples.

This was your response to me saying "It's not restricting what user's can do." Users of an application don't set arbitrary icons on windows and a user can certainly position a window in arbitrary places on the screen.

What you're asking is how an app developer can make their application do these things. That's a separate question.

Unfortunately there currently is no good way for a developer to do either of these things. There are two proposed protocols though. These two things aren't essential to development of 99.9% of applications though.

I sound like a freedom fighter, then it is because I am. I am trying to preserve my freedom to create my desktop environment and applications like I want, and not have dictated by the display manager people that my software has to work like Gnome.

Nobody is saying that your shit needs to run like Gnome. I have no idea why you keep bringing Gnome up. Nearly every major desktop either already supports Wayland or is in the middle of adding Wayland support. The fact that all of these different desktops that work very differently are all able to use Wayland and you're having issues should raise some questions for you like "How are they doing it?" and "What am I doing differently?"

And how can I do all the screen capturing and sharing stuff without getting Portals and Pipewire forced onto me? My goal is to have a GLib-free desktop.

Why do you want a Glib-free desktop? That doesn't do anything at all.

There apparently is a way to screen captures with Pipewire without Portals but I don't know how. Portals are just the preferred method of doing it.

[probonopd]

That isn't how a Wayland desktop works though.

And that is the problem. I want my desktop to work like I want it to work, not how "a Wayland desktop" works.

Unfortunately there currently is no good way for a developer to do either of these things.

See. Hence this repository, to make these things work with minimal fuss.

Why do you want a Glib-free desktop?

Because it is Gnome minus the UI, and as I said, I don't want my system to work like Gnome.

[myownfriend]

And that is the problem. I want my desktop to work like I want it to work, not how "a Wayland desktop" works.

So you want it to work like shit? Unfortunately most people don't want their desktops to work like that.

See. Hence this repository, to make these things work with minimal fuss.

No it's not. This is protest repository made for people to complain about Wayland in an echo chamber while still not sitting down and actually writing a single protocol or familiarizing themselves with what is already part of the protocol. Not only is this repository separate from official repository, you didn't even make it on the same site.

Because it is Gnome minus the UI, and as I said, I don't want my system to work like Gnome.

No it's not. It's library used by tons of software. It hasn't been part of GTK since before GTK2 and while Gnome software tends to use it, it's also used by non-Gnome software. Davinci Resolve and Fusion are developed by Blackmagic Design and uses glib but it's UI uses Qt. It has literally no influence on how your system works outside of software that uses it.

[probonopd]

So you want it to work like shit?

"Work like shit" is subjective. My reference for what a good graphical desktop is predates mobile computing by a very long time, and I am increasingly fed up with computers not just doing what we (the people = application developers and end users) want. For example, if you download a ZIP in the default browser on Windows it warns you that the download might be dangerous or whatever. That's "work like shit" for me. If I download a zip, I want to download a zip, period.

This is protest repository made for people to complain about Wayland in an echo chamber while still not sitting down and actually writing a single protocol

The first protocol proposals are there now. They might be rudimentary, they might be incomplete, but since this is a community effort, I trust that together we can make something work. The interest from the community seems to be there - I never had so many stars so quickly on a repository that only contained a README.

Not only is this repository separate from official repository, you didn't even make it on the same site.

Exactly, because just watching the echo chamber that is upstream makes it evident that they would discuss this effort to death. They welcome third-party protocols, they'll get third-party protocols. If they end up liking them (e.g., because they turn out to be hugely popular with users and application developers), they can even upstream them if they like. If not, that's fine with me, too.

uses glib but it's UI uses Qt

I have dealt with such software myself. It's "lipstick on a pig". Ended up throwing the whole thing away and reimplemented everything in pure Qt.

[myownfriend]

"Work like shit" is subjective. My reference for what a good graphical desktop is predates mobile computing by a very long time, and I am increasingly fed up with computers not just doing what we (the people = application developers and end users) want.

"We" in this case, just means you. I'm not trying to shit on your project but I tried out HelloSystem. While I think it's nice from a user experience that applications are one file that are effectively uninstalled by just deleting them, that's kind of where my positive opinion of it ends. It doesn't work remotely like how I would like things to work.

For example, if you download a ZIP in the default browser on Windows it warns you that the download might be dangerous or whatever. That's "work like shit" for me. If I download a zip, I want to download a zip, period.

For example, having Filer work as the desktop and the File manager without differentiating between their role in Processes means that someone can inadvertently close the Desktop. Yea it just relaunches but the same isn't true of Menu. At least in the stable release, closing Menu locks you out of a way to access any software other than what's already open. If you have a folder on your desktop than you can open that in yet another instance of Filer but because there's no paths or navigation, you can't go up a directory to eventually relaunch Menu.

Also despite it's simplicity, it's reliance on AppImages means that there's no shared resources and everything uses up a lot of memory. It runs a fraction of the amount of processes that Ubuntu runs yet it uses up the same amount of RAM (~1.4GBs) on start up. Htop actually claims that Ubuntu is using only ~930MB at startup though so it could be using much less memory. I really don't know which program measures RAM usage in a way that's more similar to Processes so I don't know which numbers are the most comparable. I do know that there were some processes in Ubuntu that could be killed though so it would use even less (~820MB).

That's what "works like shit" means to me. Edge warning the user when downloading a zip file is a annoying but it at least has a purpose. HelloSystem is a lot of effort into looking and working like an old system while using like 10x more memory than it's inspiration used.

The first protocol proposals are there now. They might be rudimentary, they might be incomplete, but since this is a community effort, I trust that together we can make something work. The interest from the community seems to be there - I never had so many stars so quickly on a repository that only contained a README.

Just because people are vocal about something doesn't mean they're put any actual effort into something.

Exactly, because just watching the echo chamber that is upstream makes it evident that they would discuss this effort to death.

If it were an echo chamber than they wouldn't be discussing stuff to death, they would just be pushing out protocols left and right. There's frequently disagreements in the main repo. Part of what happens when you collaborate with people to make something that works well for a larger group is that disagreements happen.

They welcome third-party protocols, they'll get third-party protocols. If they end up liking them (e.g., because they turn out to be hugely popular with users and application developers), they can even upstream them if they like. If not, that's fine with me, too.

That's not gonna happen.

I have dealt with such software myself. It's "lipstick on a pig". Ended up throwing the whole thing away and reimplemented everything in pure Qt.

Good for you. That doesn't counter the claim that Glib is Gnome minus the UI. That was dumb statement.

[probonopd]

It doesn't work remotely like how I would like things to work.

That's totally ok. Different people have different ideas about how they like things to work. This is what leads me to using open source in the first place - we can form environments that work like we want them to work. This is also why I don't like it when some self-appointed architects think they have the power (and authorization) to speak for everyone.

[ssokolow]

Good for you. That doesn't counter the claim that Glib is Gnome minus the UI. That was dumb statement.

*nod* Glib is sort of like the Rust standard library in its scope.

It's the undercarriage needed to build an ecosystem of libraries that interoperate at a level higher than C ABI. In Glib's case, an event loop, an implementation of a C++-esque object system and interface definition language for C, a file I/O abstraction, etc.

I may hate GNOME's UI direction for a lot of reasons, but GObject and GObject Introspection are something I really wish Qt would borrow from them since it makes it so easy for you to write one binding like PyGObject and then gain high-level, memory-safe access to every library on the system with an installed GIR definition file.

[probonopd]

Thanks for having tried out helloSystem. Even though this is off-topic here, let me quickly answer (but collapse it as off-topic so as to not disturb others).

For example, having Filer work as the desktop and the File manager without differentiating between their role in Processes means that someone can inadvertently close the Desktop.

How? The Filer application has no "Quit" command. (Just like the Mac has been working since 1984.) Yes, you could kill the process - but then it should just restart. The same should be true for Menu (if it doesn't, it's a bug).

At least in the stable release, closing Menu locks you out

If you can "close Menu", that's definitely a (known) bug. Menu needs to be running all the time, and if it ever gets killed, it needs to be restarted immediately. Again, how it's been on the Mac since forever.

Also despite it's simplicity, it's reliance on AppImages means that there's no shared resources and everything uses up a lot of memory. It runs a fraction of the amount of processes that Ubuntu runs yet it uses up the same amount of RAM (~1.4GBs) on start up.

You realized that you are comparing FreeBSD to Linux here? Apples to oranges. But even then, it seems to be at least on par with Ubuntu in terms of memory usage (although I am always looking for ways to further decrease it by removing bloat).

helloSystem uses application directories. For the applications provided by the system, these are not even self-contained to maximize sharing. It doesn't "rely" on AppImages (although it can run some of them by the help of the Linuxulator which is built into FreeBSD).

HelloSystem is a lot of effort into looking and working like an old system while using like 10x more memory than it's inspiration used.

Point! Shows how bloated the frameworks really are that we have to work with today. Classic Mac OS achieved much of the same user experience in a tiny fraction of the memory - but then, it was written largely in a combination of Assembly and Pascal. But again, my philosophy is "make something work first and optimize it later", so if you have tips on how to significantly reduce resource usage (especially of web browsers!), then you definitely have my attention (yes, I am interested in SerenityOS and its Ladybird browser).

If it were an echo chamber than they wouldn't be discussing stuff to death, they would just be pushing out protocols left and right.

If it weren't an echo chamber, than the obviously needed stuff (like pixel-precise prescriptive window placement and setting arbitrary icons on windows) would have been there since a decade or so.

That's not gonna happen.

If not, that's fine with me, too.

[probonopd]

That doesn't counter the claim that Glib is Gnome minus the UI.

It was designed by Gtk for Gtk. It's even in their URL. https://docs.gtk.org/glib/

[ssokolow]

That doesn't counter the claim that Glib is Gnome minus the UI.

It was designed by Gtk for Gtk. It's even in their URL. https://docs.gtk.org/glib/

It's like systemd or democratic government. Everyone's using it because it's the best of a bunch of bad options and everyone got tired of waiting for someone who hated it to come up with a better alternative.

Basically, library developers needed something to serve a similar role to Microsoft COM for library interop, and Glib was what was available.

[probonopd]

Gotta make choices.

[ssokolow]

Gotta make choices.

*nod* ...and I respect that. I'm just saying that's the reason you're going to be fighting an uphill battle against Glib.

Hell, I agree with most of your decisions.

(The exceptions being things like "I'm not a spatial file manager guy", "I think Rust would be better suited to your use case than Go for reasons X, Y, and Z", "I don't like using disk images because they force a trade-off between space conservation and application startup performance", "I like delegating busywork to package managers", "I don't believe your stance on security is viable in real-world scenarios in the 2020s", "we already have enough things where I have to manually chop off the file:// from something a third-party application gives me to get my non-KDE apps to accept it so let's mandate accepting them", and "Thank God for Portals. I can finally stop relying on crash-inducing LD_PRELOAD hacks like KGtk to get KDE file pickers in my GTK applications".)

[myownfriend]

If it weren't an echo chamber, than the obviously needed stuff (like pixel-precise prescriptive window placement and setting arbitrary icons on windows) would have been there since a decade or so.

By what logic? lol I'm not sure you understand how echo chambers work. Are you under the impression that nobody has proposed absolute positioning in Wayland before? There was a disagreement and the side that you would have been on lost.

Also Wayland had only just had it's first release with stable server API 10 years ago. I understand why you want a protocol for setting icons on windows but outside of AppImages, .desktop files worked just fine for most applications. Literally the only time that I remember seeing an application change the icon in it's window was File Explorer in the Windows 7 era. Most applications just have an application icon that may or may not be shown in it's title bar.

Also think of any tiled window manager. They don't have window decorations anyway so there often isn't a place for a window icon to show.

If you take all that into account, it's not a surprise that something like that wasn't a priority.

It's even in their URL. https://docs.gtk.org/glib/

I'm not sure what you think that URL is conveying lol