by Jon Udell
Ray Ozzie, creator of Lotus Notes, founded Groove Networks in 1997 to take groupware in a new direction. His new product, Groove, enables groups of collaborators to form in a decentralized, ad-hoc, administrator-less fashion, within or across corporate or other firewall/NAT-governed realms. Groove is a peer-empowering form of groupware -- what the company likes to call "peerware." In Groove, group members interact in highly-secure shared spaces. These spaces collect all the documents, messages, and applications ("tools") related to a group activity. Everything replicates to each member's computer -- possibly, to several devices per member -- and is available for online or offline use. Exchange of data is very granular, so that Groove-aware applications can support activities like shared editing in real time.
Jon Udell, author of Practical Internet Groupware, has been using Groove for several months, and says "it's what I've been waiting for."
Jon Udell: Like many of the products in the peer-to-peer space, Groove is really a hybrid of centralized and decentralized strategies. What does Groove centralize, and why? Conversely, what does Groove decentralize, and why?
Ray Ozzie: Groove can operate in a purely decentralized manner, but generally that mode of use will only be typical in home network or small office network environments where there's a single LAN segment and peers can be discovered through an efficient broadcast mechanism. More typically, Groove makes use of a variety of centralized services in a pragmatic fashion in order to make the communications experience feel more transparent to the user:
PRESENCE - When a computer running Groove connects to the Internet, it registers with a "presence server". Other computers interested in communicating with that device may have "subscribed" with that same server to be notified when that device comes online. This "publish-and-subscribe" awareness mechanism is a highly-efficient (e.g. generally non-polling) means by which computers can find out not only when a computer comes online, but also its IP addresses and whether or not it's behind a firewall or NAT.
RELAY - When attempting to communicate with a peer, it may be discovered that that particular peer is off-line. In this case, communications destined for the remote peer are instead routed to a "relay server" designated for this purpose. When the offline user reconnects, Groove retrieves communications from the relay server as it is also taking inbound peer connections. Also, if the users are operating from behind barriers, such as firewalls or NATs, relay servers can be useful as intermediaries to efficiently "switch" communications between them.
FANOUT - When one computer has the need to send the same information to multiple peers, it is sometimes more efficient to have a different computer doing retransmission to those peers. For example, if you are connected to the Internet over a 9600-bps GSM modem link, and you are trying to send the same information to five coworkers, it is more efficient to send one copy to a server that redistributes the content to the five others.
MAIL - When inviting other peers into shared spaces and activities, a common mechanism for distributing invitations is through standard SMTP-based e-mail.
DNS - When connecting to servers, e.g. presence, relay, or mail, Groove uses DNS lookup services in order to translate from server names to IP addresses.
Jon: You've said that human error is the Achilles heel of computer and network security. Can you elaborate on the strategies Groove uses to make strong security a mode that's always-on, yet fail-safe?
Ray: Based upon my past experience, vulnerabilities present in the systems management process dwarf technical vulnerabilities, from a practical sense. Two specific examples:
In systems based upon a PKI, the control of higher-level certificates represents a single point of vulnerability. Unless multiple-person password schemes are used to control the certificates, a rogue or disgruntled employee might create and certify identities, thus weakening trust in the certification authority.
In systems that route or authorize information based upon a directory (without cryptographic protections on that directory), rogue or careless employees can cause information to be routed to the wrong destination, can cause the wrong keys to be distributed, can cause access controls to be overridden, and so on.
The simplest way to minimize vulnerabilities is to minimize human interaction by removing the "knobs." For example, in Groove, you never have to worry about your information going over the wire unencrypted because there is no option to turn it off. You never have to worry about your information being disclosed when you lose your laptop because everything is encrypted to the disk, and there's no option to turn it off. You never have to worry about a rogue central directory administrator or certifier because there are none.
Groove, like products such as PGP, uses a peer-based person-to-person trust model, as opposed to a hierarchical certification model. This works because the product's design center is to support small group interactions, generally with people that we recognize.
Jon: If the objective is secure, yet spontaneous, collaboration that can work within and across corporate borders, Groove beats e-mail hands down -- assuming everybody you need to communicate with runs Groove. The aim, of course, is to make Groove ubiquitous. But for the foreseeable future, it's going to continue to be e-mail that makes the world go round. Groove can use e-mail as the vector for an invitation into a shared space, but otherwise doesn't facilitate communication among mixed groups of Groove and non-Groove users. How can Groove best co-exist with the current e-mail habit, while at the same time reforming that habit?
Ray: As you are subtly implying, the best co-existence strategy is one of integration. And, as you say, this is specifically why we've embraced e-mail as a key mechanism for invitation into Groove shared spaces. That said, two mechanisms are available -- albeit currently in prototype form -- that will assist in bringing e-mail-based users into collaboration with Groove shared space users. As Groove matures over the upcoming months, we plan on integrating more and more of this level of function into our base tools.
First, it's possible to send e-mail directly into a shared space (through a Relay Server) -- provided an appropriate method of addressing the e-mail, and a cooperating tool within the shared space. Thus, e-mail users will be able to, in essence, send or "cc" e-mail directly to a group of users sharing a Groove shared space.
Second, if designed to do so, it's a trivial exercise for a tool implementor to send a copy of shared-space activity to one or more external e-mail users, provided that they can format the content and activities in an appropriate way for the medium. Specifically, it's easy to copy messages (e.g., discussion items and documents) to e-mail users. It is a bit more challenging to understand how one might copy sketchpad strokes, changes to outline items, or chess moves to e-mail-based participants.
Jon: You've said that unlike NetWare or Notes or NT, Groove does not require an enterprise to deploy new directory or naming infrastructure, but that it can ride on existing infrastructure. How does that work?
Ray: When a user downloads and begins to use Groove, s/he enters one or more names by which s/he is commonly known. In my son's case, it might be his real name to his parents or a player name to his Quake friends, and yet another screen name to his EQ friends. Because most of us have multiple personas, Groove enables you to present yourself differently to different groups of people with whom you're working or communicating.
But many organizations have spent hundreds of thousands or millions of dollars investing in the assignment of unique or distinguished names for their employees. I might be firstname.lastname@example.org or CN="John Doe"/OU="Finance"/O="Big Corporation Ltd" within corporate boundaries. For this reason, Groove provides IT the capability of issuing and distributing files containing the official, preferred organizational identity -- the one from its corporate directory -- to its employees. Thus, everyone at BigCorp will know exactly what everyone else is called, and there won't be yet another redundant namespace to deal with.
Jon: Groove's security algorithms are plug-replaceable on a per-shared-space basis, so that a user who joins two different shared spaces can use two completely different security regimes. Why does this matter?
Ray: In dealing with security issues in Lotus Notes for something more than ten years, I learned a number of important things about cryptographic implementation.
First, security technology (algorithms, key widths, protocols) is virtually inseparable from security policy (law enforcement, national security). Just when you think that you've dealt with an export issue, you run into an import issue.
Second, there are issues of vulnerability -- both from a systems design perspective as well as the vulnerability of specific algorithms, specific key widths, etc. Nothing is static. In time, almost anything that we have confidence in today will at some point be questioned or questionable.
Finally, there are issues of customer preference. For whatever reason, some customers choose to standardize on specific security vendors, algorithms, implementations, and so on.
By designing our product to enable a variety of plug-in implementations, and by enabling a number of them to be used concurrently, we feel that the architecture has more than enough flexibility to carry us forward through many years of service for a wide variety of customers worldwide.
Jon: Groove generally thinks of peer-to-peer in the sense of person-to-person. But my Groove account can also propagate to many devices -- my desktop PC, my notebook PC, and so on. What's the best way to think about the relationship of people to devices in Groove?
Ray: Groove cleanly separates the notion of personal identity and device identity. We did this for a variety of reasons, but perhaps most significantly because individuals are naturally dealing with more and more devices in their work and home environment. Dealing with notions of synchronization -- trying to keep them all up-to-date -- is becoming more and more painful. The notion of just keeping simple contact lists in sync between a PC, a cell phone, and a PDA, has spawned many a new company.
In Groove, although you install the software on a given device -- e.g., a PC -- every user of the software has what we refer to as an "account," which contains all of your identities, all of your shared spaces, and so on. Through a procedure involving only a few clicks, you can duplicate your account on any other supported device. After your account has been brought to that device, all of your activities on one device are naturally and automatically kept in sync with things that you do when using your other devices. It's that simple.
Thus, we embrace the model that you may (and will likely) have multiple devices: a computer on your desk at work, a notebook computer that you use when traveling, and a computer in your den at home. Furthermore, because Groove allows more than one account to be present on any given device, the computer in your den at home can be used in Groove by you, your spouse, and your children.
Groove embraces multiple devices-per-person, and multiple people-per-device.
Next: Opportunities for other players, and enhancing the value of the pipe.
Pages: 1, 2