It has been attempted many times to create online "assistant" programs which offer up useful information to the user at appropriate times in order to reduce the learning curve of a computer system. The most notable of these was the Microsoft Office Assistant, commonly known as Clippy, which used bayesian filters (similar to what Thunderbird uses for junk mail control) to determine what the user was doing and offer help.

JohnMoser had been toying with the idea of attempting to solve these problems as part of a secure desktop system, where the end user needs to follow a handfull of basic rules to avoid compromising the security. The theoretical system, SOMOSIS (a deformation of OSMOSIS; Simple Online Memoranda Offloading Secure Information Strategy), may be interesting to put into practice. In its theoretical design, it centers heavily around the goal of helping the user make security-concious decisions; but it does allow for other general purpose use.

The purpose of this Wiki entry is to propose a project to create the SOMOSIS system. It is a simple statement of theory; but bringing that into reality for testing may be useful.

Problems and solutions

These assistive programs typically fail horridly. Clippy was, again, a prime example, continuously displaying the same unuseful help to the user even after the user followed or dismissed the suggestion. Luke Swartz' bachelors thesis, "Why People Hate the Paperclip," detailed the failings of Clippy, citing its tendency to repetedly display the same suggestion and its lack of documentation; indeed, some users don't even know what it really does, aside from "wiggle when the computer's working."

It may be possible to learn from these failures. JohnMoser has collected the following potential reasons for failure, between his own intuition, the writings of Luke Swartz, and the suggestions of MatthewPaulThomas.

1. The assistant program continuously annoys the user; it stays onscreen too damn much and thus the user either seeks to disable it or learns to ignore it. (Swartz)

2. The assistant program is not finegrained; the user may invoke "on," "off," or "hide" (come back later), and "off" is not always available. (Moser,Swartz)

3. The assistant provides mainly useless information; it repetedly asks dumb questions about what you are doing, or offers help on simple things, like how to click things with the mouse or how to open a file. (Moser)

4. The assistant provides the same information redundantly; it looks like you're writing a letter for the 4,383,766th time, and have invoked the letter creation wizard 3,978,492 times, perhaps you would like help in learning about the letter creation wizard? See (2) and (3) (Swartz)

5. The assistant does not introduce itself; the user has no idea what the hell it's for, it's just in the way. (Swartz)

6. The assistant is not a human; the user seeks help from other humans, not intuitively from the computer. (Swartz,Thomas)

Potential solutions;

1. The assistant should be onscreen as little as possible. It should appear when relavent, and vanish when no longer relavent or when the user has clicked on it. Also, it should not reappear for the same problem.
2. Besides "on," "off," and "hide," the assistant should be given "classes" and "levels" of alerts. One class-- the only one on by default-- should be "Security," to help the user learn about encrypted e-mail, anti-phishing tools, automatic updates, and the like. These settings should be globally controlled, but also adjustable per application.
3. The "levels" and "classes" described in solution (2) should be set by default to only show security alerts and not give overly-verbose help. I don't need help typing, thank you; and most people know about spellcheck. Total n00bs can turn the level down to give beginner's tips.

4. Learning as a process. You saw this, you dismissed it, I won't show it anymore. You went through setting up a GPG key for Enigmail or already have one, I won't bother showing you that one. We discussed writing a letter, you know about the wizard, you don't need to be told again. If you want to see this stuff again, press F1 or something.

5. A very BRIEF introduction is needed (outlined below). It should note that the assistant gives security tips; but can be configured to give more information, or just be turned off.
6. Solution (5) should help, as well as the wide-spread use of a proper implementation. In truth, only time can heal this; solution (5) is just a very, VERY weak kickstart.

Brief introduction from solution (5), on theoretical SOMOSIS system (Simple Online Memoranda Offloading Secure Information Strategy), is shown below.

• Welcome to your new Linux system!

  SOMOSIS has been activated to help you with your new system. It will give you infrequent tips about protecting yourself from identity theft, viruses, and spyware. It is designed to appear as little as possible, and less frequently as you use your system.

  SOMOSIS may also be configured to act as an assistant and teach you about the general use of your system and your applications. This functionality is configurable to a large degree. Would you like to learn more about the SOMOSIS assistant?

Typical appearances

There are a few typical points when the assistant should theoretically appear. Note that the below are theoretical; they're not applied to an Ubuntu default installation.

• Upon first log-in, the Assistant blocks (delays) all messages and shows its introduction. The introduction forcibly opens (directly sent from the assistant daemon itself; applications cannot force the message to immediately display!) and can be easily dismissed. Once dismissed, the other alerts are unblocked. This is displayed immediately.

• First time automatic updates are available. This is triggered by update-manager, when updates are available. It strongly recommends the user perform the updates or activate automatic updates. Although it is triggered by updates being available, this alert is probably displayed immediately since the first updates are probably available within a month of release.

• Upon first log-in, a Password Safe is assumed to be running automatically (a suitable one such as KeePass does not exist for Linux AFAIK); we will for our purposes assume that its first run leaves it flashing an icon in the notification tray, waiting for a user click. Clicking the tray icon would inform the user of the Password Safe. This is a security message, since the user can use secure passwords and not memorize or write them down; typically any environment is bereft of good information assurance policies with regard to passwords. This message is probably not immediate since the user has to voluntarily click an icon.

• First time a security update leaves post-update information (security), triggered by update-manager when the lightbulb appears in the notification tray. Note that non-security post-update information will trigger the same message, but marked as some other class than "security." This alert is probably not immediate, as the first kernel update has to be completed first.

• First time the user begins writing an e-mail. The security message would be "encrypt your e-mail," and would offer to guide the user through generating a GPG key (as he knows the password safe, we'll suggest to generate and store a random and secure password there) and e-mail encryption and signing (tutorial to lead through sending mail to yourself). This is probably not immediate, as it happens when e-mail is first written.

• First time the user selects an e-mail to read. The security message would briefly explain verifying SPF and digital signatures, which should take all of 15 seconds and 5 sentences (thankfully). This is probably not immediate for obvious reasons.

• First time the user opens the Web browser. The security message would explain the anti-phishing toolbar (i.e. TrustBar) if installed. This is probably not immediate.

Predictably, two (2) messages are displayed at first log-in immediately: "Introduction to the Assistant" and "Automatic Updates."

Predictably, five (5) more messages will appear at various times, assuming 1) E-mail can be encrypted and signed (thunderbird/enigmail); 2) SPF is available (thunderbird extension); 3) an anti-phishing toolbar such as TrustBar is installed; 4) A password safe such as a KeePass equivalent is installed. On Ubuntu, typically most of these are not there, although Enigmail/Thunderbird will usually be installed by the user; this gives two (2) being post-update information and the Enigmail super-message/tutorial.

All in all, an Ubuntu system with an online assistant such as the theoretical SOMOSIS model assistant would likely show 3-4 messages to the user. This isn't a bad thing. With more work on the applications using it, the framework lain would still typically result in these 3-4 messages; but it would also allow the user to adjust it down so that other alerts could appear which may guide him through features not related to security, such as junk mail filters, application extensions, tab browsing, etc; or down further so that typical features such as spellcheck, bookmarks, etc were shown; or even further down into more basic use.

Design

The design of SOMOSIS needs to be strictly specified. In truth, simply throwing a library at the problem may not be the best solution; there are no facilities to control flooding or standardize the configuration interface this way. Thus, a more client-server model is considered.

Server

The "server" is a small daemon running as the user. Each user will run one and only one copy of the daemon; secondary copies will notice they are not alone and will die immediately.

This daemon connects with the clients through a two-way socket, the details of which are not yet planned. The socket must not be created on a network interface or in any other method where it actually binds to a limited global resource not already in use by the process; for example, it must not bind to 127.0.0.1:34000. Because each user may run their own daemon, the collision created binding to loopback:port would complicate the code and consume resources.

Possible alternatives to typical network bindings are either AF_UNIX sockets, assuming they do not create a port affinity; or named pipes created securely in mode 0700 subdirectories of /tmp. In the case of named pipes, the application (client) would need to create one for the daemon to communicate with it, at the very least; and spoofing of information is possible through this or any other configuration using on-disk named pipes, not that it technically matters much since only the user can spoof the information, and malware will only be able to spoof to the user it's running as.

The daemon itself will have several jobs. First and foremost, it must decide which alerts to display to the user, and execute these decisions. In other words, the daemon is actually responsible for managing and displaying the assistant. This means it must track application-level configuration and global configuration of the assistant.

When displaying alerts, the daemon must select which X display to use. This won't be difficult; the client back-end can inform the daemon of the display, or we could leave it up to other methods such as asking the system about the process' environment, especially the DISPLAY setting. If no other method can absolutely be claimed as durable, then we must rely on letting the client back-end do it; of course, this could easily be done by sending the display number upon connection.

Interface

Once the display is selected, appropriate action must be taken. Specifically, the correct toolkit needs to be utilized, and decisions on what virtual desktops to display on and where to position the display; for example, if the displaying window is under the current one, the displayed message should be between the two.

This can be handled by an interface. Utilizing a special interface library and interface API, an interface program could connect to the daemon and declare itself for that display, such that the daemon would forward actions for that display to the interface. This program would decide if GTK or Qt should be used, and talk with the window manager about where program windows are and where exactly to stick the assistant's displayed message. This separation also creates additional durability; crashing the interface won't kill the daemon, and simply restarting the interface will allow the daemon to send it all active messages, quickly putting everything back in order.

Client

The client is the application actually sending the messages, such as update-manager, thunderbird, or OpenOffice.org. The client uses a special library designed to supply the simplest useful API to the application programmer; most of the work is abstracted away. To this end, the major underlying design of the assistant is largely flexible; a lot of work can happen client-side without the application programmer having to code for it.

To this effect, a handful of symbols exists, and very few functions. Implementing these functions in a dummy library would be simple; such a library would be useful for systems without the assistant installed. A better but currently less-likely solution would be to use a tool such as relaytool from the Autopackage project to make the dependency run-time dynamic rather than compile-time dynamic; relaytool allows program flow to move around code if a library does not exist by setting up appropriate facilities using dlopen()/dlsym() and function pointers and testing if this succeeds at run-time. This type of dynamic linking would allow, for example, a program to decide if it can read PNG images at runtime by checking to see if libpng is installed (sort of like plug-ins, but not).

The client application programmer is responsible for starting the SOMOSIS client thread by calling a single function; setting up client-specific information classes; sending messages; and handling the returned information from a specific message.

The client library handles actual communication with the daemon; configuration files; passing of additional information; and logging of the actions taken for each alert. It also sends the message to kill all messages and disconnect when the application is going to terminate. The bulk of the client side code occurs in this library.

API

JohnMoser has started work on a simple API for the client side to determine what the most basic API would look like. So far, three classes of functions have arisen:

1. Initialization and termination functions. These are basically two functions. One connects to the SOMOSIS daemon and sets up a thread that handles all of the messages sent back from the daemon; this thread also handles the configuration file. The other sends kill-all-messages and ends the thread.

2. Setup functions. This is again one function. After the initialization function is run, there's one more function that allows an application to list several more classes of information that may be contained in a message. This is used for the assistant to handle

3. Message sending functions. These tell the assistant to send a message and to draw shapes attached to that message. Messages can interact with the application; shapes notify the application when clicked, and messages can contain a limited number of buttons.