This article is a much-expanded revisit to an article, no longer available, originally posted to a security research blog.

The Wikipedia entry for ‘error message’ [1] includes a number of infamously confusing error messages, though it doesn’t include my all-time favourite:

Keyboard not found! Press any key to continue

Or:

Keyboard not found! Press F1 to continue

That may read like an urban legend. However, I did see more or less that same error message several times, back in the Jurassic, when supporting IT users was part of my job. And, of course, it’s not quite as dumb as it sounds. If there’s a keyboard problem, it makes sense to check that an external keyboard is plugged in properly, or that using a different keyboard fixes the issue, and while the system might recognize that the problem has been corrected (hopefully) by itself, it might be necessary to send a wake-up call to the system by pressing a key.

There is an old joke (especially common among IT support staff, who often feel somewhat badly treated by the people they’re paid to help (yes, it happens!), and get some sort of revenge by exchanging stories about IT users who don’t understand technology very well. Not all those stories are apocryphal, but I’m not here to poke fun at corporate computer users who are the victims of inadequate training policies or documentation, so I won’t turn this article into a list of such stories. (If that’s what you want, I’m sure your favoured search engine will find you hundreds or more.) However, the joke I have in mind (which may or may not be apocryphal) concerns an IT user who rings the helpdesk because his keyboard doesn’t have an Any key. (It’s probably funnier told in the pub after a hard day manning – sorry, personning – the service desk.)

Perhaps that joke and its variants are the reason that Microsoft and/or (other) PC manufacturers appear to prefer to specify the F1 key. Most keyboards have numbered function keys, though marked function keys often have picture symbols too, to indicate other tasks they may perform, such as moving the cursor or adjusting loudspeaker volume. However, F1 has for decades been the key conventionally used for calling up a help menu, especially in environments based on IBM’s Common User Access (CUA) [2] guidelines. Though this too has been the subject of support staff jokes, such as the one concerning the person calling the helpdesk to complain that “I’ve been pressing F1 for an hour, and no one from the IT unit has turned up yet to help me.”

In any case those guidelines have never been universally adopted, even on systems descended from IBM’s original PCs. IT support first became a significant part of my own job description in 1987 or thereabouts, around the same time the CUA was published, but the F1=Help convention was already reasonably well established. However, I have fond memories of being contacted by another department in the hospital I was then working at, asking for my help with a problem with WordPerfect, which at that point I’d never used. (Though I was very well acquainted with WordStar: in fact, when I wrote my own little multi-window text editor, now long forgotten even by me, it used WordStar commands!). Fortunately, one of the things I did know about Wordperfect was that the Help key was F3, not F1, so I had a starting point for fixing the problem…

Anyway, back to keyboards and error messages.

I first checked that Wikipedia page on error messages back in 2013, when I was scouring the web for links related to ‘error messages’ and  ‘security alerts’. That was because I’d recently encountered an article by Tori DeAngelis on the American Psychological Association web site [3] that told me that psychologist Gary Brase and security researcher Eugene Vasserman, of Kansas State University, had been given a $150,000 grant by the National Science Foundation for research into developing better online alerts. I imagine that many security companies have explored this approach to developing a product and its user interface, involving psychologists, focus groups, and ergonomists, amongst others with interest and expertise in aspects of human-computer interaction (HCI).

StIll, I’d seen more than enough in the way of confusing software-generated alerts to agree that security software could do with a little more attention to the HCI dimension. There is still a special place in my heart for the sort of alert that we often saw [4] along the lines of ‘EICAR test virus not-a-virus detected’.

Strangely enough, the day after I revisited this paragraph, I came across a paper [5] that cites that paper [4] by myself, Lysa Myers and Eddy Willems on the use and misuse of malware simulation, though I’m not convinced that the authors of the new paper had totally understood or even read it.

Perhaps because my own academic background was originally in social sciences (computer science being a later add-on), I don’t believe that computer security should be focused entirely on bits and bytes, even if researchers are more comfortable with a rigidly digital approach. The bits and bytes approach clearly hasn’t solved the world’s problems with cybercrime, cyber-espionage, and all the other cyber-issues du jour. Nor is the kind of security alert that leaves the software user wondering “What does that mean? What does it want me to do?” capable of passing a meaningful usability test.

The APA article includes a couple of examples cited by Brase:

“Do you want to trust this signed applet?” or “This application’s digital signature has an error; do you want to run the application?”

The truth is, though, that there are even more confusing examples guaranteed to drive the end user to the nearest wall with the intention of banging his head against it. For example, any message that displays one of the following:

• an unexplained error code (or worse, a hex string) with no indication of where to find even the most indecipherable definition
• a text string like ‘unknown error scanning file [filename]’
• a blank message box.
• almost any message that gives you a mystifying warning and asks whether you want to continue…

The problem with Brase’s examples isn’t so much the actual wording, it’s conceptual. Nowadays, the word ‘algorithm’ is misinterpreted as a sort of synonym for everything disquieting about Artificial Intelligence, but of course all programming is, arguably, algorithmic (in the sense of a set of ordered instructions to be followed in the hope of achieving a goal). Algorithms that try to mimic intelligence are a special case. If the algorithm behind a security program isn’t able to make a reliable determination of the risk, why should we expect the everyday user to be able to? To be fair, he or she might make a logical or informed guess, knowing that a site is (normally) safe, even if they can’t be sure that it hasn’t been compromised in some way. If it lacks the difficult-to-replicate human qualities of intuition based on environmental and experiential factors, security software has the disadvantage that it can only deduce malicious intent from analysis of the programmatic characteristics of a program, or from automated textual analysis.

At this point, I’m giving in to the temptation to take a detour via the late Dr Alan Solomon’s PERFECT.BAT, a sort of thought experiment based on the futile search for the perfect antivirus program. Having just discovered a presentation on that very issue that I never actually delivered, I think that will probably be the basis of the next in this series of articles in danger of disappearing without trace, so I’ll restrict myself to a minimal description here rather than provide my own definitions of the Halting Problem, for instance.

Long ago, in the forum alt.comp.virus [6], Kevin Marcus made a point about the ‘mathematically impossible’ claims of certain security vendors about detecting ‘all viruses, known and unknown’. ‘Mathematically impossible’ presumably refers to assertions by Dr. Fred Cohen [7] that there is no general algorithm that will detect all viruses, closely related to Alan Turing’s assertion that there is no general algorithm that will solve the Halting Problem [8] for all possible program-input pairs. Never one to miss the opportunity to take a contrarian position, Alan adapted Cohen’s assertion to make a point about antivirus industry marketing using three batch files. [9]

• The first (P1.BAT) took a filename as a parameter: it didn’t actually examine the filename or even check that it existed, but simply returned the text string “[filename] is infected by a virus!!!”. In principle, this batch file would detect all virus-infected files ‘past, present and future’, but has a ludicrously high volume of false alarms.
• The second (P2.BAT) also took a filename as a parameter, again without performing any form of checking, but returned the text string “[filename] is NOT infected by a virus!!!” Thus fixing the false alarm problem, but not actually detecting any infections.
• The third [PERFECT.BAT] took a different route: it displayed a string “Is %1 a virus? (Y/N)”. It actually takes a little more programming than Alan showed to get the ‘appropriate’ string to be displayed when the end-user presses ‘Y’ or ‘N’, but the point is that the program only gets the correct result if the user already knows the right answer.

Alan’s conclusions, which are hard to argue with even if you’re not sure about his illustration, were:

1. If something is superb at detecting viruses, it’s no use if it gives a lot of false alarms.
2. Anything that relies on the user to make a correct decision, on matters that he is not likely to be able to decide about, is useless.
3. You can receive something that is *exactly* what the salesman promised to deliver, and it’s nevertheless useless.

We’ll revisit point 2 shortly, as that’s the main point of this article.

Reverting to the point about textual analysis: text filtering has progressed immeasurably from the days when oversimplistic string recognition meant that phrases like ‘magna cum laude’, or the name Scunthorpe, triggered porn detection algorithms all over the globe. Still, contexts remain where a reasonably well-informed human being might make a better decision than an email or web filter. But ‘informed’ people weren’t the main target for research in this case. Brase stated, entirely reasonably, that “Good security alerts should be tailored for all types of users, no matter what their intent.” This assertion not only suggests a wide range of skill/knowledge levels, but also a wide range of target sites, institutions, and communities.

In IT security, the importance of being in touch with the intent of the user as well as that of the malefactor is often underestimated. Jeff Debrosse and I suggested in a 2009 paper that security software could be made more effective by incorporating analysis of the user’s behaviour as well as analysis of programmatic behaviour – Malice Through the Looking Glass: Behaviour Analysis for the Next Decade. [10] I’m not aware that this approach has had much direct impact in the security arena (if any), yet it is one way of addressing another of Brase’s points: that is, that ‘user education has not kept pace with the increasing complexity of Internet transactions.’ That, at least, is true, both in the workplace and for home users. I’m all for making computers people-literate (the very apposite title of a book by Elaine Weiss, probably long out of print). [11]

However, improving the presentation and wording of security alerts won’t make security software (or other software with some security functionality – for instance, a browser using detection technology like Google’s Safe Browsing [12] to flag malicious sites) any more capable of discriminating between aspects or examples of human motivation than it already is. That’s not such a negative comment as it sounds: programmatic filters don’t in themselves ‘detect’ malicious intent, but they do reflect the programmer’s understanding of some behaviour – programmatic or semantic – characteristic of malicious intent. But malicious behaviour is not a constant, not static. The average security program may yet be a long way from achieving the same discrimination in analysing textual content that a moderately psychologically-aware human being is capable of.

Though no doubt there are ‘nextgen’ programs claiming that their AI has already achieved and surpassed that ability to discriminate…

[1] https://en.wikipedia.org/wiki/Error_message

[2] https://en.wikipedia.org/wiki/IBM_Common_User_Access

[3] https://www.apa.org/monitor/2013/06/security – “Making online security warning messages more useful and effective”

[4] http://www.welivesecurity.com/media_files/white-papers/AVAR-EICAR-2010.pdf or https://geekpeninsula.wordpress.com/wp-content/uploads/2013/11/avar-eicar-2010.pdf by David Harley, Lysa Myers and Eddy Willems.

See also the related AMTSO document https://www.amtso.org/wp-content/uploads/2018/05/AMTSO-Use-and-Misuse-of-Test-Files-in-Anti-Malware-Testing-FINAL.pdf

[5] https://arxiv.org/pdf/2501.05542 – “Infecting Generative AI with Viruses” by David A. Noeverm, Forrest McKee.

[6] I stopped participating in the alt.comp.virus newsgroup around 2001, when it became effectively unusable due to a flood of malware, and access to Usenet newsgroups in general has mostly been restricted to viewing archived material rather than posting new material, because of the amount of undesirable material that overwhelmed it. Google Groups is one of the front ends that no longer allow new posts to the newsgroups it controls.

In the 90s, though, alt.comp.virus was an invaluable resource for me early in my career in security as a venue where mainstream security researchers, end users seeking help, and quite a few virus writers (not all of whom were totally evil) were able to establish lines of communication. The FAQs put together by myself and many others can still be found at https://www.faqs.org, though they’re obviously very outdated. Unfortunately, I no longer have editing/maintenance privileges for any of those FAQs (Frequently Asked Questions), having passed those privileges to George Wenzel. The main four-part FAQ is still accessible at http://www.faqs.org/faqs/computer-virus/alt-faq/ though. Perhaps I’ll take a closer look at it someday.

More about Usenet: https://en.wikipedia.org/wiki/Usenet

[7] https://en.wikipedia.org/wiki/Fred_Cohen – the Wikipedia page doesn’t mention it, but his book A Short Course on Computer Viruses gives a fairly full account of his early work in the field.

[8] https://en.wikipedia.org/wiki/Halting_problem

[9] https://groups.google.com/d/msg/alt.comp.virus/xwaFmyWZNrI/uARw82u91dMJ

[10] https://geekpeninsula.wordpress.com/wp-content/uploads/2013/04/harley-debrosse-vb2009.pdf

[11] https://www.amazon.co.uk/Making-Computers-People-literate-Environment-Performance/dp/1555426220

[12] https://safebrowsing.google.com/

David Harley

*** This is a Security Bloggers Network syndicated blog from Check Chain Mail and Hoaxes authored by David Harley. Read the original post at: https://chainmailcheck.wordpress.com/2025/01/28/keyboards-lost-and-found/