Brief Mentions

To round off this chapter on arguably the most popular manifestation of peer technology, I decided to briefly cover a handful of implementations that are rather different from each other and from the previous clients. The last, Windows Messenger, might even become the dominant future IM technology, overtaking the current role of ICQ-AIM as the mediums of choice. This is because of it being bundled with all Windows XP systems, and the fact that it is as yet fairly clone friendly.

These clients, including to some extent WM, have in common that they are still very much under development and are all effectively in the v0.x stage. Nevertheless, they exist as public releases and are all eminently usable in their proper context. They range from the extremely light-weight but securely encrypted Psst, to the very broadly multiprotocol and versatile Trillian client, and all address at least some observed lack or deficiency in the established IM technologies.

If these clients stand the test of time, user acceptance and, perhaps critically, continued funding and development, a later edition of this book might examine them with the same level of detail as some of the other implementations. But until then, a quick overview is the least I can do to indicate the range of options that are open to anyone wanting to use IM tools, without opting for the standard and often less-than-optimal client that “everyone knows about” and is the default route to IM connectivity. I predict that the multiprotocol IM client solution will grow in importance faster than the prospects for full interoperability during 2002, because exchanging clients is a quick user decision. Interoperability is a slow process, even when all the major providers are committed to it—which they currently aren’t.

Psst

Probably the smallest p2p IM implementation to feature strong session encryption is Psst, developed by David McNab from New Zealand. The Windows console binary weighs in at only 58kB, which seems incredible on the face of it, and the application is open source gcc-compilable under Linux.

Although still early in its development cycle, available at the time of writing were stable version 0.1.1 and test version 0.1.2 for Windows DOS, and v0.2 GUI binary versions for both Windows and Linux, plus sources (netforth.sourceforge.net/psst/download.html). Even the latter Windows GUI version is only a 152KB download, which is quite remarkable. These versions provided solid performance—despite the very rudimentary console (in DOS box) or GUI interfaces which are shown in Figure 6.11 and Figure 6.12 respectively.

Connectivity requires that the user initiating the conversation knows the Internet address of the other, whether domain or IP number, and that the other can receive incoming connections on the port used. This is true p2p instant messaging!—endpoint to endpoint, no server intermediaries, no arbitrary protocol changes by a service provider, and as secure as you’re likely to get. Totally no-frills IM.

Note that the current implementations require same-version clients on both ends to communicate properly. Download your selection and pass a copy to your counterpart, determine your respective current IP addresses, and go. Later versions might well relax this same-version constraint as the codebase becomes more stable.

Psst fills a definite need in terms of simple support for securely private p2p conversations. The integral session encryption is transparent to the user, and the application leaves no overt traces of the session in the system. If you want to log something, that’s up to you—manual copy and paste always works.

The overly paranoid Windows user can run the program from diskette or ramdisk, using command-line invocation, which ensures that later analysis won’t show any system trace of the session or the conversation. It’s of course up to the user to avoid any transcript copy or save operations that would allow potential recovery of conversation content from the hard disk. (You might note that other IM clients don’t usually encrypt messages, and they frequently log sessions on disk by default.)

Trillian

I ran across the Trillian client almost by accident at a late stage of review of this book and I liked it very much. Frankly, there’s a lot to like here. Just the fact that it includes now-working native support for all the following major IM protocols, including Internet Relay Chat in one client is a major plus. The introduction on the client home page (www.trillian.cc) says it all:

Communicate with Flexibility and Style. Trillian is everything you need for instant messaging. Connect to ICQ, AOL Instant Messenger, MSN Messenger, Yahoo! Messenger and IRC in a single, sleek and slim interface.

Yes, AIM and ICQ both actually worked in Trillian, most of the time, unlike in Jabber, the other most promising multiprotocol client discussed earlier. I attribute this to Trillian being based on a more recent (in other words, on-going) hack of the ever-shifting AIM and ICQ protocols, or to the client inherently being able to deal with the AOL servers in a better way. The client layout, which groups AIM and ICQ into the same connection manager dialog, indicates that the same AOL servers handle both. AOL is, as ever, emphatically opposed to any such interoperability.

During the technical review for the book, the Trillian client was in fact rapidly iterating through the minor version numbers in a tit-for-tat “AOL bug fix” process, evidently tracking an ongoing skirmish between Trillian and AOL programmers revising protocol and client’s detailed behavior, respectively.

Trillian is freeware (“for free noncommercial use, forever”)—currently a 2.2MB download in its Windows-only, most recent v0.72x incarnation. Behind Trillian, the client, is Cerulean Studios, the company (www.CeruleanStudios.com, although both domains go to the same Web site at present). Founded in May of 1998 by Kevin Kurtz and Scott Werndorfer, the company’s only visible showing is Trillian.

And it’s worth looking at. The client interface is shown in Figure 6.13, as it appears in its default skin and size. The capture shows two concurrent sessions over different mediums, here ICQ and MSN, to another user who needs multiple clients installed, the original for each service. Both the main status interface (with contacts list) and the session windows are resizable in a multitude of ways. (I blocked out contact names and any e-mail addresses in the sessions in the interest of privacy.)

Note the discrete row of icons on the bottom panel of the contacts list; each brings up a context menu relevant to the medium it represents—from left AIM, ICQ, IRC, MSN, and Yahoo. The online status for in the contact list is in the form of corresponding icons beside the name, visible on mouse-over or when online. Session windows show the same icon and current status on the top tab. The “is typing a message” presence information is more useful than one thinks.

(Personal reflection and aside) Have you noticed how many mainstream applications are “skinnable” these days? No longer just a matter of color themes, many applications (especially media players) have support for skins that sport a quasi-redesign of the user interface. Sometimes, this is good, but I often despair at limited selections of ready-to-use skins in spikey, odd-ball, psychedelic, and visually/usability-unfriendly themes. Rolling your own skin may be easy or hard, but takes more time than most are willing to spend.

P2PQ

Messaging doesn’t have to be strict one-on-one, or even especially personal. What happens if you cross a search engine with a messaging client and remove the engine? Well, you might get a distributed user-driven knowledge-base, much like P2PQ.

P2PQ is a free service (www.p2pq.net) that works by recruiting people who volunteer to share their knowledge and provide their answer potential to others. It’s a dynamic directory of live people, available to users from anywhere and any device. It promotes the concept distributed aggregation with the registered slogan “Put your mind online!” and a Web site with a form to enter an arbitrary question.

The small clients are installed and sit idle on the machines of the users until someone needs to “pick their brains” at the P2PQ Web site. A typed-in question (and a timeout for the query) is farmed out to distributed clients, where it’s assumed that somebody will know the answer. Any client user can type and return a response to a received question. The collected results are displayed in a list of results, just like the results from a standard search engine query.

This solution is a kind of human-powered version of distributed processing, inspired it’s said by the ancient story of Kadikai. It’s not strictly p2p in the sense that this book uses the term, but it’s still interesting in its possible implications for distributed social networks. The central server in this case sorts and sends queries to appropriate categories of client users who act as relevancy (and spam) filters. Approved queries are then passed on to the larger client community for a category.

Anyway, this service is clearly still in the early testing stage (there was only one category when I tried a query), and human responses require measurable time to compile. The advantage of a functional “peer” system of this kind rests on the adaptive nature of human response and the ability to correctly parse requests expressed in everyday language. It also encourages the “value” rated answers—useful personal qualifiers like “I think”, “last I recall”, “I recommend”, “based on 10 years of experience with”, and so on. Implicit is a trust that the people answering are sincere about their volunteer work. Worth keeping an eye on.

Windows Messenger

Finally, an overview of Windows Messenger, what could quickly become a dominant IM player, if only by virtue of it being the IM technology bundled with Microsoft Windows XP and integrated into .NET. Some deeper detail is included because of this, but the focus remains on the broader issues.

WM effectively supplants the various IM and p2p technologies introduced in earlier versions of Windows. The new IM is further incompatible with earlier protocols such as MSN and NetMeeting H.323. Made specific to Windows XP, the client however can also be retrofit into some earlier versions of Windows, albeit then lacking a few features that only work with XP.

As far as can be determined at present, the MSN messaging network doesn’t try to block compliant third-party client software—my experience with Trillian has shown no glitches—so we can expect to see numerous clones appear, especially for non-Windows platforms, as WM gains popularity. Trillian, described earlier, is one recent multiprotocol client under development that easily supports communicating with users who use the original WM client.

This kind of open interoperability should be the rule everywhere. The main requirement on any clone for full functionality with WM is that it can deal with the Passport authentication process when contacting the MSN servers.

Highly optimized for what it does, WM offers basic IM, telephony over Internet, video, file sharing, and a potentially long list of Microsoft and third-party extensions. I would expect WM, as a highly visible desktop client, to rapidly “infiltrate” the user experience in Windows at least as much as the Internet Explorer and Outlook combination (with their interrelated, hidden, GUI-extension components).

Although the new user wishing to get a registered WM identity is taken to a Microsoft Web registration site and given the default suggestion to sign up for a MSN or Hotmail e-mail account, another click allows the prospective user to register with Passport under any permanent e-mail address. The e-mail identity entered is the one that WM uses as its unique user identifier, but the user can freely choose any handle to be the default name shown in the contact lists of other users.

The application actually looks oddly similar to the AIM client at the default WM window—you can add a contact, send an instant message, or place a call (that is, establish a voice conversation). The same window also displays presence information about your contacts (that is to say, your roster). This all looks exceedingly simplistic at first, but the client hides most of the functionality controls from view until the context is relevant. You may or may not like this automation, but it is configurable.

Going to an IM window, for example, adds buttons to start video, send a file, invite others to start application sharing, start remote assistance, or start a whiteboard session, just to name a few—see Figure 6.14. The client can also be your gateway to multiplayer games. Except for IM sessions, which can optionally be one-to-many (multicast), all other WM features are implemented as one-to-one (unicast) only per session window.

The MSN panel shown at the bottom of the interface window is actually a fortuitous capture, because it normally shows (localized and profiled) animated banner advertising. This advertising is only slightly less annoying than that in the ICQ client which shows separate banners in each and every session window.

Voice quality is described as being as good as a clean phone connection. The fidelity is achieved using an impressive array of specialized codecs, dynamic jitter buffers, forward error correction for the streaming data, and acoustic echo cancellation. Video rates are up to 12 frames per second, depending on your available bandwidth—that’s webcam-jerky but usable and surprisingly sharp from good sources.

Screen updates for application sharing are fast, and control of the application can be passed interactively between the users. Microsoft or in-house tech support can take complete control of a user’s desktop using the Remote Assistance feature, walking users through difficult operations. This built-in remote control feature is a two-edged sword, of course, and not to everyone’s liking. Time will also tell if the feature gets hacked and exploited for unauthorized purposes.

Usability Issues

Microsoft likes to embed various “convenience” features in its products, and WM functionality is no exception—in part this is coded into WM, in part it hinges on features inherent in the common Windows components used, and in part it is the entire design philosophy expressed in Microsoft-on-the-Internet and the Web components. The inconvenient aspect of automated convenience features is when their functionality doesn’t match the needs or expectations of the user.

Let’s take the matter of locale. Microsoft made Windows configurable for a wide variety of languages, keyboard layouts, international fonts, time zones, and location-specific settings. Localization is all good and well, and a welcome evolution from the extremely U.S.-centric applications we had before the 1990s. However, when extended (for example, to automatic redirects and update selections), things can get confusing, frustrating, and downright messy for the user who doesn’t fit the form— especially when it’s unclear what the automation is based on (keyboard layout, locale setting, system language version, originating IP-number block, and so on).

Consider this hypothetical scenario:

Susan is a user from the U.S. who is for a time working in Sweden. For practical reasons, she finds it convenient to set the laptop locale to correspond, and to sometimes also use a separate local-layout keyboard. One day, she needs to find the messaging identity of a co-worker in the U.S. Going to user search i MSN, she gets the response that there is no user by that name. She is even more mystified when a search of her own identity fails!

Being bilingual, our example user didn’t especially react to the fact that the MSN search site was serving localized pages (in Swedish). Many sites can today serve content in different languages—that is after all the purpose of the preferred languages setting in Web browsers. The MSN server, having queried the computer’s locale setting, had transparently redirected the request to the country’s local MSN site. The redirection would have been unnoticed and perfectly OK for the majority of users in that locale, but it trips up any user who doesn’t fit all the assumptions.

To successfully find a registered MSN user, it would appear that you must search at the correct localized site where that user registered. In our example, the redirected site was msn.se, but both user and coworker were registered in msn.com site’s database (international domain, but for users in the U.S.). For success, the ex-pat user must therefore either set locale appropriately or force connection and search to the U.S. site. This kind of hidden redirect can be even harder to detect when the language remains (more or less) the same while locale varies—for instance, English but U.S., Canada, U.K, or Australia. Try the default Web search feature in IE or Outlook with different locale settings and marvel at the wide range of page layout and functionality interfaces, not to mention different search rankings.

WM Protocol

The basic protocol underlying WM is Session Initiation Protocol (SIP), which is an open IETF standard (specified in RFC 2543). The choice indicates at least the potential for general interoperability with other technologies that support SIP on any platform. For example, a third-party SIP-to-PSTN gateway server would let you place a WM voice call to anyone who has a landline or cellular phone.

SIP is a generic application-layer control (or signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions can include Internet multimedia conferences, Internet telephone calls, and multimedia distribution. Session communications can be multicast, unicast, or a combination—all depending on how the implementation supports these features. SIP transparently supports name-mapping and redirection services, a functionality that was seen as essential to the kind of user mobility that is rapidly becoming the norm.

The session management functionality in SIP includes support for

• Determining user location, which refers to the end system to be used for the communication

• Determining user capabilities, which selects the media and media parameters to be used

• Determining user availability, which also includes the willingness of the called party to engage in communications

• Managing call setup, which establishes call parameters at both ends of the connection, also known as “ringing”

• Managing call handling, which includes call transfer and termination

The similarities here with call management in ordinary telephony are no coincidence. These basic properties naturally tie in with the three basic Passport dimensions of user identity (that is, person, location and application).

SIP can also be used together with other call setup and signaling protocols. In that mode, an end system uses SIP exchanges with a protocol-independent address to determine the appropriate end system address and protocol. SIP can also be used to convey session-specific information to other protocols or application managers for specialized functionality that SIP itself doesn’t support.

Plug and Wait

As yet, however, SIP is still a new protocol, and the applications that support it are relatively untested. Not that many products use SIP, and consequently, not many people are asking vendors about SIP support for their favorite products. It would seem, therefore, that increased SIP support will mainly come from vendors deciding to interoperate with Windows XP and WM.

More serious is probably the firewall situation. Current small office and home office (SOHO) gateways simply can’t deal with the combination of secure NAT and how SIP uses dynamic port allocation. Anyone wondering what this issue is all about would do well to read up on similar concerns raised by the older H.323 protocol used by NetMeeting. One such source is the primer from the SANS Institute, which is found at www.sans.org/infosecFAQ/homeoffice/concerns.htm.

This document discusses the basic problems of trying to run a secure system behind routers, firewalls and proxies, in the context of applications that require many open communication ports to the outside world. Certainly it can be done, but the user (or administrator) must be aware of what the security trade-off is, especially with applications that don’t require or enforce any kind of authentication mechanism.

Typical gateway and firewall vendors haven’t yet come to grips with the new WM requirements, so plenty of user scenarios simply won’t play. In general, all users who wish to use the real-time communication features supported by Windows XP are faced with this constraint for the simple reason that the new features all rely on SIP.

For example, it’s highly unlikely that your average SOHO (Small Office Home Office) computer user behind a NAT-firewall/gateway will be able to WM-connect to a colleague behind the corporate firewall—even without any formal access restrictions on either firewall. It’s been tried and it didn’t work then, and probably won’t until firewall software is patched or upgraded (as happened for H.323 support) or site-specific workaround is installed.

In that vein, the Universal Plug and Play (UPnP) Forum is working to establish PnP support between Windows XP and resident gateway products. XP and WM already support UPnP—or rather some subset/interpretation thereof. Future gateways will automatically configure themselves to support WM, or seen another way, the WM clients will reconfigure the firewall products on demand. The hairy security issues this raises are briefly noted in Chapter 4.

However, as recently as January 2002, only Ingate (www.ingate.com) had released what it claims to be the first SIP-compatible enterprise firewall product, thus providing the needed transparency to application functionality that relies on SIP: presence, instant messaging, internet telephony, and real-time video and audio conferencing, at least as it is implemented in the XP/WM model.

Still, the bottom line is that WM will be fully supported, eventually, as long as Microsoft is committed to their current vision of .NET and Windows XP—with a bundled, standard IM-and-more client with authentication features. Clearly, this is the path of least resistance for the corporate environment, with a firm commitment to a uniform application environment. Considering the poor security and authentication offered by the otherwise most popular IM implementations, that might not be such a bad thing in the corporate context.

There are, however, other interesting peer-based technologies to explore, especially if we look beyond simple IM and wish to eschew central servers.