7 ms·

Good security doesn't prevent users from executing a legitimate use case though. A user can have legitimate reasons for wanting to share a certain window or the

Good security doesn't prevent users from executing a legitimate use case though. A user can have legitimate reasons for wanting to share a certain window or their entire screen with a process like Zoom. Once you start preventing users from executing their use case you turn the user into an adversary. They'll start undermining your security model and you will always lose that fight. This is why permission models exist, make the user aware of the security implications and allow the user to decide on a per-app basis what permissions should be granted. Make the user complimentary to your security model rather than making them an adversary.

hackerbrother 4y ago
Is a standard Google Meet meeting in Chrome for Linux on a Wayland desktop not functional?
- deleted 4y ago
  [deleted]
- dralley 4y ago
  I use Google Meet on Firefox on Wayland. Screen sharing works fine (now). It didn't for a while, admittedly, but now it does.
  - linsomniac 4y ago
    I'm using Google Meet via Firefox on Ubuntu 22.04 and have not had any success with screen or window sharing, so YMMV.
- dijit 4y ago
  Usually not, no. There are two processes that need to be running that somewhat work. xdg-desktop-portal & xdg-desktop-portal-wlr Even then it can be garbled, only supports one screen, and you can’t use it if the process was started under Xwayland - which is opaque when it’s being used. Might be better under Firefox, but chrome is spotty for me.
  - jhugo 4y ago
    Disabling Xwayland, if you can, makes wayland a much better experience. Not possible for everyone, as you may have software that doesn't work on Wayland, but I ran my daily driver Arch laptop with sway and no X at all for years, everything worked really well.
    - bitwize 4y ago
      Xwayland is probably going to be deprecated and removed anyway. It's only included for backward compatibility with "legacy applications". It's like DOS compatibility on Windows.
      - deleted 4y ago
        [deleted]
      - dijit 4y ago
        Sincerely hope not, I’ll be forced to go back to X11 for jetbrains tools and everything electron based. (as the version that ships almost never has wayland support enabled in the sandbox browser- and even force enabling it where it isn’t compiled out crashes it randomly) EDIT: why did I get downvoted for that? It’s extremely true and I’ve tried to run without Xwayland a lot.
        jhugo 4y ago
        With Chromium having decent Wayland support since a while now, I expect Electron apps will catch up eventually. A major DE deprecating Xwayland would give packagers of Electron apps a reason to get around to it.
        Hackbraten 4y ago
        Have you had the chance to report those random crashes as bugs (against Electron or your compositor?) I figure that would be helpful for all. I’ve been using Electron apps natively on Wayland for quite a while with those force-enable flags you mentioned. Few issues so far. At one point, the apps indeed started crashing. Turns out this was due to the compositor (wl-roots) evolving while the Chromium team didn’t get the memo. They quickly fixed it in Chromium though but not before people started filing bugs. Didn’t take long for their patch to bubble up to the next Electron patch release. The sooner people report those crashes, the better for everyone involved.
wmf 4y ago
Wayland doesn't prevent anything that people need, but the APIs are different and apps need to be ported. (Worst case, certain features need to be implemented in the compositor itself not in an app.)
- nicce 4y ago
  Yeah. The most of the screen sharing and recording issues are easily solvable. It just takes engineering time, and time is money. As from the global user space, Wayland is in minority, for example for Zoom to create proper support.
Nursie 4y ago
> Once you start preventing users from executing their use case you turn the user into an adversary. I'm reminded of an early systemd security choice that killed all of a users processes on logout, for 'security'. Because they didn't personally have the use-case of wanting to fire off long-running jobs, so didn't consider it. (I'm not raging at systemd, I like the unit files and while I have some concerns about the design, in general I believe it's a positive thing to have around. IIRC this issue was fixed fairly quickly when it came to light.)
- usrn 4y ago
  They still do this. It really sucks when you don't expect it. I wish the people who wanted all this crap would just go run ChromeOS since it does what they want better anyway.
  - Izkata 4y ago
    Downvoters: The systemd default really is still to do this, it's just become less obvious because individual distros have been changing it since the initial fallout instead of accepting systemd's default configs.
    - Nursie 4y ago
      Really? Wow that is crappy. Yeah I haven't encountered it since way-back, partly because my use-cases have changed but also quite likely because debian and ubuntu (my general distros of choice) have configured it better.
      - kaba0 4y ago
        From a theoretical view, why is it a bad thing? I very much want my OS/service-manager to.. manage services and upon terminating my session, nothing should continue to run under it. Put another way, would you expect to get a higher bill on some cloud provider because after logout some userspace process (say, a dev server) continued to chug along? I do understand Hyrum’s law and that there are legitimate programs depending on decades old hacks like ignoring OS signals instead of exiting for some functionality - that could not be implemented other way back than. But these are trivially portable to user services that are meant to linger after logout (but hurrdurr, why depend even more on evil systemd) with like a few lines of configuration, solving all of these problems. Just remember, after a while every observable behavior of a program will be dependent on. If the alternative is forever stagnation, I very much prefer evolution and some manageable breaking changes instead.

hackerbrother 4y ago

Is a standard Google Meet meeting in Chrome for Linux on a Wayland desktop not functional?

deleted 4y ago
[deleted]
dralley 4y ago
I use Google Meet on Firefox on Wayland. Screen sharing works fine (now). It didn't for a while, admittedly, but now it does.
- linsomniac 4y ago
  I'm using Google Meet via Firefox on Ubuntu 22.04 and have not had any success with screen or window sharing, so YMMV.
dijit 4y ago
Usually not, no. There are two processes that need to be running that somewhat work. xdg-desktop-portal & xdg-desktop-portal-wlr Even then it can be garbled, only supports one screen, and you can’t use it if the process was started under Xwayland - which is opaque when it’s being used. Might be better under Firefox, but chrome is spotty for me.
- jhugo 4y ago
  Disabling Xwayland, if you can, makes wayland a much better experience. Not possible for everyone, as you may have software that doesn't work on Wayland, but I ran my daily driver Arch laptop with sway and no X at all for years, everything worked really well.
  - bitwize 4y ago
    Xwayland is probably going to be deprecated and removed anyway. It's only included for backward compatibility with "legacy applications". It's like DOS compatibility on Windows.
    - deleted 4y ago
      [deleted]
    - dijit 4y ago
      Sincerely hope not, I’ll be forced to go back to X11 for jetbrains tools and everything electron based. (as the version that ships almost never has wayland support enabled in the sandbox browser- and even force enabling it where it isn’t compiled out crashes it randomly) EDIT: why did I get downvoted for that? It’s extremely true and I’ve tried to run without Xwayland a lot.
      - jhugo 4y ago
        With Chromium having decent Wayland support since a while now, I expect Electron apps will catch up eventually. A major DE deprecating Xwayland would give packagers of Electron apps a reason to get around to it.
      - Hackbraten 4y ago
        Have you had the chance to report those random crashes as bugs (against Electron or your compositor?) I figure that would be helpful for all. I’ve been using Electron apps natively on Wayland for quite a while with those force-enable flags you mentioned. Few issues so far. At one point, the apps indeed started crashing. Turns out this was due to the compositor (wl-roots) evolving while the Chromium team didn’t get the memo. They quickly fixed it in Chromium though but not before people started filing bugs. Didn’t take long for their patch to bubble up to the next Electron patch release. The sooner people report those crashes, the better for everyone involved.

wmf 4y ago

Wayland doesn't prevent anything that people need, but the APIs are different and apps need to be ported. (Worst case, certain features need to be implemented in the compositor itself not in an app.)

nicce 4y ago
Yeah. The most of the screen sharing and recording issues are easily solvable. It just takes engineering time, and time is money. As from the global user space, Wayland is in minority, for example for Zoom to create proper support.

Nursie 4y ago

> Once you start preventing users from executing their use case you turn the user into an adversary. I'm reminded of an early systemd security choice that killed all of a users processes on logout, for 'security'. Because they didn't personally have the use-case of wanting to fire off long-running jobs, so didn't consider it. (I'm not raging at systemd, I like the unit files and while I have some concerns about the design, in general I believe it's a positive thing to have around. IIRC this issue was fixed fairly quickly when it came to light.)

usrn 4y ago
They still do this. It really sucks when you don't expect it. I wish the people who wanted all this crap would just go run ChromeOS since it does what they want better anyway.
- Izkata 4y ago
  Downvoters: The systemd default really is still to do this, it's just become less obvious because individual distros have been changing it since the initial fallout instead of accepting systemd's default configs.
  - Nursie 4y ago
    Really? Wow that is crappy. Yeah I haven't encountered it since way-back, partly because my use-cases have changed but also quite likely because debian and ubuntu (my general distros of choice) have configured it better.
    - kaba0 4y ago
      From a theoretical view, why is it a bad thing? I very much want my OS/service-manager to.. manage services and upon terminating my session, nothing should continue to run under it. Put another way, would you expect to get a higher bill on some cloud provider because after logout some userspace process (say, a dev server) continued to chug along? I do understand Hyrum’s law and that there are legitimate programs depending on decades old hacks like ignoring OS signals instead of exiting for some functionality - that could not be implemented other way back than. But these are trivially portable to user services that are meant to linger after logout (but hurrdurr, why depend even more on evil systemd) with like a few lines of configuration, solving all of these problems. Just remember, after a while every observable behavior of a program will be dependent on. If the alternative is forever stagnation, I very much prefer evolution and some manageable breaking changes instead.