We just released version 1.5.1 of the Plaxo Outlook and Outlook Express plugin. This release contains some new features as well as numerous bug fixes and performance enhancements.

Some noteworthy changes:

• new "Build Your Address Book" wizard, a power-user feature to automatically add people to your address book that you e-mail frequently
• improved installer is more firewall-friendly and can detect and fix many common installation problems
• you can now send update request e-mails from any of your validated e-mail addresses (previously you could only send from your primary e-mail address)
• Enhanced user interface for synchronization progress dialog and preferences dialog
• fixed a bug where some address data got hidden for outlook express users
• numerous minor bug fixes (many pointed out to us by our users!)

To get the latest version of Plaxo, go to http://www.plaxo.com/downloads and click "Download Plaxo Now". Please post comments if you experience any problems.

Thanks,
The Plaxo Team

BusinessWeek online just published an article entitled The Perils and Promises of Online Schmoozing in which they discuss the potential privacy concerns raised by social networking services. Plaxo is touted as a trailblazer in consumer privacy protection. BusinessWeek columnist Jane Black writes:

Plaxo, a company that enables users to automatically update their Microsoft Outlook address books, aims to protect customers' information through one of the most stringent privacy policies I've seen: Contact information belongs to the individual. And if the company should ever be sold, its privacy policy -- a contract with its paying customers -- still stands.

Read the full story at http://www.businessweek.com/technology/content/feb2004/tc20040220_3260_tc073.htm

At Plaxo, we've been interested in the Friend-of-a-Friend Project (FOAF) and its potential applications for some time. There are potential synergies for Plaxo and FOAF both on the "input side" (e.g. you reply to update requests and/or pre-fill your registration by supplying your FOAF file) and on the output side (e.g. Plaxo can generate a FOAF file for each user that always stays up-to-date). We've built internal tools that do both of these things (in fact we quietly released limited FOAF output for Plaxo members a while ago), but we've run up against a few lingering technical and privacy-related issues that have kept us from releasing most of this work to the public. Given the recent fervor over Tribe's interest in supporting FOAF, we thought it was time to ask for your advice on how Plaxo can best work with FOAF.

Technical issues:

The primary technical issue with FOAF is that Plaxo supports more contact fields than FOAF does. We basically support all the fields that Microsoft Outlook does, which is roughly equivalent to what vCards support (note btw that we've had a feature for some time that lets Plaxo members create a link to a vCard with their contact information that always stays up-to-date). Our current FOAF tools fill out fields like mbox, phone, and workplaceHomepage, but we'd like to be able to read and write a user's full set of contact fields in FOAF. What's the right way to do this? Surely every social networking site has the same problem in one form or another (fields not supported by FOAF). There's a W3C Submission on representing vCards in RDF (and the RDF could be included in a FOAF file) but that seems to have languished and it's not clear how widely supported it is. Are there alternative schemes that people currently use to augment a FOAF file with additional contact information? Any suggestions on how we can import and export rich contact information with FOAF?

A further limitation of using FOAF files is that they're one-size-fits-all, i.e. you generally have a single FOAF file for everyone to view. In contrast, Plaxo members can set up detailed permissions about which users can see what of their info. So there's no single FOAF view that's appropriate for everyone. In our current auto-generated vCard/FOAF page, we let the user decide whether they want to share their business card, personal card, or both cards, and then everyone sees that. We could do something similar with FOAF but then each user could potentially have 3 FOAF URLs to pass around, and we don't want private FOAF files getting to unauthorized users. Any suggestions on if/how we can incorporate permissions and restricted viewing into a FOAF framework?

A separate technical/UI issue is that while we can always point to a Plaxo-generated FOAF file for a user, many users maintain their own FOAF files and might want to use them instead of their Plaxo version. For Plaxo members, we could let them type in an alternate FOAF URL, but non-members would presumably want this ability too (providing their FOAF file as part of a response to a Plaxo update request and/or as an auto-reply mechanism, e.g. "when a Plaxo member asks for my contact info, just give them what's in my FOAF file"). The problem is that most people don't use or even know about FOAF (yet) and we're wary of cluttering or confusing our interface with a feature that would (at least initially) only be appealing to a small number of users. The alternative is to obscure this feature (to avoid confusing people that don't need it) but then we're not really getting through to the people that it would benefit. Any suggestions on how we can let members and non-members tell Plaxo to use their own FOAF file without cluttering our interface and confusing non-FOAFers?

Privacy issues:

The bigger issue impeding Plaxo's public support of FOAF (and presumably the main issue that similar services are also mulling) is privacy: FOAF files make all information public and accessible by all, including the contents of the user's address book (via foaf:knows). At Plaxo we're extremely careful never to share any personal contact information without the user's consent, and we never share the contents of their address book (which differentiates us from most other social networking sites). But clearly this information is a key ingredient in making Plaxo-generated FOAF files useful: you shouldn't have to maintain separate friends lists on every site and also maintain your address book with Plaxo. So what should we do? We could of course allow users to opt-in to publicly sharing their address books (which could then be included in their Plaxo-generated FOAF file). But even this would be a privacy-compromising operation because the contacts in a user's address book might not want their information to be made public, and right now they don't really have any control over that. Plus it's like the FOAF features mentioned above--it will only impact a small number of users, but it potentially complicates and confuses the experience for everyone else, and in this case, risks running counter to our strict privacy practices, which are among our deepest core values. On the other hand, supporting FOAF without doing any linking seems half-baked at best. Any suggestions on if/how we can allow users to share their list of contacts without compromising privacy?

A FOAF-specific but related privacy issue is whether to show plain-text e-mail addresses in FOAF files or only SHA1 sums. Currently Plaxo users link to one another via e-mail addresses on their cards, so in a way we already leak the plain-text addresses in approved situations, and our permission system makes sure that no one sees any contact info they're not authorized to see (including e-mail addresses). On the other hand, many FOAF users seem to prefer to only display their SHA1 sum so that they can be identified but not spammed, and we want to accommodate those users. Plus, as mentioned above, FOAF data is generally more public and widely available than data inside the Plaxo network. Other than adding yet another obscure-and-potentially-confusing-preference about "show plain-text e-mails in FOAF files", any suggestions on how to handle plain-text emails vs. SHA1 sums in Plaxo-generated FOAF files?

Summary of Open Issues:

• Importing and exporting rich contact information with FOAF
• Incorporating permissions and restricted viewing into a FOAF framework
• Offering FOAF features without confusing people that don't use FOAF
• Sharing your contact list without compromising the privacy of you or your contacts
• Using plain text e-mail addresses vs. SHA1 sums (which is better where)

Conclusion:

There's been a lot of discussion lately on blogs and elsewhere about how social networking services should support FOAF. We totally agree that there's a great opportunity here to let users participate in multiple services without having to duplicate data and also to let developers build external services that can take advantage of the data gathered by these networks. But before we can fulfill these dreams we need to address some technical issues and, more importantly, figure out how to respect privacy in the process. We hope that some of you will have good suggestions on these complex issues, and you can be assured that as soon as we've found good solutions, Plaxo will be very FOAF-friendly!