[foaf-dev] FOAF-based whitelisting project

Kingsley Idehen 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:
>>  http://konfidi.org/wiki/Create_a_FOAF_file
> 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 
> hand.  
>> 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
>> GPG.
> 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 
> there.
>> 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 
> anyone. 
> Cheers,
> Kjetil

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 mailing list