4 ms·
> That's not the end of the world, honestly. But it is a learned gesture that the system taught me by failing to do what I'd asked it to do. Although I agree t
by d1sxeyes 5y ago
> That's not the end of the world, honestly. But it is a learned gesture that the system taught me by failing to do what I'd asked it to do.
Although I agree this is annoying, to be completely fair, it doesn't suggest that you should start typing your password immediately.
You could also start typing 'news.ycombinator.com' and it wouldn't browse to HN, but you wouldn't say that it failed to do what you asked it to.
Arguably, you have been 'taught' or you have inferred yourself that you should expect a sleeping system to immediately accept your keypresses as a password, which although reasonable is not necessarily a good practice.
For example - I have two computers connected to the same keyboard, one is indeed Gnome, the other Windows. I have twice now typed my password into what I thought was my sleeping Gnome system, hit enter, only to have to apologise to someone on Teams because I accidentally sent them my password because my keyboard was sending my keypresses to the Windows PC.
- OrderlyTiamat 5y agoI... am sorry, but I think that is extremely bad practice. You should not put yourself in that position, and your experience in that position does not excuse the design flaws in windows. > You could also start typing 'news.ycombinator.com' and it wouldn't browse to HN, but you wouldn't say that it failed to do what you asked it to. Well firstly, that isn't what the prompt is for, so I'm struggling to see the relevance. However it is a good example for me- When I type C-l right now, I can _immediately_ start typing 'news.ycombinator.com'. There is no delay, no animation, nothing. I didn't go through a learning experience of finding out how long I should wait before typing- it's just ready. Fundamentally: _why_ should I have been "taught" anything about how long I should wait? I don't have to do that on my ubuntu laptop. I don't have to do that on firefox in the example you handed to me. It's bad when I have to learn that. The computer should never make me wait unnecessarily, and I find it worrying that people are so readily accepting of it.
- d1sxeyes 5y ago> I... am sorry, but I think that is extremely bad practice. Completely correct - I'm not excusing my lack of attention there. > Well firstly, that isn't what the prompt is for That's exactly my point. There is no prompt displayed on the screen, you have not been asked for input. You are pre-empting the next prompt before the system is ready for it. > When I type C-l right now, I can _immediately_ start typing 'news.ycombinator.com'. There is no delay, no animation, nothing. I didn't go through a learning experience of finding out how long I should wait before typing- it's just ready. Agreed - but that's with the application already open. From the lock screen, it won't do what you intend. With Firefox running and in focus, Ctrl + L tells the application to focus the address bar, but it only works in that context, you first have to prepare the correct context (computer unlocked, Firefox running, in the foreground and focused). On Windows, Ctrl + Alt + Del tells the system to wake, not 'the next characters entered will necessarily be the password of the most recently logged in user'. In fact, I tested a little bit, and often Ctrl + Alt + Del on a sleeping system actually asks me to enter a username first, not a password, although in some cases the username is pre-filled for me, and the password prompt will be focused. I cannot necessarily know a priori which I will be asked for until the system wakes and decides. As soon as Windows displays the prompt, you can type into it (same as Gnome). The only difference is that Windows requires you to first wake and then authenticate once the system is woken, while Gnome allows you to do both simultaneously. There is one particular 'pro' to the Windows approach of requiring Ctrl+Alt+Del which is that it's an interrupt sequence. If a malicious actor created a full screen application that mimics the Windows password prompt, it would not be effective because the Ctrl+Alt+Del sequence cannot be handled by an application. The same is not true for Gnome - if a malicious actor created a full screen application that mimics the login prompt on Gnome, you could be tricked into entering your password.
- tsimionescu 5y agoGP's (I think reasonable) point was that typing A on the keyboard of a locked (or worse, sleeping) computer has no reason to be interpreted as "input the letter A into the password field that will be displayed on screen", which is what the original post is assuming it should mean. There's no real reason it should even mean "input the letter A into the first field that comes into focus", which may anyway not be the password (it could be the Username field in certain setups).
- kaba0 5y agoWell, you usually see the logged in user’s name and icon on the screen, and presumably you left your own computer there. And frankly, UX is about finding the little practices that make the experience better — arbitrarily waiting for windows to bring up a prompt is not making me any good, since I know what I want to do. So in my opinion in this very special case, windows is simply doing an incorrect thing — making the common case slow.
- d1sxeyes 5y ago> Well, you usually see the logged in user’s name and icon on the screen I don't have this experience. On Windows (10, at least), normally I see either a black screen (if it's asleep) or a wallpaper, clock, and a message saying 'Press Ctrl + Alt + Delete to unlock.' > arbitrarily waiting for windows to bring up a prompt I don't think it's arbitrary. It's doing something - it's calling Winlogon, spinning up disks and reading hibernation data into memory, restarting power to powered down components, probing authentication methods available (eg: fingerprint/card readers), in case of domain joined computers, validating whether the domain is available (which means firing up network interfaces), and if so, whether the user's password has changed, etc. There are definitely downsides to Microsoft's approach here - as you mention, in a large number of cases, it takes more time to unlock the computer. However, there are also upsides if you accept that UX is only one consideration when designing a secure log on prompt, and there may be other priorities.
- klibertp 5y ago> Arguably, you have been 'taught' or you have inferred yourself that you should expect a sleeping system to immediately accept your keypresses as a password, which although reasonable is not necessarily a good practice. I fail to see why that wouldn't be a "good practice". Last weekend I read some articles on Canon Cat[1], and Jef Raskin referred[2] to the feature as something desirable: > In many ways it was, for 1987, far ahead. [...] instant on with any keystroke (and you didn't even lose the keystroke) He goes on to explain why it's a good idea to do so in the article, it's a good read. [1] https://en.wikipedia.org/wiki/Canon_Cat https://en.wikipedia.org/wiki/Canon_Cat [2] https://www.apple-history.com/gui_raskin2 https://www.apple-history.com/gui_raskin2
- d1sxeyes 5y agoThanks for sharing. I can definitely see why it might be appealing. However, using Ctrl + Alt + Del guarantees that only Winlogon can handle the logon, no other process can be simulating the login prompt. My dad told me about a program he wrote for a PDP-11 which would just simulate a login prompt. When a username and password were entered, it would append it to a file somewhere, then print the 'Incorrect username or password' message, and exit silently. The user would assume they'd fat-fingered the password, and try to log in again (successfully) and be none the wiser that their password had just been stolen. The Windows dependency on Ctrl+Alt+Del makes this type of attack impossible, while systems that don't require a Secure Attention Sequence (as apparently it is called) to log in are susceptible to a slightly more sophisticated version of this attack.
- klibertp 5y agoI see. It makes sense, and it's a valid concern that I didn't think of. Personally, I prefer the convenience of continuing where I left off with as little friction as possible, so I don't even lock the session when the screensaver kicks in. But I never take my laptop outside, and the threat of malware is considerably lower under Linux. If that wasn't true, I would probably also want to err on the side of caution. Choosing a specific key (I have a very conveniently positioned X86WakeUp physical button) or combination for waking up and getting to login prompt seems like a good idea in that case.