[rdfweb-dev] partly anonymous web communities

[Bernhard A. M. Seefeld]

Hi,

> The idea behind using the hash is that if someone else knows someone's  
> e-mail
> address they could cross-reference that hash.  Essentially, if I  
> already know
> your private e-mail address I can make a hash and see if foafspace  
> knows of it.
> If someone doesn't know your private e-mail address using the  
> foafspace hash
> won't help them find it as they'd have the break the sha1hash.  Which  
> is
> theoretically possible but hardly worth the effort.

For me, the difference is that if you I use the real mailbox to  
generate the hash, I can verifiy that that given profile actually is  
the person I think it is by information he/she has given. You're right,  
I can only identify people if I now the possible mailboxes before, but  
then I can be sure about the identity. I think this conflicts with the  
notion that the community is by default anonymous.

Of course, with FOAF anybody can put the information that two mailboxes  
(real or pseudo) belong to the same person into foafspace, thus also  
destroying the anonymity. The crucial difference for me, is that this  
is just some dude claiming the relation (anyone can claim anything in  
FOAF) vs the first version (with the real mailbox as generator for the  
hash) would be a verifiable claim; which, of course, if usually a good  
thing, except here.

Or stated otherwise: In this way, introducing FOAF wouldn't change the  
anonymity of the community, as it was already possible that someone  
puts up a webpage and says "hey that person in this community is  
actually the same as that one here". But this is just a unverifiable  
claim, and as long as I don't use the real mailbox, nothing else is  
possible in FOAF, too.

>> This whole "fake-email to generate a unique sha1sum" method seems a
>> little awkward. Essentially this would defined the foaf:mbox_sha1sum
>> element as a general guid, rather disconnected from the notion of  
>> email
>> addresses.
>
> Yeah, it does seem 'wrong' to use a faked address here.  How about  
> providing a
> relaying service for accounts?  The point of using an mbox_sha1hash is  
> that
> someone that already possesses the e-mail address can make a hash of  
> it for
> cross-referencing.

Well, adding a relaying service would be no problem, but IMHO this  
wouldn't fix the problem in its original spirit. I mean, nobody will  
actually use this relaying service for real if I wouldn't communicate  
it enough (which in many communities doesn't make much sense). So while  
the basis for the hash would then be something that can actually get  
email, it wouldn't be a really used email address. The primary way to  
get in touch with the user is given through foaf:homePage.

> Or, I suppose, some other form of hashed cross-referencing might be  
> worth
> considering.  Perhaps a hash of a user profile page?  The trouble  
> there would be
> the complexity of defining the domain/realm of it and then the data  
> itself.
> Something along the lines of "I know about community  
> http://example.com/cabal
> and I know of a user Joe.  So I could search foafspace comparing my  
> known key of
> Joe's profile in the cabal realm and his profile URL.   The trouble is  
> how to
> markup a profile URI identifier in such a way as to be useful.
>
> Hmmm...
>     URL is http://example.com/cabal/users/joe and hashing it gives the
>     string 2a38fd64922764d4ced66e9f8e5851dc683ed36e
>
> So a mythical markup fragment could be:
> <foaf:personaHash>2a38fd64922764d4ced66e9f8e5851dc683ed36e</ 
> foaf:personaHash>
>
> Then anyone in the 'cabal' group could 'know' to build a URL in that  
> manner,
> hash it and then search for matches in the foafspace.

This sounds interesting. Let me see, if I get this right: Your goal is  
to preserve the discovery mechanisms in case of incomplete information  
about the person you are looking for. And using a URI scheme instead of  
mailboxes looks cleaner and more widely adopted. Right?

OTOH, mailto:<mailbox> is also an URI. And thus, in some sense the  
mbox_sha1sum property works in this URI-subspace, but is otherwise  
essentially a "hash of an URI that uniquely describes this user". So  
something worthwhile could be to add a general mechanism to FOAF which  
says, "All these URIs are associated with this and only this person",  
where some of those URIs might be given as hash only.

In fact, it seems like some other properties serve this functionality,  
too. This was pointed out by Morten Frederiksen:

>> The issue is that this community has grown as an anonymous system. I  
>> do
>> have the user's email address, but it isn't public. FOAF seems to use
>> foaf:mbox as the primary way of identifying people.
> It may be seen and used as the "primary" way, but it's certainly not  
> the only
> one. Several properties can be used, namely the ones that are declared  
> to be
> socalled inverse functional properties - properties that over time  
> belongs to
> one person (or organization, or ...) only. They don't have to last,  
> you can
> change these properties as much as you want, as long as the ties  
> between them
> are kept.
>
> Among those properties are currently also foaf:homepage and  
> foaf:weblog, of
> which the first should probably be of use to you and your  community.

So, all of these inverse functional properties (most of which are even  
URIs) seem to fall in this category. That is great news, and as  
foaf:homepage isn't something I would want to obfuscate I can start  
right now with it.

The reason I thought that mbox is the primary way to identify people  
is, that I got the impression, that all the tools like foafnaut seem to  
work that way, but I might be wrong? Will these tools handle my foaf  
files if there is neither a foaf:mbox nor a foaf:mbox_sha1sum property?

 From the perspective of a tool writer, who wants to maximize linkage:  
One should check for all inverse functional properties in the used  
namespaces and use them to link. (I'd guess a general inference engine  
would work that way, anyway?) This in turn would make a generalized  
"that hashed URI refers to me" property unnecessary, as usually that  
URI will also have a deeper meaning (like being a mailbox, homepage,  
picture, IM-id, etc.).

Cheers,
Bernhard

-----
Bernhard A. M. Seefeld, http://www.bernhardseefeld.ch/