An application idea and a problem

[jamescarlyle <jamescarlyle at t...>]

Hi,

I'm really excited about FOAF and in particular the applications that 
can be built on top of it, rather than the FOAF vocabulary itself.

One application that I am currently building is an automatic 
notification service. When the contact details of a friend change, 
you are emailed with a vCard of the changes, so you can update your 
address book. The vCard could also be sent as a flash text (SMS) 
message, allowing you to accept the changes on your mobile phone. So 
that the application is not seen to spam anyone, it will only send 
notifications to those that subscribe to it.

Apologies if these ideas have already been covered - I'm new to the 
FOAF conversation.

The problem

Currently some FOAFers are publishing their email addresses (e.g. 
<mbox web:resource=mailto:xxxbri @w3.org /> ) while others are only 
publishing a hash (e.g. 
<foaf:mbox_sha1sum>69e3. .c55fd</foaf:mbox_sha1sum>). Email 
addresses are liable to be spammed (and will be as soon as there is a 
large enough FOAF network to make it worth harvesting addresses), but 
there is other information (e.g. home phone number) which people will 
guard even more carefully. Clearly, if contact information is 
hashed, my application will only be able to notify a subscriber that 
a friend's contact details have changed, not what they were changed 
to.

So I've been thinking on this quiet pre-Christmas Sunday of ways to 
publish an email address, while protecting it from spam harvesting, 
and would be grateful for feedback on these ideas. For each of these 
solutions, imagine a person A who lists B as a friend, and B lists C 
as a friend. D is an outsider. As well as email addresses, consider 
any sensitive information.

Solutions
1) Person A publishes his email address for each listed friend, using 
their respective public keys. B would be able to decrypt A's email 
address using B's private key, but C and D would not. Alternatively, 
A could publish a skinny FOAF file unencrypted, and point to 
individual sensitive FOAF files encrypted using friends' public 
keys. So the overhead of publishing would be high and the file sizes 
large. No additional server resources are needed, but the publishing 
client (FOAF-a-matic) would need to be smarter.

2) Person A publishes his email address using the public key of 
a "trusted service" server. The server is therefore able to decipher 
A's email address and store it. If B requested A's email address, 
the server could check that A listed B as a friend and then encrypt 
it using B's public key and return it to B. If C requested A's email 
address (perhaps C lists A as a friend and wants to be notified of 
A's email address changes), the server could work out the degree of 
separation between A and C and if this was less than a threshold that 
A had set, encrypt A's email address with C's public key and send it 
to C. If the "degree of separation" algorithm looked at the wider 
network of interconnectedness between A and C, it should be hard for a
spammer to infiltrate the network. The downside of this approach is 
the need for a separate operational service. D cannot get access.

3) C is a FOAF of A. Person B acts as an intermediary, and has a 
separate, semi-public encrypt/decrypt mechanism. B publishes the 
keys to this mechanism to A and C, in B's FOAF file, using A and C's 
public keys. Then A can publish A's email address using B's encrypt 
key in A's FOAF file, and C can decrypt A's email address using B's 
decrypt key. The result is that A is trusting B with sensitive 
information, and this can only be seen by B's friends. The advantage 
is that A does not need to publish explicitly for C, but C (though 
not D) can still find out A's email address. No separate service is 
needed.

Thoughts?

James Carlyle
www.takepart.com/weblog/