Path: csiph.com!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: John Ames Newsgroups: comp.os.linux.misc Subject: Re: Artix Linux and Xlibre Date: Thu, 7 Aug 2025 15:56:22 -0700 Organization: A noiseless patient Spider Lines: 61 Message-ID: <20250807155622.00003411@gmail.com> References: <1063lgp$jmj$2@reader1.panix.com> <1064ag9$1kvkq$1@dont-email.me> <1064m75$1lvr1$1@dont-email.me> <10667je$35rkf$2@dont-email.me> <106bdkb$2s14s$1@dont-email.me> <106bjgj$2t9mq$5@dont-email.me> <106cld0$33q3n$2@dont-email.me> <106l5kp$133ed$3@dont-email.me> <106ohbv$1q0ne$1@dont-email.me> <106s6ae$2irb0$6@dont-email.me> <106thun$2tl20$1@dont-email.me> <20250805120229.00002255@gmail.com> <106ulcf$35j8e$3@dont-email.me> <20250806090124.00005af4@gmail.com> <10716ac$3ok85$4@dont-email.me> <20250807141447.000028d3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Date: Thu, 07 Aug 2025 22:56:27 +0000 (UTC) Injection-Info: dont-email.me; posting-host="0490a4cb91035f688bb39682abf3b577"; logging-data="356547"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19RW+a2jjTUFw+aS0hNtYVwd/NISU56hNI=" Cancel-Lock: sha1:tlZNGDjooTADbqJXmYErpY6DR4Y= X-Newsreader: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) Xref: csiph.com comp.os.linux.misc:70582 On Thu, 07 Aug 2025 23:14:04 +0100 Richard Kettlewell wrote: > As I=E2=80=99ve said before I=E2=80=99m not fully convinced by the Waylan= d design, but > when it comes to _saved_ positions in particular, I think that very > much belongs in the window manager rather than the application, for > several related reasons. >=20 > Firstly, it=E2=80=99s functionality that basically every application need= s; > making every application handle it explicitly is pointless duplication > of effort. In the general case, I'd agree - window managers already handle this on the regular for the majority of applications, usually present the user with options for configuring the default placement/sizing strategy, and that's all well and good. But it's one thing to provide a default behavior for don't-care cases and quite another to completely disallow applications from specifying or even hinting to the WM about relative positioning - which was the bizarro hardline stance taken by Wayland 'til they hit critical "people are yelling at us and won't use our stuff" mass. I don't doubt that there may be better ways to handle this than the way X11 does it - but looking for a better approach is not the same thing as writing the whole question off as a You Don't Need That. > I think there is a legitimate risk here. If a bit of malware that > looks like your bank=E2=80=99s website (as it would appear in a browser) > manages to position itself directly over the window that really has > your bank=E2=80=99s website at the point you=E2=80=99re expecting to ente= r your > credentials, you=E2=80=99re going to take a loss. >=20 > That doesn=E2=80=99t require intercepting global input (just input focus)= , or > scraping another window (what your bank=E2=80=99s website looks like is p= ublic > knowledge). As has already been pointed out, though, trying to solve "malware is being tricksy and evil" by clapping *all* programs in irons is a real "barricading the barn door and hiding punji traps in the barnyard after the cows have already gone" mindset. If evil software is running on the local machine under a valid user's session, the safeguards've *already failed* - anything with that level of access can snarf the entire $HOME and beam it right up to the mothership for analysis. There *is* something to be said about trick pages running in a Web browser from some unknown source, but these don't even need to pop up a separate window most of the time - major browsers in their default configuration will happily open a new tab and switch right over to it with nary a sign that anything is questionable, and they'll drive users right to these pages, too, responding to an address being typed in the URL bar with a list of SEO-baited scam pages that naive users will just click on rather than finish typing. This is an *atrocious* failure of security practices - but it's a failure on the part of search engines and browser developers, *not* the display server/window manager.