[rdfweb-dev] partly anonymous web communities
Bernhard A. M. Seefeld
seefeld at gna.ch
Sun Jul 6 14:50:04 UTC 2003
>> 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
> 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
> 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
> 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
> 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
> foafspace for it. This is where the 'hide in plain sight' aspect of a
> URI hash is not completely private. Were someone to accidentally put
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
>> 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
> 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.
Bernhard A. M. Seefeld, http://www.bernhardseefeld.ch/
More information about the foaf-dev