The future of Internet groupware is up for grabs. No matter which way the wind blows, it’s clear that web-based applications will play a central role. But I’m not betting that web mail and conferencing will supplant the existing forms of Internet messaging, at least not anytime soon. We live and breathe email, and I don’t know anybody who prefers an HTML (or Java) mailreader to a native-GUI mailreader.
Oddly, although most people prefer today’s “fat” messaging clients to “thin” HTML alternatives, few have really begun to exploit the capabilities of their fat-client tools. Here are some of the missed opportunities:
- Secure mail
The Microsoft and Netscape mailreaders have long supported end-to-end encryption of messages using S/MIME. When was the last time you exchanged encrypted email with someone? It’s an odd thing, but people who fret about the strength of the encryption that protects their online credit-card orders think nothing of sending reams of confidential information all around the Internet in the form of cleartext SMTP messages.
Why hasn’t S/MIME taken off? Mainly because most people haven’t found it worthwhile to acquire the client certificates (digital IDs) that enable this feature, despite the fact that such certificates are inexpensive (http://www.verisign.com/) or free (http://www.thawte.com/).
- Digital signatures
The Microsoft and Netscape mailreaders have also long supported digital signatures. A recent spate of email-borne worms and viruses—first Melissa, then ExploreZip.worm—underscored the need for strong authentication of messages. These attacks weren’t more technically adept than countless others, but they were far more socially adept. Receivers of Melissa got mail that seemed to be from people they knew. Receivers of ExploreZip.worm, even more insidiously, got mail that seemed to be from people they knew in response to messages they had just sent to those people. In both cases, that mail came from a trusted person’s machine but not from a trusted person.
A point that was missed in all the debate about renewed virus-checking vigilance is that the habit of digitally signing messages could have thwarted both attacks. I do most of my business, and you probably do a lot of yours, by means of electronic communication—primarily email. In that realm, we’re usually represented by nothing more than our email addresses, which are trivial to forge. I can, for example, configure my mailer so that email I send appears to come from Bill Gates, thus defaming Gates (and Microsoft) in personal or public-forum messages.
Digital signatures, which solve this problem by binding the use of an email address to a digital ID backed by a trusted third party, have to date largely been stigmatized as geeky. We need to regard them, instead, as a mark of professionalism. If we’re doing business by way of email, you should expect me to stand behind my electronic identity, and I should want to sign my messages so you’ll take me seriously. My company, and your company, should be very concerned about either of us unleashing a worm bearing a corporate domain name.
The tools we have aren’t perfect. Hardware-assisted signing, with smartcards, is a long-overdue solution to the necessary evil of the digital-ID password. Digital-ID request and installation procedures are still not quite as smooth as they could be. But digitally signed email (and newsgroup conferencing) is workable now and has been for several years.
- IMAP
The Microsoft and Netscape mail clients both support IMAP, in principle freeing users from the limitations of POP. Most people, though, still connect to POP servers and can’t use IMAP’s server-based features. IMAP public folders, which as we saw in Chapter 13 can do everything NNTP newsgroups can do and more, likewise aren’t available to most users or well understood by those who could use them.
- HTML messaging
The Netscape and Microsoft mail/news clients include HTML message composers that can produce, in a WYSIWYG manner, HTML that expresses everything that Microsoft Word is typically used to express: outline structure, font styles, color, tables, inline images. I wish I had a nickel for every Word document I’ve received as an email attachment. Such documents, written in HTML, are a fraction of the size of their Word counterparts, and they display instantly in HTML-aware messaging clients.
HTML messaging isn’t just about fonts, tables, and images, though. What’s really at stake is the production and aggregation of intranet content. We are all prolific consumers of web-based content, and we are all prolific producers of intranet content, but the stuff we read on the Web doesn’t look or act like the stuff we write to each other. Today’s HTML message composers aren’t the final answer, but they’re an important step in the right direction.
- NNTP conferencing
By the summer of 1999, as I was completing this book, there was a groundswell of interest in online community and particularly in the uses of conferencing on public sites and intranets. There are lots of ways to do conferencing, and as I’ve said, what’s most important is that you do it, not how. It’s ironic, though, that a mature solution—NNTP conferencing—is available everywhere but used almost nowhere.
All these technologies have been widely available since the debut of 4.x browsers. But, Internet time notwithstanding, they’ve progressed little since then. It’s a chicken-and-egg problem. Hardly anybody uses the stuff, so there’s little incentive for vendors to improve it. Because the stuff isn’t improving, users aren’t attracted to it. For example, although I routinely sign my own email messages, I’ve said little about the subject of client certificates in this book. Why? It’s hard enough to get people interested in the most basic of the underutilized Internet groupware features, such as conferencing. If you also try to push public-key infrastructure at the same time, you’ll have an even harder time making headway.
I’m not sure how we break out of this vicious loop, but I think it’s naive to assume that the Web will magically take care of everything. Web users, for example, have shown no interest in acquiring the client certificates that would not only enable signed and encrypted email, but also strongly authenticate their online credit-card purchases.
What’s at stake here transcends the tug-of-war between the thin HTML and fat GUI styles of software. Much of the Internet infrastructure that was sketched out in a tremendous rush of innovation a few years ago has failed to mature as expected. I hope this book has shown where that innovation was headed and how the Internet clients that we use every day contain the germs of many groupware ideas and techniques. But where do we go from here?
On the server side, we’re in great shape. We’ve seen how the core Internet services are scriptable components that can be combined and recombined endlessly. Because these services live in the network, they can evolve frictionlessly. Playing to the lowest-common-denominator client, they deliver tremendous value and are creating more every day.
It’s the client that worries me. For all its strengths, the standard web client—that is, the HTML/JavaScript browser—falls far short of the rich features built into the (nearly) standard messaging client. Unfortunately, that messaging client isn’t a programmable component in the same sense that the browser is. Somehow, these two streams of development have to merge. Messaging is at the center of all groupware activities. We need to be able to deeply customize our messaging environments. There are two ways this can happen:
- Enrich the browser’s user interface and local data store.
There’s a reason we prefer our fat messaging clients. They’re powerful information-management tools, and we need all the power we can get, because message traffic is our lifeblood. It’s about time to extend HTML’s tired old widget set, and if that happens, messaging widgets—a multipane viewer, a tree control, a rich-text and forms-capable composer—should top the list of desirable new HTML features. Of course, these things should be scriptable by way of a standard Document Object Model (DOM).
Better UI alone won’t solve the problem, though. Browsers today are quite limited in their ability to store and manage local data. A cookie file is hardly the place to put megabytes of semistructured, searchable message data. Messaging clients use powerful—and proprietary—embedded database engines to manage local message stores. Should this machinery migrate into the browser? Perhaps so. Ideally the proprietary message stores would offer standard DOM bindings so that custom messaging applications built on top of them could be portable.
- Componentize the messaging client.
Instead of moving all the rich functionality of the messaging client into the browser, why not bring the browser’s programmability into the messaging client? There’s almost no limit to what you can achieve with the right set of scriptable components. But in the Internet realm, the messaging client is conspicuously unable to work as a scriptable component. Notes and Exchange developers routinely create custom forms and message types that provide, right in the messaging environment, the flexibility that Internet developers can only achieve in web space.
As in the browser case, this solution should provide an API that insulates scripted applications from the proprietary message store. There are all sorts of groupware services and components that need to be built. If the messaging client becomes a platform for such services and components, it needs to be an open one so that development activities have the best chance of reaching critical mass.
I’d settle for either or both of these solutions. One way or another, I hope we’ll end up with an Internet messaging platform that has the ultimate flexibility of the web programming model, plus all the features of the fat messaging clients. That’s the platform on which we can build the next generation of Internet groupware.