[rdfweb-dev] partly anonymous web communities

[Bill Kearney]

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

Oh most certainly.  This is why some foaf tools use a 'different' sort of link
between bidirection relationships vs unidirectional.

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

Yes, you are right on the mark.  It would be a /very bad thing/ for you to hash
and list their private addresses.

> Unfortunately, if I want to prevent this, I also prevent lookup by
> email address.

Yes, the existing tools would be unable to handle searching for your users.
That said, FoaF is an evolving thing and it's not unreasonable to think the tool
makers wouldn't be willing to enterain extensions to foaf that better support
your need.

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

What's worthwhile here is using foaf even if you're not ever going to expose the
data.  You could well come up with some well-written web pages and code, refine
their usefulness with your community and then possibly expose those
tools/webpages as ways for better public foafspace navigation.  Meanwhile you'd
gain from watching what the public foafspace does.

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

Yep, signing via pgp/gpg is completely supported.  Not too many tools are using
it as this point but the core idea has already been implemented.

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

Well, you could and it would certainly fall into the 'hide in place sight'
category.  Sort of like a secret handshake or car license plates.  I'd be
cautious about doing it because it might lead to accidental leaking of
unintended data.  As in, someone naively cutting and pasting the wrong files
together.  The resulting public relations disaster as they flail about "blaming"
you would be a train wreck.   But yes, you're right and that was my point, the
hash is only sensible to someone that knows how to make the source string and
then knows to search foafspace for it.

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

Sure, as my comment above suggests you might well come up with some membership
handling techniques that would have a good overlap with the public foafspace.

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

Dan's indicated foaf is expected to have a degree of fluidity in the near term.
So there's not too much risk of things 'going wrong' by discussing extensions to
it.

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

I'm not sure I agree, better to perhaps add your own subclass of elements based
on FoaF and wage a lobbying campaign to get them considered for incorporation.
Nothing convinces people of the utility of an idea like a working implementation
with lots of data.

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

Sure, the ability to have hash alternatives for each and every element would
seem messy.  To allow for either/or behavior seems likewise messy.  Having
plain/hash alternatives for certain key elements seems like the only reasonable
compromise.  If for no other reason that RDF being triple based, not quads.  As
in <foaf:mbox type='sha1'>....  As for which elements to choose as hashed
consider that there's also the idea of using XMLSIG signed and encrypted
/fragments/ that could live in external files.  Using something like seeAlso
doesn't quite work here because you're looking to publish something that's
searchable but not by mbox.

Anyway, the question is whether the foaf 'community' is listening and wants to
debates the idea.  Sometimes this takes a little while.

-Bill Kearney