Technical and Privacy Challenges for Integrating FOAF into Existing Applications

1. Technical and Privacy Challenges for Integrating FOAF into Existing Applications Joseph Smarr Plaxo, Inc. (www.plaxo.com) joseph-foaf@plaxo.com Paper available online: http://www.w3.org/2001/sw/Europe/events/foaf-galway/papers/fp/technical_and_privacy_challenges/

2. How can FOAF achieve critical mass? • Appeal of FOAF increases as more people adopt it • Need your friends’ and colleagues’ data to drive applications • Important target: existing social networking services • Large, established user base (Friendster: 10M+, Plaxo: 3M+) • Collecting exactly the data that FOAF describes • Personal contact information (profile / business card) • Links to other people (friend list / address book) • Key challenge: convincing SN services to adopt FOAF • Technical hurdles (how to make it work) • Privacy issues (how to make it acceptable)

3. FOAF Adoption: The story so far • Impressive grass-roots adoption of FOAF • Individuals building and hosting FOAF files • Some online services auto-generating FOAF for members • TypePad, LiveJournal, tribe.net, etc. • Social networking services collecting FOAF-like data • Millions of closed profiles that can’t easily be moved / extended • Time-consuming / repetitive to enter your data for a new service • Supporters call upon SNSes to add support for FOAF • “I want my data back”

4. The call for Social Networking Servicesto support FOAF • Comments range from suggestions… • “Why can't you export your Orkut profile into a standarised [sic] FOAF profile? That would seem to make a lot of sense.” • …to “forceful suggestions”: • “When are you going to support FOAF!?!? If these other services don’t support FOAF I think we should boycott.” • Plaxo has experimented internally with FOAF • We want to answer this call, but we need your help…

5. Plaxo: It’s your address book • Plaxo keeps your contact list up-to-date • Most address books quickly become stale • People move, change jobs, get a new cell phone / email address • Plaxo builds an Outlook plug-in that syncs you and your contacts • When their information changes, you get it automatically • Permission-based: you choose what information to share with whom • More than 3M Plaxo members (adding >100K / week) • 2-year-old startup in Mountain View, CA • Founded by two Stanford engineers and Napster co-founder • Funded by Sequoia Capital, Cisco Systems, et al.

6. Why Plaxo is excited about FOAF • Plaxo maintains FOAF-like data • Business and personal cards for each member • Address book (links to other Plaxo members) • We want to build a global / ubiquitous contact network • Should be integrated with all applications that need contact info • You should never have to re-type contact info • Value is in the network: we want everyone to have access to it • Started with Outlook/OE because of its market share • We believe in the value of an open network • We have a SOAP API for partners to Plaxo-enable their services • The network is more valuable the more applications use it

7. What could Plaxo do with FOAF? • Input: respond to an update request or join using FOAF • No need to re-type contact info, import your contact list • Output: publish your contact info / address book in FOAF • Easier to join new services that require this same info • Easy to extend the Plaxo network with additional services • Hurdles to FOAF integration • Need to support richer contact information • Need to only show the data that permission has been granted for • Need to respect privacy of members and their contacts • Meeting these challenges critical for wider adoption • Most existing applications face similar issues

8. Technical Challenges Extensibility – storing more data with FOAF Permissions – deciding who can see what Authentication – identifying users’ permissions

9. Technical Challenges: Extensibility • Members keep more contact info than FOAF supports • Job title, birthday, etc. (essentially same data as vCard/Outlook) • Most services will store extra data of some kind • Ideally members should be able to preserve this data when importing / exporting using FOAF • How much should FOAF be extended? • Core FOAF standard will never support everyone’s custom fields • Lowest-common-denominator will often be too weak • Need a standard way of adding common extensions • Both technical process and community guidelines / collaboration • What’s the best way to do this?

10. Possible Solutions: Extensibility • Mix in tags from additional namespaces with FOAF files • Standard process for RDF / XML • Proposed schemas already exists (RDF vCards, ContactML) • Many FOAF files do this already using a wide array of schemas • Need “best practices” for extending / augmenting FOAF • What types of data should and should not be stored in FOAF? • Need repository of common extensions to FOAF • Make it easier to find and agree upon additional schemas • Allow FOAF usage to develop while remaining universal

11. Technical Challenges: Permissions • FOAF files today are static and public • Any Web surfer (or agent) can see whatever is published • Contrast: SNS members grant detailed permissions • Who can see your business vs. personal information • Who can browse your address book (always private for Plaxo) • Need to respect permissions when generating FOAF • Can’t publish private information without members’ consent • Can’t show information to others that don’t have permission

12. Possible Solutions: Permissions • Different FOAF files for different recipients • Separate URLs for sharing public and private information • Essentially like password-protecting private FOAF files • Currently used by Plaxo, HowdyCard, et al. (keys in query string) • Drawback: results in several FOAF files for each member • Hard to remember which URLs to give to whom • Fine-grained permissions would lead to combinatorial explosion • No inherent protection against unauthorized viewing

13. Possible Solutions: Permissions • Encyrpt sensitive information using PGP • Proposed by useful inc. using wot: vocabulary • Sensitive data is encyrpted and linked to main FOAF file (rdfs:seeAlso) • Benefits: • Single FOAF file, potentially multiple encyrpted additions • Anyone can see public info, only those with keys can get private info • Drawbacks: • Need public keys of everyone you want to share private info with • Need to encrypt sensitive data with everyone’s public key • Need to re-encrpyt time you grant someone new permission

14. Technical Challenges: Authentication • Authentication is major barrier to enabling permissions • Need to know who is viewing the file to know what they can see • No authentication for static FOAF files published on the Web • Authentication should be distributed like FOAF itself • Within Plaxo, we authenticate members via e-mail and password • Members sign in and get custom pages with the data they can see • No problems with multiple URLs, keys, etc. • But, can’t authenticate non-members or publish data externally • Need standard scheme for authentication / permissions • No single company in control

15. Possible Solutions: Authentication • Existing work in distributed authentication • Liberty Alliance, Drupal, etc. • Server forwards credentials to remote server using RPC/redirect • Not directly tied to permissions (would need standard format)

16. Possible Solutions: Authentication • Granting permissions with clinks (“contact links”) • Distributed permissions scheme proposed by clink systems • Users create their own domain-based clink (joseph.plaxo.com) • No central authority for identities / credentials • Contact info / files granted to users by attaching their clinks • Users authenticate to clink servers via public / private key • So leaking a clink doesn’t compromise privacy • Drawbacks • Requires everyone to run clink servers and share public keys • Clinks can’t change without breaking permissions • Part data standard, part web service / API

17. Privacy Challenges Deciding how much to share Data ownership vs. privacy E-mail vs. SHA1

18. Privacy Challenges: Deciding how much to share • Most services can’t release members’ data without explicit permission • Even “public” information often restricted to verified members • FOAF support likely to be opt-in (members elect to publish data) • Problems with opt-in FOAF support • Requires educating users about FOAF and explaining benefits • Most users tend to stick with default settings • Will enough users opt-in to make FOAF worthwhile? • New features require engineering, UI real estate, support, etc. • Currently few compelling FOAF applications (bootstrap problem)

19. Privacy Challenges: Data ownership vs. privacy • Privacy concerns remain even if members opt-in • Sharing address book publishes other people’s contact info too • Need to balance rights of data owner and person data describes • US law: address book is property of the owner • If you give someone your business card, you can’t steal it back • Debate over whether this should apply to digital information • Publishing data in FOAF would intensify this tension • No address book sharing  3rd party concerns are ideological • Real harm if your data gets published on the Web (spam, etc.)

20. Privacy Challenges: Data ownership vs. privacy • Need to find middle ground on how much to share • Want to respect privacy of address book entries • But, removing foaf:knows links destroys emergent network • Ecademy et al.’s solution: • Members decide how much personal contact info to share • Contact list contains only name and e-mail (SHA1 sum) • Establishes network topology without leaking 3rd parties’ data • Drawback: rich address book data is lost • Undesirable for moving between services, etc. • Assumes a world in which everyone maintains their own FOAF

21. Privacy Challenges: E-mail vs. SHA1 • Hashing e-mail addresses allows links without spam • But, actual address must be shared to enable communication • When is e-mail vs. SHA1 appropriate to display? • Need set of best practices for handling e-mail addresses • Plaxo: links are established via e-mail; no leakage in-network • Ecademy: members share raw addresses, SHA1 for contacts • Larger issue: who is the focus in an FOAF file? • Ecademy: FOAF primarily about author (no contact data) • Plaxo: members want their address books full of data • Need guidelines for how much 3rd party data to share and when

22. Conclusions: • Widespread adoption of FOAF would be greatly aided if existing services with large user bases publish data • Advocacy alone is likely to be insufficient motivation • Requires solving real technical and privacy challenges • FOAF community should discuss / develop solutions • Provide technical roadmap to companies for FOAF integration • Explain privacy trade-offs and best practices • Provides new research opportunities for FOAF • From data format to permission model and authentication API? • Socially-conscious division of data and sharing?