Results tagged “userinterfaces” from Appleseed Blog

Anyone who has used Unix more than a little has probably seen this message. I estimate I've seen it, oh, maybe as many as one hundred times in my career so far.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.

It appears when you try to use the ssh command, which opens a secure login session with a remote Unix machine, but your own computer detects that something about the target machine's identity changed between the last time you connected to it and now.

In my experience, every single time this has happened, it's because the remote machine changed its IP address for one reason or another. That's not something that normally happens often to an individual machine, but when your normal daily routine involves connecting to an ever-changing variety of computers
via ssh, it's not an entirely rare phenomenon, either. So, I end up seeing this message once a month or more.

Its all-caps, exclamation-point-studded text is clearly meant to convey alarm and urge immediate wariness, but after you've seen it a handful of times, all that stuff is completely invisible. When I see it now, I think: Oh, has this machine's IP changed? Yes, I suppose it has. OK. It's good that I think that, but it has rather little to do with the words on the screen.

More valuable is the fact that ssh will refuse to create the connection until you edit a file containing the target machine's public key. (Typically, you just blow away the old key and let ssh generate a fresh one for the target machine's new identity.) This is correct behavior, and forces the user to think about what they're doing. I just wish that its programmers (or, today, its maintainers) chose a warning message that looks less like screaming paranoia that users will start to ignore the third time they see it, and more like rational admonition requiring a prudent safeguard. Hey, something changed. As a security precaution, I'm not letting you make this connection until you edit your .ssh/known_hosts file. You should only do this if you know why the target machine changed its identity. If you're not sure about this, consult your system administrator. That's all.

As threatened earlier, my first use of this blog as a (very occasional) soapbox about the world of web application design and deployment. Particularly when it involves other peoples' work, ho ho.

A colleague from my past recently had bike accident. He got roughed up badly enough to require emergency surgery, from which he is currently mending rapidly. I stayed up to date with his fall and recovery through frequent updates that his wife's been making to a CarePages.com page, and as far as that goes, I certainly appreciate the existence of the channel.

As relieved as I am that my friend will be OK, though, I'm bitterly disappointed with some serious flaws in CarePages' design.

First of all, when invited to the site by an email telling you that your in-hospital friend or loved one has had a new page created for them, you have to submit to a full user-registration process before you can see the page at all. This is pretty bad, since to coming to the site expecting to learn news about your sick friend or family member and seeing instead a lengthy account-creation form is just tacky. But, sadly, it's such a common metaphor across various weirdly paranoid websites (including several newspapers I could name) that many users are inured to this sort of abuse. (And, yes, I did check Bugmenot to see if they had a suitable account, but no such luck.)

Far worse, however, is the site's update-notification system. Once you've registered, you start to receive email whenever the person's page gets updated. But, frustratingly, the email contains no details about the update - only a link back to the website. When you click the link, you have to log in again, because - as far as I can tell - there's no option to keep a session cookie with the website!

And here we cross the line from annoying to incompetent. When a significant percentage of your users are worried-sick friends and family who (depending upon the situation) may be holding their breath with dread every time there's news, what you don't do is announce this news with a content-free email and a link that makes them fumble around for their password when they're too stressed out to type straight.

All these mistakes have been made countless times before by other websites serving a variety of functions, and they're certainly irritating, but I shrug them off. But for CarePages, of all places, to feature them all is entirely inappropriate, to the point where I have to call it breathtakingly negligent. There's no argument that CarePages provides a very useful service - it's a popular site. But they can do a lot to improve their user experience.

So I just used plain old email to wish my friend a swift recovery. Oh, RFC 821: you are much maligned, but you're there when we just need simplicity.