[rdfweb-dev] An application idea and a problem

[Bill Kearney]

Edd's got an article that discusses some of this:
http://usefulinc.com/foaf/encryptingFoafFiles

My only comment is that transitive trusts are a real pain to manage. Too often
the participants misunderstand what they've let out to trust and what they've
been trusted to share.

What is interesting, however, is the idea of using Foaf structures as
whitelisting aids. To have a mail transport start understanding how to
correlate frequencies of mail in/outbound with presense in foaf groups starts to
look rather interesting. As in, I get mail from you, but you're not on my
whitelist. A foaf traversal of "nearby" groups shows you're in the foaf of
someone else with which I frequently exchange mail. It might be reasonable to
assume that since the person with which I'm already convering 'trusts you
enough' to list you in their foaf it might be ok to let your mail get through.
Sort of a decentralized six degrees of separation on mail handling.

-Bill

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