The CSD Initiative Is Pushing For Apps To Abandon Title Bars In Favor Of Header Bars

[ssokolow]

Could you elaborate a bit on the WM vs compositor distinction? To me they are the same, and this is an artificial distinction; maybe that's more true on wayland though. Do you make this distinction trough the protocol? (d-bus vs wayland -- I don't even know what the message passing interface is with wayland? A C API?)

X11 has Window Managers and the model was hacked up to allow a WM to composite. (Though Beryl and Compiz Fusion created a non-standard interface to split the functionalities apart again so that the Compiz "WM" can have pluggable decorators like Emerald to draw the borders.)

In Wayland, compositing is mandatory (it's just a question of whether it's done in the GPU or using a software fallback) and the display server, compositor, and window manager are collapsed into a single program. If you want to split the WM part back out, that's up to the compositor to provide an API for it.

(Code sharing between Wayland compositors is accomplished via shared libraries rather than by having multiple processes communicating via some form of IPC which would also have to somehow enforce the Wayland security guarantees.)

albeit of doubtful usefulness

The idea was that things like media player playback controls, IM client status controls, e-mail client unread notifications, and so on, might be exposed via DWD and then KDE Connect wouldn't have to rely on each application developer supporting an MPRIS-like D-Bus standard in addition to their usual GUI.

[RelaxTrolls]

(It's for that reason that I was surprised when I discovered Weston was CSD-based. Given the Wayland focus on security and keeping users in control of their desktop, it seems odd that they'd allow potentially malicious applications so much freedom to meddle with the most intuitive workflow for moving and closing windows.)

I don't know why you would be surprised that Weston would be CSD... SSD is less efficient, on resize, moving windows, etc - you end up having more overhead, there is more than a single window / surface being drawn, etc...

while it's true that CSD isn't specified in the Wayland protocol, it definitely is specified (or strongly suggested to use) by the reference compositor, Weston...

I don't see how CSD is a security concern - could you please elaborate? maybe give a more specific example? how would a malicious application use CSD, exactly?. ... are you trying to suggest that because a toolkit implements, CSD - now some rogue app can sisallowme from moving it or closing it?. ... if so, that doesn't seem to be an issue, in practice, afaict.

[ssokolow]

I don't know why you would be surprised that Weston would be CSD... SSD is less efficient, on resize, moving windows, etc - you end up having more overhead, there is more than a single window / surface being drawn, etc...

while it's true that CSD isn't specified in the Wayland protocol, it definitely is specified (or strongly suggested to use) by the reference compositor, Weston...

I don't see how CSD is a security concern - could you please elaborate? maybe give a more specific example? how would a malicious application use CSD, exactly?. ... are you trying to suggest that because a toolkit implements, CSD - now some rogue app can sisallowme from moving it or closing it?. ... if so, that doesn't seem to be an issue, in practice, afaict.

I'm thinking of three factors:

1. As an indication of the kind of trickery actually in the wild, right up until Firefox switched to only allowing signed extensions, "utilities" that come with browser toolbars and the like would exploit Win32's support for programmatic window repositioning to manipulate users in the "Firefox allows unsigned extensions, but external installs trigger a permissions prompt" era by using shaped windows to draw overlays that made it look like Firefox itself was requiring that you OK the permissions prompt to continue.
2. If the application is responsible for drawing the titlebar, it can draw things which trick users into thinking the window cannot be moved or closed without agreeing to its terms. (Even if Weston chooses to require active regions, they can be drawn so they don't look like active regions.)
3. Even with the new Firefox extension paradigm, when I go to help non-geek family friends with their computers, I often have to clear out dozens of useless extensions bogging down their browsers that, as far as I can tell, they agreed to installing because they thought they were necessary to use the sites for things like recipes that they googled up. If that's representative of the average non-technical non-millennial (which is the demographic that CSD-using GNOME has always seemed dead-set on targeting, by the way), and this is supposed to be used in concert with Flatpak's sandboxing, you REALLY don't want applications having that degree of control over the only method of resizing or moving windows that tends to come to mind for such people.

[RelaxTrolls]

I'm thinking of three factors:

1. As an indication of the kind of trickery actually in the wild, right up until Firefox switched to only allowing signed extensions, "utilities" that come with browser toolbars and the like would exploit Win32's support for programmatic window repositioning to manipulate users in the "Firefox allows unsigned extensions, but external installs trigger a permissions prompt" era by using shaped windows to draw overlays that made it look like Firefox itself was requiring that you OK the permissions prompt to continue.
2. If the application is responsible for drawing the titlebar, it can draw things which trick users into thinking the window cannot be moved or closed without agreeing to its terms. (Even if Weston chooses to require active regions, they can be drawn so they don't look like active regions.)
3. Even with the new Firefox extension paradigm, when I go to help non-geek family friends with their computers, I often have to clear out dozens of useless extensions bogging down their browsers that, as far as I can tell, they agreed to installing because they thought they were necessary to use the sites for things like recipes that they googled up. If that's representative of the average non-technical non-millennial (which is the demographic that CSD-using GNOME has always seemed dead-set on targeting, by the way), and this is supposed to be used in concert with Flatpak's sandboxing, you REALLY don't want applications having that degree of control over the only method of resizing or moving windows that tends to come to mind for such people.

win32 and Gtk are different - so I'd like to know if you can demonstrate your example of ''trickery in the wild'', or rather could you demonstrate it at the time, being as we aren't talking about windows, but linux...?

from what I understand, firefox is actually removing exposing some of the gui's internals to users, sooner than later. (userChrome.css being one bit, that people seem to be pissed about)... so it's very possible that your example may be N/A, or could be sooner than later... I guess you might need to put together a demo to show it in action or something.

another thing to note is that while clients are responible for rendering, window management and composition are handled in a given wayland compositor, not by the client.

on top of that, i'm not sure that your example of friends misconfiguring firefox extensions is a valid argument against CSD. it seems liike a big stretch... how is CSD being targeted at millenials??! (ROFL). no, CSD is pretty much the standard on all of the major desktop OSes - due to it being cleaner, less overhead, simplified rendering, better resizing, window positioning, etc... I highly doubt there is some conspiracy to target millenials with CSD...lmfao...

also, I use gnome, prefer CSD, am not a millenial and am a technical user....idk, man. I think there are pretty good pros and cons and arguments to each approach (SSD vs. CSD), but yours (especially that last part. lol) isn't one of them...

lastly, wouldn't your 2nd example also be just as doable on SSD anyway? like rather than doing so in the decoration, you could just do that in app window anyway? (making it kind of a mooot point).

[jm111]

That's fine. It's for technical people.

I just hope that screenshot was a collection of components and not supposed to be an actual UI.

[jm111]

I like the idea of applications being able to do their own thing. It's just that Linux designers typically try to do the exact opposite of what works.

The screenshot in the article looks butt ugly to me.

I am no fan of Thunderbird and Firefox's style, I don't particularly like Opera's style either. Chrome, yes, Chrome did it nicely (on Windows).

I don't mind innovation. I like individualism. But there is a strong guarantee Gnome's designs will turn out unpleasant.

Windows 10's random button placement in title bars is deeply annoying.

I understand that menus take up a lot of space and most of the time you don't need them, in some applications. And the title bar can be integrated with the window, and disappear.

But abusing the title bar in a non-maximized window for additional buttons is the exact opposite of making it disappear and has no practical use because the amount of content you could place in it is always going to be severely limited.

I WANT applications to be able to hide their title bar and integrate buttons in their main window, in some CSD style.

I DON'T WANT them to abuse title bars for non-standard stuff; a title bar should be UI-wide, but an application should be able to hide it and do it's own thing.

I really don't see the use case for anything else other than perhaps custom window menus but even that thing would be all about unique appearance and can be done in the main window, OR would only serve the purpose of adding additional menus in the existing menu style.

I don't see a good use case for individual window menus, so I stand by my statement that everything an application wants to do, it should do in its own window,

and just ask the window manager to turn decorations off.

Very simple, doesn't require a lot, and everyone is happy.

[ssokolow]

win32 and Gtk are different - so I'd like to know if you can demonstrate your example of ''trickery in the wild'', or rather could you demonstrate it at the time, being as we aren't talking about windows, but linux...?

My example was intended to demonstrate the degree to which bad actors are willing to creatively abuse whatever power you give them. If you want a native Linux example, despite Windows being so much more valuable to target at the moment, here are two cases:

1. The first end-user-targeting malware for Linux was uploaded to GNOME-Look back in 2009 as a .deb that claimed to be a screensaver and installed a DDoS bot. (which took advantage of the lack of sandboxing on.deb install scripts to apply changes that didn't get reversed when you uninstalled the .deb).

2. As an example of how dodgy even legitimate, honest apps can get in their attitude toward user interaction, the Dropbox client loves to ask for root when you start it so it can meddle in settings for your benefit.

from what I understand, firefox is actually removing exposing some of the gui's internals to users, sooner than later. (userChrome.css being one bit, that people seem to be pissed about)... so it's very possible that your example may be N/A, or could be sooner than later... I guess you might need to put together a demo to show it in action or something.

Would you mind clarifying where you're getting your info?

If you mean Benjamin Smedberg's comment in Bug 332529 11 months ago, this commenter on /r/firefox pointed out the following:

That particular comment was made by a developer who has been 'threatening' to remove the Profile Manager from Firefox for over 10 years. And in that >10 years Mozilla has introduced three 'new' Profile Manager schemes; the XUL Runner application in 2011 (done by interns), the Developer Edition PM scheme that automatically creates a 2nd Profile for "developers", and the aboutrofiles internal page, which came from Developer Edition PM improvements.

So much for his opinions about code that he doesn't "own", when he unable to achieve consensus for removing the code that he does "own" - the PM.

If you mean Bug 1416044 (Add telemetry for userChrome.css usage), the most recent comment (2 months ago) said "I'm not sure where you are getting this idea? The act of measuring usage doesn't imply any intention to remove a feature." and the intention stated in earlier comment is to get a better idea of how much to prioritize further expansion of the new theming API and configuration UIs.

another thing to note is that while clients are responible for rendering, window management and composition are handled in a given wayland compositor, not by the client.

Yes, which is why bad actors will focus more heavily on "wetware hacking". (ie. Exploiting the confused deputy problem to have the user either not exercise the veto power guaranteed them by the compositor or act against their own best interests.)

on top of that, i'm not sure that your example of friends misconfiguring firefox extensions is a valid argument against CSD. it seems liike a big stretch... how is CSD being targeted at millenials??! (ROFL). no, CSD is pretty much the standard on all of the major desktop OSes - due to it being cleaner, less overhead, simplified rendering, better resizing, window positioning, etc... I highly doubt there is some conspiracy to target millenials with CSD...lmfao...

You completely misunderstood my point. I said that GNOME has historically used "because it will scare/confuse grandma" as their rationale for excising features. That means they're targeting NON-technical NON-millennials to the detriment of those who use the more advanced features.

Firefox is an example of how, despite all the effort poured into ensuring the user remains in control, bad actors can still do a surprising amount of bad stuff in such a constrained environment by "hacking the user" rather than hacking the system.

also, I use gnome, prefer CSD, am not a millenial and am a technical user....idk, man. I think there are pretty good pros and cons and arguments to each approach (SSD vs. CSD), but yours (especially that last part. lol) isn't one of them...

You just admitted that you are a technical user. Therefore, you're not part of the demographic that this kind of "wetware hackery" typically targets.

lastly, wouldn't your 2nd example also be just as doable on SSD anyway? like rather than doing so in the decoration, you could just do that in app window anyway? (making it kind of a mooot point).

Look up Clickjacking/UI redressing attacks. CSD enables them, SSD does not.