[rdfweb-dev] partly anonymous web communities
Bernhard A. M. Seefeld
seefeld at gna.ch
Sun Jul 6 12:30:26 UTC 2003
> The idea behind using the hash is that if someone else knows someone's
> 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
> 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
> 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
> someone that already possesses the e-mail address can make a hash of
> it for
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
> 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
> Something along the lines of "I know about community
> 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.
> URL is http://example.com/cabal/users/joe and hashing it gives the
> string 2a38fd64922764d4ced66e9f8e5851dc683ed36e
> So a mythical markup fragment could be:
> Then anyone in the 'cabal' group could 'know' to build a URL in that
> 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
>> 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.).
Bernhard A. M. Seefeld, http://www.bernhardseefeld.ch/
More information about the foaf-dev