X11 screen locking: a secure and modular approach
leahneukirchen.org
leahneukirchen.org
* The screen doesn't lock, and remains on while the lid is closed.
* The screen doesn't lock, but does turn off when the lid is closed.
* The screen locks, but the machine doesn't suspend when the lid is closed.
* The screen doesn't turn on after the lid is opened. Key commands work, though.
* The screen turns on after the lid is opened, but is blank (no unlock requestor).
* The machine doesn't resume from suspend, requiring a hard reset.
* The screen locker gets completely bypassed and you're dumped into the desktop (possibly a fresh desktop because the entire environment crashed and restarted).
Throw remote desktop into the mix and you're in for a world of hurt.
I just disable screen locking, and make suspend a manual operation to keep my sanity intact. The trackpad still stops responding sometimes though...
Desktop environments are now reaching that threshold because users demand "modernity" and fanciness. They would be fantastically served by a desktop with the capabilities of Windows 9x, MacOS 7.x, or AmigaOS 3.x, but they demand much more than that, and the Windows and MacOS teams (and code bases!) have bloated in size to meet this demand.
These problems showed up much earlier in Linux because in order to release a desktop OS, you need someone exercising strict control over all aspects of the system from the kernel (and even lower than the kernel, like the hardware and firmware) all the way up to the shell, GUI toolkit, and other user-visible features. You need that leadership to define and prioritize work and even prioritize OS concerns. (For example, a desktop OS should handle keyboard/mouse interrupts IMMEDIATELY.) You need to enforce a single set of user concerns on everybody, and fire anyone who doesn't play ball. And with Linux and open source, good luck getting everybody on the independent kernel, libc, X, and GUI projects to cooperate this way.
Me, I've always been content with like fvwm95 (or lately, i3) and whatever independent programs I needed for desktop tasks. And if I have to say 'pm-suspend' at a command prompt to put my computer tk sleep, so be it. I can see the many hands all making the world a slightly better place, and since their work is all loosely coupled, it all sort of hangs together and is very robust. Conventional desktops are brittle to start with, and made even more so under Linux because of those issues I mentioned.
Do they? Do they really? Because I struggle to think of a change made in how I or anyone I know's desktop works that we actually think made things better. The last one I can think of was when Windows added start-typing-search to the start menu back in, what, 7?
I'm not dismissing that other people might be demanding some "modern"/"fancy" features, but if so what the heck are they? What I see is GUI redesign for the sake of it, or hiding of options in order to promote more "desired" (by the vendor) options.
Also, this is why I don't use Linux any more. It's grown into a dumpster fire of ad-hoc patches from big corps looking to hammer every last drop of cloud server performance or poorly designed desktops made by people who obviously don't use them.
Plan 9 front is my daily driver with OpenBSD/FreeBSD if I need a Unix. Windows 7 still powers my gaming rig by it most likely will move to Linux because Steam. Probably the only reason I need Linux and Windows 7 still isn't enough of a reason to switch....
Do you mean the design part or the coding part? From my limited experience desktops are made by contributors and volunteers work on whatever affects them the most or some might work on cool stuff. It is what it is, without someone with money hiring a large dev team and foucssing on user tickets it will never change. As a developer I prefer something customizable like KDE where I can fix a crash in an app if I hit it over a Windows like experience where important apps like the screen magnifier had hard coded shortcuts and you could not customize them.
That's true of proprietary software to roughly the same extent: if I don't like how things are I am free to make my own or just not use it.
I understand why compiling sucks though and this is why I am considering to use Python for a program I want to make and open source despite the fact I dislike it's syntax.
If emacs, SBCL & Firefox ran on Plan 9, I would see no reason to bother running Linux on hardware. But they don’t, and they probably never will.
Maybe when I retire I’ll have time to work on porting them, but I have a long time until then!
Emacs is a poor fit as it already is an OS. plan 9, an operating system which encourages programs to talk to each other, offers no advantages to a monolithic text editing operating system. You're better off learning sam or acme and learn how they interact with the platform which is where their power comes from. That's how you use plan 9, you work with it, harness it. It's a kind of "be one with the os" zen thing.
SBCL I have no experience with but my guess is all the tooling and libraries are built around a 50 year old operating system. Porting languages isn't that big a deal, we have a buch like ocaml, python, Go, pforth, and maybe hugs/haskell among others. The issues are libraries which assume some unholy assortment of unix/posix/linux/whatever bindings and dependencies. plus we have no c++ because few at bell labs thought much of it even though they spawned it. Tells you something.
Firefox. The big one. The modern web browser is a primitive document viewer from the 90's which borrowed ideas put forth some 25+ years earlier by Ted Nelson and others in the 1960's and demonstrated by Doug Englebert in the MOAD. Now it can run computer code while displaying video, audio, text and images on your already existing computer. In plan 9 we would use separate tools to accomplish these tasks. A web browser would at most need to render html, ccs and handle basic javascript. The more complex stuff like pdf, audio and video should be plumbed to external programs which can be removed or swapped out as needed.
I beg to differ. Emacs is an excellent text-based operating environment, simply the best, without peer. I’ve used sam & acme, and they don’t compare.
> SBCL I have no experience with but my guess is all the tooling and libraries are built around a 50 year old operating system.
Some of the hairiest bits of Lisp (e.g. the pathname abstraction) are due to the fact that it doesn’t assume Unix.
Regardless, while I would prefer to boot directly into some sort of 21st-century Lisp OS which takes a lot of great ideas from Plan 9, that doesn’t exist; Plan 9 does. And if I ever get the spare time I intend to port Emacs & SBCL. And hope someone else will port Firefox.
There are some kinks to be worked out. I'm seeing the following scenario:
I have Ori and the Blind Forest installed through Steam on Ubuntu 18.04. Attempting to play it through the steam client causes a crash. Navigating to the install directory in a terminal and running the simple command `wine oriDE.exe` runs the game with zero apparent problems.
Of course Steam isn't using the local wine installation, but... still? The game works flawlessly with the absolute bare minimum of effort. What's Steam doing instead?
(I tried watching the startup process in the Steam console, but it appears to be committed to printing only uninformative messages.)
But your alternative is one totally locked on ecosystem and one provided with embedded spywares.
It's good enough, and since we are not giving millions of dollars to the editors like we do with products disrespecting us, I understand we can't ask for perfection.
I've been hearing that for between 15 and 20 years now. I believe this mentality is part of the reason it never seems to get any better.
It's not even a brand that's well-known for Linux compatibility (like Thinkpads), but all I've had to do to get Lubuntu 18.04 running more or less flawlessly was disable Secure Boot in the BIOS. Wifi, sound, and webcam all worked without needing tinkering. Bluetooth appears to work based on it being detected, but I haven't tried pairing anything yet. The only thing I hear doesn't work is the fingerprint sensor, but I wasn't going to use it, anyway.
Suspend on lid down and wake on lid up hasn't been an issue at all. I'm actually very pleasantly surprised at how well this LTS version from 2018 runs on a 2020 model laptop.
Or maybe it’s that authoring and supporting drivers for actual hardware is tremendous effort that is mostly thankless.
Even Microsoft can’t get something much better and they literally have billions they need to throw at it.
Oh, if only drivers were the only part of Linux Desktop that was broken...
I've been using linux for 15 years. It's better in every way.
My mother has been using Ubuntu for 7 years now. It would have been impossible in the early 2000.
It is better. It is productive. It is even a good experience. I'm no a masochist, I buy and use proprietary software. I use Linux because I want to.
I'm not just not blind to it's many shortcommins.
Last week I used Windows with a client. I had to disable Windows update because it was eating all the Ram. Some people are literally buying a new mac because the mechanical keyboard is unusable on some models.
There are systems you complain about. And systems nobody use.
I love linux, but it's not wart-free.
https://twitter.com/BenoitLetondor/status/939127296266588160
The only thing “by far” about Windows 10 is the distance it should be defenestrated.
In other news... look up Surface Pro “hot bag”. The chucklefucks at Microsoft couldn’t get reliable suspend working on their own hardware for years.
* The screen locks, unlock, but the network card cannot wake up anymore and requires a reboot.
* The screen locks, let you enter things, but doesn't seem to react, then suddenly, replay all the things for 20 seconds in 1 seconds, and displays an error message
* the screen locks, but you can see the unlock screen for a few seconds when you wake the laptop up
Not being able to explain why the software does this does not negate the fact that it is doing this, and that it is a quite different possible reason for lengthy pauses in the user interface, one of several, that is nothing to do with suspending the machine; indicating that, as I said, one should not assume that these things are always suspend-related.
I wouldn't blame them if I see any of them ending up staying on Windows or moving to macOS or outright iPadOS.
I posted a thread asking for advice and did get responses, but I haven't worked up the resolve to go back and try to get it working again. Last I checked, people were just suggesting I try something else, which kind of misses the point of the activity to uses the most secure lock screen that seemed to be available.
I appreciated the help, it just seems like the whole issue should be something provided by a systemd utility that you specify your lock screen for in a config file. I know people hate on it, but systemd really does tend to make it easier if you just kind of want your system fundamentals to stay in the background and just work rather than having to constantly meddle with them.
It's a point of pride to me that I've kept my Linux system going for so long (it's outlived one Windows and two Mac laptops) but it does feel like there's often a very myopic design to a lot of applications. That is, the author often expects you to be willing to context switch out of whatever you were doing for a few hours to learn their software to use it, and doesn't feel like there's any usability problem with the state of affairs. In the case of a lock screen, this was turning into multiple days.
I can only imagine that if things were simpler, it would make it easier to involve more people, bring them on board, and/or just to get stuff done.
Anyway - enough soapboxing.
What doesn’t work well anymore is user switching: when I switch virtual consoles to either another user or the gdm screen the keyboard stops registering and the mouse gets slower and slower until it stops completely. Then some time later it starts responding again. The length of time it is unresponsive seems to be proportional to the length of time the virtual console has been suspended. The system continues to be available via SSH. I suspect that the issue has something to do with a huge backlog of invalid events being delivered, but I don’t know for sure. It may also somehow have something to do with the NVIDIA proprietary drivers. I kinda blame dbus/systemd, because it first started happening at the same time as I started using systemd, but I don’t actually know that.
It’s annoying because I’ve grown to rely on fast user switching over the past decade or more.
I don't use GDM however.
* The screen turns on when the lid is opened, the login prompt appears, but the backlight is still off so you cannot see anything (except by using a super strong flashlight).
It seems like mostly power management issues rather than the screen lock. If you removed the screen lock program entirely (remember that it is possible to run without one) this would still be a set of bug reports, eg. not suspending when you expect, not coming back from suspend..
[0] https://github.com/google/xsecurelock#known-security-issues
https://blog.martin-graesslin.com/blog/2015/01/why-screen-lo...
I would find a link and include it but jwz is hostile to links with HN as a referrer.
That's funny, because the effect there is obviously intended, because, uh, it looks cool.
> For a screen saver of the last millennium this was a suitable solution
It's true that this particular effect was much more impressive in the 90s. Personally I use the 'blank' demo in xscreenaver. Which I guess I could replace with the script in TFA without noticing much.
> Today users also expect the current time, battery state and many more information on the lock screen. We need to provide accessibility features which is not possible in XScreenSaver.
I don't see why this is not possible with Xlib. Yes I have written Xlib code. Seems to be just an "omg xlib is so old" argument, and things being old does not by itself make them incorrect.
> We need DBus integration
> and logind integration
Says who? I certainly don't need these.
But yeah, one of those things that's surprisingly tricky to get right.
One thing which I'm also analysing recently is electron shit^H^H^Happs, triggering XSS (X screen saver) idle detection on some internal app events (not user actions!).
Being: if you dont move mouse, nor touch keyboard, plus you're receiving slack messages, XSS considers youre NOT idle, in result not allowing lock to work if relying on xss-idle-detection.
needing it as I'm expermineting with some cool X11 software from 199x. I added XSS support, as original detection engine(*) dont work reliably on modern X11.
Anyone?
It seems more secure as it bypasses X, and you can be sure (can you? I just assume this, I don't really know) your input is not even being passed to X when your screen is locked. In practice I've found it very reliable.
xss-lock --transfer-sleep-lock -- i3lock --nofork
Yeah, lots of features and options in this one. Worth a look! ;)
I rewrote it in Nim some time ago to see how it works, and it was a good lesson in X11 and POSIX APIs. Short and to the point.