[rdfweb-dev] partly anonymous web communities

[Bernhard A. M. Seefeld]

>> 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'm not sure we're disagreeing here.  A foaf:person without a 
> cleartext e-mail
> address, using a hashed one, is useful only to someone that already 
> knows their
> e-mail address.  Thus if a 'new person' wants to see if people they 
> know are
> 'already in foafspace' they can hash up the address and search for it 
> as a key.

I think we agree, here. What I want to point out is, that in the event, 
that someone outs someone's address (the social faux pas you are 
talking about), there is IMHO a big difference if that outing can be 
verified or not. If I use the real mbox and someone outs one of my 
users, everyone is able to tell that this outing is indeed correct. If 
I don't use the real mbox, then that's just an unverified claim like 
every other claim I can put on a webpage today.

Unfortunately, if I want to prevent this, I also prevent lookup by 
email address. The FOAF profiles could still provide other clues that 
would make finding a person in foafspace stable enough for the searcher 
but not everyone else. Providing a picture (as this community does) 
will help me recognize my friends easily but data miners will have a 
problem. Clues like birthdate, etc. will facilitate matching against 
what is in my brain but defeats losing anonymity.

> I don't think there's any reliable way to "prevent" someone from making
> relationship information.  This is true in the real world and it's 
> certainly
> going to be just as much of a problem in the foafspace.  The same ways 
> the real
> world says "that guy doesn't know me" is just as applicable here.  
> Thus my past
> questions of *proving" foaf provencance.

I agree, I don't think you can prevent this. But there are two levels 
of compromising: Where I just claim things and where a third party can 
verify a claim by looking at the owner's (possibly even signed) FOAF 
file.

> The value of hashing the persona URI is that it makes it completely 
> anonymous as
> to even the community itself!  That way if a third party came across 
> this
> pseudonymous foaf:person and saw that it had a persona URI hash they 
> wouldn't be
> able to even tell what community it was representing.  That way only 
> users of
> the community that would 'know' to hash the persona URI and then 
> search for it
> could make the association.  Now, that outside party, on "discovering" 
> the foaf
> persona URI structure could certainly make a hash of it themselves and 
> search
> foafspace for it.  This is where the 'hide in plain sight' aspect of a 
> persona
> URI hash is not completely private.  Were someone to accidentally put 
> their

Ah, I think I get it. This is an interesting idea.

This would even allow me to expose a membership in a "secret" community 
in my real non-anonymous FOAF file.

>> 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?
>
> That one tool doesn't suit your needs shouldn't prevent you from 
> working around
> it.  Some tools started with using unhashed addresses.  Most still 
> support using
> an unhashed address as the search query.  There has been effort in 
> some of them
> to avoid needlessly exposing addresses to the 'public'.

The underlying question is wether generating all these FOAF profiles 
without mbox and mbox_sha1sum would still be a valuable contribution to 
foafspace now and/or in the future.

If the trend would be, that the more widely used foafspace navigators 
will (or already?) support cross-referencing with properties like 
foaf:homePage, then I could do it today without adding anything new and 
completely in the spirit of FOAF.

If however, mbox / mbox_sha1sum will be expected to do something useful 
in the foreseeable future, then I would be inclined to add mbox_sha1sum 
of almost nonexistent mailboxes (almost nonexistent because they would 
never be used outside navigation in foafspace).

>>  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.).
>
> I think so but I'm not exactly sure what you're saying here.

In the first part of this paragraph I wondered how a toolwriter should 
interpret the spec in terms of implementing cross-reference.

In the second part, I thought that a generalized hashed URI mechanism 
is probably unnecessary, because you would always want to qualify what 
that URI means anyway (and thus using a more specific property to 
provide it). OTOH, your secret membership idea would be exactly a use 
case for a hashed URI without a more specific meaning.

Cheers,
Bernhard

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