Saturday, February 25, 2012


There are many trust and reputation systems on the Internet today, and some are more robust than others in protecting themselves from ill-intentioned users. There is already some research available on robustness of reputation systems and the types of attacks they must defend against. Another goal of the rep system in the Ethosphere is to thwart most of the more common shenanigans that nefarious users can inflict. Here are a few of the infamous ones.

Sybil Attacks

Named after the (largely fictional) book by Flora Rheta Schreibe (1973) about a woman suffering from multiple personality disorder, this exploit is carried out by having a single user create many, perhaps thousands of, different aliases within the Ethosphere. In fact, multiple personality disorder is an advantage here, allowing a single user to diversify his personality and identity in order to function efficiently in diverse, unrelated teamspaces. It is the idea of reputation in the Ethosphere that helps ensure this beneficial feature does not lead to chaos and instability.

Although it is free and easy to create new aliases, each alias begins life with a rep of zero. Any influence exerted by such a "newbie" alias is limited to what it can convince other reputable members to do, members with non-zero reps. There is no voting or other numerical advantage in having numerous alises. While it is conceivable for a user to obtain non-zero rep shares for each of many different aliases within a teamspace, having a thousand aliases with reps of 1.0 each is no better than having one alias with a 1,000 rep share.


A coordinated effort by many teamspace members, especially if they are owned by the same user (see above), might be used to unfairly influence voting and decision making. However, it wouldn't really be unfair unless such collusion could be used to artificially inflate the reputation of some or all the colluding members. The Ethosphere is designed to avoid all such possibilities by ensuring that rep shares cannot be granted from one member to another without some equivalent cost to the granting members. In all cases where a recommendation or accommodation from member @foo can cause an increase in the rep share of member @bar, such shares are actually transferred from @foo to @bar rather than being created out of nothing. For example, if @foo "likes" a comment made by @bar, a single rep share is transferred from @foo to @bar. This makes it impossible for members to collude to unfairly boost the reps of others.

It is still possible for subjective collusion to occur, where several cooperating members, perhaps belonging to the same user, all write valid but different comments in support of or against some prop. The plurality of support or opposition, rather than the merits of the arguments, might be more convincing to some. However, if there are indeed many different arguments for or against something, perhaps that should be a valid consideration.

Persona Breaks

This exploit is sometimes called a playbook attack. The basic scenario is, a member may behave well and participate constructively for some period of time, building up a high rep share, but then change abruptly with the intent to unethically influence or cause damage to the stability of a teamspace. Of course, this exploit can occur in real life also, either by design or through natural processes. For example, a person of great influence such as a prime minister, president, or CEO can experience a sudden mental break, an emotional crisis, a religious epiphany, or just a simple change of opinion, causing others who have developed a trust relationship to suddenly feel alienated or betrayed. In such cases, our only goal is that Ethosphere be no more vulnerable than real life.

There are other potential causes of reputational discontinuity in Ethosphere that we do attempt to address. For example, logins can be hijacked and passwords can be lost or stolen, enabling someone else to pretend to own an alias. It is even conceivable that valuable, high-rep aliases may be sold or traded in real life, causing an ownership change and, perhaps, a persona break. To protect against these kinds of exploits, Ethosphere allows members of a teamspace to challenge an alias in two different ways, if they become suspicious of a break. First, members can perform an action known as a auth challenge, which will cause the framework to require the user of an alias to re-enter her password and re-authenticate her identity. In more extreme cases, the members of a teamspace may see fit to perform an ID challenge for a "misbehaving" alias. An ID challenge will cause the framework to validate the user's email address before he can continue.


Reputation systems that allow negative scores are vulnerable to re-entry exploits where a low-scoring entity simply leaves the system and re-invents itself as a new alias. The Ethosphere avoids this by starting all new aliases entering a teamspace with a zero rep and not allowing the rep to ever be negative. A zero rep means the alias has no numerical influence whatsoever within that teamspace. Although there are some punitive reputational transactions that can decrease one's rep, such punishment cannot accumulate beyond the zero point.

Denial of Service (DoS) Attacks

DoS exploits are notoriously difficult to defend against, and there are many potential ways for evil doers to cause the Ethosphere service to experience slow or even curtailed operation. Protection against one incarnation of this exploit, bots pretending to be aliases, can be provided by using "captchas" in the login process to try to distinguish between human (good) and robotic (bad) users.


  1. How are units of rep generated within the system to begin with? I'm not sure this is the right entry to which to post this question, but this is the one that made me ask the question. Thanks!

  2. Ah, the bootstrap problem. The analogy with shares of a private corporation is pretty close. When one or more members initially create a teamspace, they are granted something like "founders shares" of rep. Subsequently, those shares can be transferred from founders to other members through, for example, Liking their comments. Also, brand new shares are generated when *any* member offers a Prop that is ratified by the whole team. This is not a transfer but a grant of new rep shares.

    I will explain the theory and mechanics of rep transactions in a later post titled Building Ethos out of Logos.

  3. Sounds good. It definitely encourages participation within the teamspace.