[foaf-dev] FOAF-based whitelisting project
kidehen at openlinksw.com
Sun Mar 11 22:57:03 UTC 2007
Kjetil Kjernsmo wrote:
> On Sunday 11 March 2007 16:44, R. Steven Rainwater wrote:
>> On Sun, 2007-03-11 at 00:07 -0500, Dave Brondsema wrote:
>>> While making practical incremental progress is important, I think
>>> we should discuss for a little while our plans for this project
>>> so that we can work in the best direction.
>> Well, here are a few random thoughts...
>> I looked at konfidi.org. The first thing I noticed is that it appears
>> to need a GPG/PGP fingerprint for each user, based on the example:
> Yup. They do also have concrete plans to support other identity
> mechanisms such as SPF. While I'm a huge PGP geek, with a key ranked as
> the 445 most trusted in the world, I think the konfidi-project's
> biggest hurdle is that it won't be useful from day one, as that small
> number of PGP and FOAF users can more easily whitelist each other by
>> But a spammer could easily create an account on myspace and, if
>> myspace exported Dan's simple whitelist format, we'd have no way to
>> know which were real users and which were spammers.
> Not really. I'm on of the creators of my.opera.com in my dayjob, and we
> have our share of spammers, though we do our best to whack them.
> However, a spammer just getting an account should matter, as long as
> there isn't a single foaf:knows statement that has them as an object.
> Even if they put up a bunch of accounts with foaf:knows between them,
> they will remain an island that nobody else trusts.
> We should try to prevent spammers from getting foaf:knows at all of
> course, but if it is a "remote node", it doesn't really matter that
> much. It would result in a low score, and everyone would scream "are
> you really sure you know this spammer" to the person that stated it.
> Moreover, spammers tend to use random MAIL FROM addresses, if they used
> a valid address for all their spam, systems like Vipul's Razor would
> probably deal with it quite easily.
> What would be disastrous for this system is that if a spammer managed to
> sneak in a foaf:knows statement that states that a supernode (i.e. a
> person a lot of people trust) knows them. Say, for example, that a
> spammer managed to get a statement :danbri foaf:knows :spammer (danbri,
> you're surely a supernode! :-) ), since that would allow them to get a
> high trust metric for a lot of people. If something like that happened,
> it would certainly undermine the trust in the system quickly, so we
> have to be careful about that. That spammer accounts sneak in, I'm not
> too worried about, but that they manage to insert an unauthorised
> foaf:knows statement is something we need to prevent. Even in open
> systems like my.opera.com, they don't get any foaf:knows pointing to
> themselves, only from, so a dump from my.opera.com would probably be
> quite safe.
> The next probable disaster area is that once we are successful, spammers
> will probably attempt to use the email of a supernode in the MAIL FROM.
> That will make it suck to be a supernode in this system, as they would
> need to deal with all the bounces, and possibly flames from
> spam-fighting n00bs.
> I think that we would need to look into using Sender-Permitted-From or
> DomainKeys or similar to combat this problem. It is not so much a
> problem with the trust metric, allthough it makes sense to trust a SPF
> or DomainKeys-signed address more. My plugins will have to deal with
> this. This will place additional burden on the supernodes, they are the
> ones who will have to be most concerned about having their addresses
> forged and used in MAIL FROM, that's the cost of being famous, I
> guess... :-/
>> The obvious downside,
>> is that there is zero chance that a significant number of users on a
>> site like myspace are ever going to learn how to use something like
> And if they did, they probably do it so wrong that it would be
> useless... :-( There's the famous papers on "Why Johnny can't encrypt"
> and "Why Johnny still can't encrypt". The usability isn't getting
>> Maybe a combination of the two methods could work?
> Well, what I have in mind is partly that the clients will have to do
> some extra checking, like above, and partly that the PGP WOT, the
> DomainKeys signature, the OpenID identification, etc., as well as more
> elaborate statements (rel:spouseOf is a stronger statement of trust
> than rel:enemyOf, for example :-) ), and context information (for
> example, an explicit statement that you trust someone to not spam, is
> stronger than just a foaf:knows statement), would influence the trust
> metric. So, it would be a single metric, but it would be influenced by
> many factors.
> However, adding these factors is something we can do as we go, I feel.
> We need to avoid the traps that completely undermine the trust in the
> system, we cannot accept triples asserting relationships from just
What are the current Trust Metric factors?
Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO
OpenLink Software Web: http://www.openlinksw.com
More information about the foaf-dev