Technical and Privacy Challenges for Integrating FOAF into Existing Applications

Joseph SmarrPlaxo, 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/

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)

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”

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…

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.

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

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

Technical Challenges

Extensibility – storing more data with FOAF

Permissions – deciding who can see what

Authentication – identifying users’ permissions

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?

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

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

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

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

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

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)

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

Privacy Challenges

Deciding how much to share

Data ownership vs. privacy

E-mail vs. SHA1

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)

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.)

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

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

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?