February 12, 2004

Plaxo and FOAF: What’s the right model?

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!

Email Print

About the Author

View Plaxo Profile >>
Redgee Capili

General Manager, Plaxo.com

Related Articles
Comments
  • http://purl.org/net/morten/ Morten Frederiksen

    IMHO:
    Contacts: Go ahead and use the vCard RDF schema, there are no better alternatives out there for that kind of information.
    Permissions: See http://usefulinc.com/foaf/encryptingFoafFiles
    “Remote” FOAF files: Simply skip it, after all, the data is already out there for people to point to… Alternatively, put the option in a non-intrusive place (as LJ is about to do).
    Privacy/SHA1: The latter is the answer to former! :)
    Simply put, you could expose just the SHA1 of the people known, that way nobody would be able to make any useful connections unless the known person has published information for herself.

  • http://www.boy.net Man
  • http://www.plaxo.com Joseph Smarr

    DannyAyers has a nice summary of the recent FOAF fervor mentioned above, including an opinion on the register article referred to in an earlier comment by “Man”:
    http://dannyayers.com/archives/002287.html

  • http://www.eventsherpa.com Paul

    In terms of RDF vCard adoption – eventSherpa supports RDF vCards and will be adding support for FOAF. To protect privacy, users have the option of toggling this functionality on/off. Keeping the interface clean and non confusing is an ongoing challenge as you’ve suggested. See http://pcowles.eventsherpa.com/ for an example.
    I hope to see Plaxo support either FOAF or RDF vCard in the future.

  • http://clinksystems.com Stephan Fowler

    Joseph: we’re working on a distributed authentication process that could answer some of the issues you’ve raised. It is not FOAF specific, but it has potential as a FOAF privacy model.
    See http://clinksystems.com
    Clearly, serving static FOAF files without requestor authentication can only cover the public aspect of FOAF. As FOAF is intended above all as a distributed collection of data, it follows that its privacy model needs to be equally distributable.
    As I see it, the wider problem is one of delivering the right FOAF view to a requestor who may not be local to the host server (e.g: a non-Plaxo user requests a Plaxo user’s FOAF file). Whilst the requestor might be a legitimate client to which a given Plaxo user would like to supply a priveledged FOAF view, Plaxo has no way of recognizing/authenticating the requestor.
    Our process uses a network-wide identity we call a “Contact Link”, designed for exactly this type of scenario. It’s actually just a simple URL, for instance “joseph.plaxo.com”. With it you can login to any compliant service and retrieve resources, maybe with privileges if you have been granted the appropriate permissions.
    The data owner just has to add “joseph.plaxo.com” to the permission list for the appropriate data item(s). For instance a non-Plaxo user “jane.tribe.net” could be given access by you, Plaxo user “joseph.plaxo.com”, to a privileged FOAF view of your Plaxo account.
    No passphrases are needed to authenticate users on target services. That’s transparently handled cryptographically – but in a much much simpler way than say PGP. And the data owner does not need to prepare pre-encrypted views for all his privileged friends.
    So a distributed community of Contact Link holders can easily each visit each other’s data, and grant each other permission, irrespective of where they and/or their data is located.
    Crucially, there is no central supplier of these identities, or indeed any agency with a central role to play. Contact Links can be issued independently against any domain name, by any number of web sites, organisations etc, who are all effectively peers in a network of compliant servers.
    In addition to being A user’s identity as featured in other users’ access control lists, it might be illustrative to think of a Contact Link as collapsing three FOAF roles into one easily communicated URL:
    1. – a unique identifier
    2. – a “safe” identifier
    3. – the location of FOAF data
    Also, handing out someone else’s Contact Link does not compromise their privacy, since the recipient will himself need specific permission to get any of the Contact Link owner’s data.
    We’re developing a SOAP fronted secure file server that understands the login protocol described above. We’ve currently got a Contact Manager web-app running on an alpha of the server which only implements secret v.s public data, not individual-user or group permissions, which is coming in the next release. Notably, the web app is a relatively generic XML file view (with XSL rendering), so if required could be easily used for serving FOAP views from arbitrary other schemas (e.g. we currently use a simple XML schema for personal contact info: http://contactml.org ).
    Anyway we’ll be publishing SOAP/WSDL as soon as we deliver the server proper. Ahead of that, we’re exploring how this might be applied to serving bespoke FOAF XML. I’d be very happy to explore this further with yourself and anyone else in the FOAF community.
    Stephan Fowler
    stephan@clinksystems.com

  • MJLewis

    I am deeply grateful that you are taking the PRIVACY issue so seriously. This is a critically important reason why I chose Plaxo, and I know many others who examine your privacy policy very carefully before signing on. Please do NOT compromise this strength of your product!

  • http://www.plaxo.com Joseph Smarr

    Thanks for all the great comments so far! We’re moving the discussion to our Plaxo Community Forum, so if you have more to say, please go to http://forum.plaxo.com/showflat.php?Cat=&Number=483&page=0&view=collapsed&sb=5&o=&fpart=1