Scalable Trust 2
Poltergeist
storks.
Since we already have spammers in our midst, some day our fledgling
opt-out service may be flooded with such huge hordes of zombies that
each real frog is surrounded by fifty zombie machine, each emulating a
hundred frogs. Each emulation might accumulate good karma by submitting
real spam that refers to real spamvertiser websites.
When something like this happens we will need a system that doesn't
depend on the 5000 zombies around each frog for storing our data and
relaying our messages.
To make sure our volunteers can work on real spam we need a system that
can cope with a haystack where every needle is surrounded by 5000
straws.
I think I have a good solution for this.
Another thing. Our adversaries are organised crime syndicates. Some of
them may be totally callous. And they will be far more motivated than
any of us. Maybe some of them will do anything, whatever it takes, to
hunt down and stop any people that we put in the top of a hierarchy. To
protect our people we may need to remove this temptation altogether, by
making sure that we don't have any hierarchy with a tempting,
vulnerable top.
I think we can solve these problems by dividing our network into small
networks of trust.
SMALL NETWORKS OF TRUST
Our network would consist of a very large number of small networks of
trust. Each such network would be largely independent. Frogs would
connect only with other frogs that are in the same or in a neghboring
network of trust.
If frogs are to become popular they must have a very simple user
interface. The way I imagine it, to create a network of trust,
basically all you have to do is exchange once-only passwords and a
special e-mail with someone. You also have to assign a trust score. The
rest is automatic.
If Alice wants to join us, Bill might invite her to join his network of
trust. If Bob also invites Alice and she accepts, then Alice will be a
member of two networks. With two people vouching for her, Alice's
influence is increased.
If Bill and Bob are members of Celia's network, this does /not/ make
Alice a member of Celia's network.
Spam submitted by Alice is first seen by Bill's and Bob's frogs. They
calculate a priority score and pass it on to Celia's frog. Celia's frog
calculates a new priority score and passes it on further.
Typically you'd invite people you know and trust to your network. But
if you don't mind spending time adjusting scores up and down you can
also invite distant acquaintances, and even unknown, untrusted people
whom you put on probation.
Technical details: Each trust network is implemented as an independent
de Bruijn graph. However, if the members are offline so often that
connectivity suffers, the network gets help from a trusted neighboring
network. I'll discuss such things in more detail below.
PERSONAL SCORES
You must give a personal score of trust to each person that joins your
network, and to each person whose network you join. You pick the score
that seems to fit best from this list:
[5] A trusted friend who understands okopipi enough that you know that
he will contribute constructively.
[4] A respected acquaintance, you believe that he will contribute
constructively.
[3] A distant acquaintance, he seems nice and reasonably competent.
[2] Unknown people, a large majority will behave well, a small minority
will misbehave. This is the score that a large ISP should give most of
its customers.
[1] You have reason to believe that this person will misbehave in minor
ways from time to time.
[0] No trust at all. A bot, a person who you think will misbehave
frequently, a person who can't understand how to use our service, a
mistrusted person on probation.
You cannot see what scores people have given you.
You can change a person's score whenever you want.
AUTHORISATION
To get our opt-out help you must also indicate what tasks you authorise
each person to perform or delegate on your behalf. You must indicate
this for each person that joins your network, and for each person whose
network you join.
With this trust arrangement, when you submit spam you are /not/
reporting the spam to some central authority that decides for everyone
how to deal with the spammer. Instead you're asking a few people, a few
close neighbors in the network, to help you with the opt-out procedure,
just like you might ask some friends on the phone.
Your neighbors may in turn ask their neighbors, if you have authorised
them to delegate.
You can also authorise the okopipi volunteers in general to
collectively make certain decisions on your behalf, based on votes
among the volunteers.
You can authorise individual frogs to step in and substitute your frog
to perform certain tasks when your frog is offline. You can allow or
forbid a neighboring network to relay messages for your network if your
members and you are offline a lot.
You can change the authorisation settings whenever you want.
CALCULATING SPAM PRIORITY
When Alice submits spam, copies are stored in the Distributed Hash
Tables of Bill's and Bob's networks. Bill's and Bob's frogs are
notified. Each of them separately calculates a priority score that is
based on how much each one trusts Alice. Both results are stored in the
DHT of Celia's network.
Celia's frog calculates a new priority score, based on the priority
scores that Bill and Bob have given the spam and on how much Celia
trusts each one of them. It stores the aggregated priority score in the
DHT(s) of the network(s) where she is a member.
And so it spreads through the supernetwork.
CALCULATING VOTES
When volunteers decide things collectively by voting, the personal
score of trust defines how many votes each person has. If two members
with a score of 5 vote yes, and one with a score of 2 votes no, this
counts as 10 votes in favour and 2 votes against. Thus high-score frogs
have a much stronger influence than low-score frogs.
When votes are communicated from one network to another they are
re-calculated based on trust, it's very similar to the calculations for
spam described above. Thus each network will arrive at a different
result, based on the various trust levels and authorisations along the
way. Each network and each individual opt-out case may arrive at
different conclusions and decisions.
WORKING ON SPAM
When you want to work on spam you choose a task and click on a
corresponding frog button. Your frog then shows you a list of spam that
is at the stage you have chosen, selected and sorted by factors like
authorisations and priority. You choose one of these spams, and your
frog shows you samples of the spam, some statistics, and any comments
left by people who have worked on earlier stages.
With that, you get to work.
As you see, there is no central coordination, you don't have to ask
anyone what to do or wait for anyone's permission. You have already
been authorised by your network neighbors.
An important legal point here is that you represent the few close
network neighbors who have indicated that /they/ trust /you/ to perform
this task on their behalf, either by direct trust or by delegation. You
do /not/ represent everyone on our supernetwork who has submitted the
spam.
Thus, if you call a spamvertising company on the phone to ask them to
respect our opt-out list, you might start by saying "Hello, I'm calling
on the behalf of seven people who have received your spam."
The small number has the advantage that the person you talk to will
feel that you represent real people whom you know and care about and
answer to, not just some nebulously anonymous mass of unknown users who
don't know you.
Unknown users, the spammer might add, who could be a zombie horde in
this particular case.
Of course you're still helping everyone in our supernetwork who has
complained about the spam, even if you don't represent them. The
results of your work will spread quickly throughout the network,
following trust and authorisation paths of delegation, checking and
voting.
And of course it's a good idea to /also/ tell the spamvertiser that
there seem to be N thousand people in our large supernetwork
complaining about the spam.
This limited, local representation is very important. Hopefully ISPs
and e-mail providers will eventually recommend our services. For this
to happen we must be carefully, scrupulously legal and polite. With
this in mind, and having no central authority, each one of us can only
represent the close neighbors who have authorised us.
One interesting side effect of this limited representation is that if
some company just won't stop spamming us, no matter what we do, then
it's quite reasonable for us to conclude that it wasn't enough that a
few people representing only a tiny fraction of our userbase called
them, and that therefore they need to be called on the phone by all the
other volunteers who represent all the other people who have submitted
their spam, so that everyone who complained gets represented. Everyone
has the right to get represented.
Unfortunately for the spamvertisers we have to stagger this carefully
over time, to avoid DOSing them. Each operator must have time enough to
present himself politely, and to explain the situation, and to give
arguments that might convince them. Therefore it won't be just a storm
that blows over shortly. It will keep coming, steadily, relentlessly,
for a very, very long time.
This may be torturous, but we must play by the rules. We can only hope
for their sake that they have lots of time and patience.
OPT-OUT REQUIREMENTS
Only your frog can send an opt-oput request for you. This cannot be
delegated.
When it's time to send an opt-out request, your frog will first check
that three conditions are met:
[1] You must have submitted the spam yourself. It is not enough to let
your ISP or your spam filter decide. Only you can authorise our
volunteers by submitting the spam.
An efficient way to do this is to let your spam filter collect the spam
in your junk folder. From time to time you check through the folder,
and then click a frog button and a confirmation dialog, and all the
junk is submitted in one swift stream.
[2] A predefined series of required tasks and approvals must be signed
to confirm that they have been completed. This must all match the
authorisations that you have given in your okopipi configuration.
[3] A time-staggering function must have assigned a time slot during
which your frog is allowed to perform the opt-out operation, to avoid
DOSing the spamvertising company.
Again, unfortunately for the spamvertisers, this means that the
opt-outs will be spread over time. It won't be a temporary flood that
is soon over. Instead they will keep coming in, one after another, and
the next, and the next, for a very, very long time.
This won't bother the spamvertisers much if they have fantastic amounts
of time and unlimited patience.
USER INTERFACE: CREATING A NETWORK OF TRUST
The trust network configures itself automatically when you invite
somebody.
To create your own network of trust, basically all you have to do is
exchange once-only passwords with the person you invite, and have your
frog send, to the invited person's frog, a specially formatted e-mail
that contains connection data, keys etc. The invited frog reads this
automatically and connects to your frog. Once the frogs are
communicating they set everything up automatically.
The user-interface procedure is slightly more complicated than
described. You have to go through some minor hoops that prevent
careless clickbacks and certain types of social-engineering attacks.
No central server is involved, everything happens locally. The
once-only passwords serve as initial authentication.
TECH DETAILS: NETWORK TOPOLOGY
Each network of trust is a self-contained de Bruijn graph where each
frog connects to eight other frogs, or to all frogs if there are fewer
than eight.
Each frog can belong to up to eight such networks. Thus you can have up
to 64 connections, 8 networks with 8 connections in each network.
One of these networks is your own network of trust, consisting of all
the people you have invited. The other seven networks are those you
have been invited to. Thus you can only get invited to seven networks.
The limitation to seven networks is not a disadvantage, it's a useful
feature. It encourages good behaviour. Every invitation increases your
influence. If you get seven invitations you're counted as seven people.
You can't accumulate trust by getting invited by a huge anonymous
crowd. If you care about getting influence, what you need to do is get
invitations from seven people who trust you enough to give you high
scores, and who in turn are likely to be trusted by others, so that
they receive high scores, and so on.
Although you can only connect to eight networks, each one of these
networks can be quite large. Thus if you want you can invite lots of
people into your network.
Inviting a person does not affect your influence in any automatic way.
But the people whose network you have joined are likely to adjust your
score depending on how well you score your network members.
A big company might create a network of trust with several thousand
employees or customers. I think we should cap it at around 32.000
people. Unless I'm mistaken the largest distance within the network
will then be five hops.
There can be loops in the network. In the example above, Alice was a
member of Bill's and Bob's networks, and they were members of Celia's
network. If Alice then invites Celia to join her network, Celia loops
back to become a member of Alice's network.
These loops introduce complications, but they are important, because
without them our supernetwork would become a hierarchy.
CONCLUSION
This arrangement offers safety for our people, as there is no powerful
center of authority that can form a tempting target for attacks on
people.
Attacks on any limited part of the supernetwork will have only a
limited influence on the whole.
Even extremely large hordes of zombies will be largely isolated from
the volunteers who are doing the real work. Some influence from the
zombies will seep through, but only with a low priority.
Even if our user base grows explosively, there won't be a center of
authority that gets swamped with work, difficult to reach, difficult to
convince about things, and so on. Everyone acts locally in his own
network neighborhood.
Constructive behaviour is encouraged, as people who form close-knit
groups of known and trusted friends get the most influence.
The arrangement is immune to the "binomial attack" that is described
here: http://wiki.okopipi.org/wiki/Talk:Security_concerns
These frogs can survive a tremendous invasion of storks.
Spy der Mann
you read the paper about virtual hierarchies?
http://www.cs.dartmouth.edu/~sws/pubs/ms02.pdf
What's your opinion about it?
Spy der Mann
ideas (except blatantly evil ideas like DDOS'ing servers), but I think
we need to organize ourselves more.
I'll put it in Zeb's own words:
--- snip ---
Thanks Spyder, I was also thinking the thread had wandered.
I've read all but one of those papers you posted in the other thread
and there are a miliion interesting things I've made notes on related
to the karma concept and establishing trust in a P2P environment. In
fact, the authors touch on every issue that we are discussing in one
place or another. (Except the opt out stuff. That's new academic turf
perhaps, and not part of this thread. ;)
But I'm in the mood now to keep studying. I'm discovering that most of
my so called "coolest ideas" have already been thunk up in these
papers. There is loads on establishing trust and accountability in the
kind of environment we need but each paper comes from a different angle
and needs to be studied for what it is.
Sorry I don't have anything directly pertinent to this thread except
maybe: More people need to read those papers, find more papers - read
them, and then.. Maybe we should put together a task force to write
our own paper to publish to the P2P, Security and Spam communities.
I feel like we're starting a long road trip without a map.. Let's
write a map.
Did you know they have conventions on P2P?
Sheesh! :)
Zeb.
-------------
Thanks, Zeb :).
See, I think that we could be wasting valuable time and human resources
by trying to come up with our own ideas and depending exclusively on
them. It's like reinventing the wheel. Why not read the papers and
refine our own ideas from there?
For example, my idea for a hierarchical trust had a flaw: A compromised
node could dominate nodes below. When I read the virtual hierarchies
paper i realized that by simply replacing one for two nodes in the
hierarchy (so the hierarchies would be based on pairs of nodes), the
system became much more robust.
This is why I propose to read those papers and then base our ideas
there. I still haven't read your post (it's too long, and I'm too lazy,
sorry ^^; ) but I'm sure that if you read those papers your ideas could
be improved a lot.
In any case, I appreciate your help. You're a valuable member of the
group :)
Spy der Mann
SMALL NETWORKS OF TRUST
I disagree with your idea of using separate de Bruijn Graphs, it's
overcomplicating things. (It perhaps could be used for the hierarchy,
like using different levels of networking depending on the trust. But
I'll leave that for a separate discussion)
However, I agree with your general idea, so let's adjust the proposal.
Add "shortcuts" to a node's routing table, as a separate "backup"
network where friends know each other's IP, but only for messages that
go from-to each other. Actually this has already been proposed in
previous literature, it's called a "friend to friend" network.
Establishing the F2F architecture would help us with the administration
hierarchy.
The novelty with your approach is that, while I only had envisioned it
for the administrator servers, turning Okopipi into a F2F network gives
us improvements on the network stability: a) bypassing the p2p network
to makes sure the messages get thru in case of a network disruption, b)
They save bandwidth for the rest of the network, and c) The messages
can't be intercepted by infiltrators. d) If we can make these
connections and messages independent from the Okopipi network, the
trusted nodes could only log in for finding their friends, and then log
out, while maintaining connection. This is a boost for security!
Notice that I only recommend this for using shortcuts in the routing
tables. The messages must remain within the Okopipi protocol. Otherwise
we run the risk of turning the Frognet into a major chat / filesharing
network, and this isn't our goal.
OK, one issue tackled. :) Let's go for the next!
Poltergeist
I checked /all/ the papers and /all/ the discussion threads. I have not
yet read every paragraph everywhere, but I did check quite thoroughly,
to make sure my proposal was a sufficiently significant improvement on
the discussed alternatives to be worth the effort (as far as I could
judge of course).
None of the threads give good reasons for spending so much effort on
hierarchy and authority.
None of the threads and papers solve the problem of how to cope when
the real nodes are a numerically insignificant minority.
> What's your opinion about it?
It's a very interesting read, but I think it's better to aim for a
safer and simpler architecture where we don't need such defense
mechanisms.
Poltergeist
re-invent the wheel.
But the discussions here are going in a very unfortunate direction. The
project is locking itself into a path that is unsuitable for Okopipi,
in my opinion.
All the solutions and strategies that are discussed in any depth depend
heavily on hierarchy and authority. People are discussing as if
hierarchy and authority were unavoidable. Complicated solutions for
alleviating the inherent problems are proposed, reinforcing the
lock-in.
It's a very large amount of time and effort to spend on something we
could simply remove. Proposals like hardcoded keys, hiding command and
trust servers, building virtual hierarchies, and so on, are defense
mechanisms to protect hierarchy and authority.
I'm beginning to feel that anyone proposing a solution for protecting
hierarchy and authority should first give some clear, compelling
reasons why hierarchy and authority are needed in the first place, why
they are so valuable that they warrant the cost in complexity of
specification, coding, debugging and maintenance, to say nothing of the
risks.
While discussing solutions, people should be clearly aware that
excellent solutions without hierarchy and authority are possible.
So I'm not trying to re-invent the wheel here. I'm trying to show clear
evidence that a less costly path is fully realistic and well worth
considering.
Poltergeist
That's odd. I find your solutions far more complicated than mine.
You have a host of clever strategies to tackle the problems that are
inherent in the hierarchy-and-authority approach.
All I have is eight routing tables instead of just one. That's it.
The need for all the other infrastructure simply vanishes. The security
issues vanish. The need to tackle them vanishes.
Was my explanation unclear? Did you think I started out with a large
central P2P network infrastructure, and then tacked on the trust
networks on top of that? That's not what I intended.
The only networks are the trust networks. Their code footprint is
small. They are safe, simple, clean.
Spy der Mann
topology, and I do accept i was complicating some things... i was
giving ideas. But the ideas are becoming clearer, and right now i'm
thinking on how to establish trust groups with anonymous routing over
the network. I think i'm 90% done with the algorithm, I'll keep you
updated.
nano
have proposed and continue to propose a simple fully-connected network
design that is nothing more than a DHT and a broadcast ability. In
fact, my design is much simpler than yours, because your design
involves coordination between individual DHTs, trust levels,
invitations, voting, etc. My design does not have a need for those
things.
As I've stated in other threads, my proposed DHT network has only a few
functions:
1) Store data in the DHT
2) Retrieve data from the DHT
3) Compile lists of most common data (specifically, spam reports)
4) Broadcast availability of an opt-out script
Your network would also have to deal with many other functions. Not to
mention the fact that you haven't discussed how the
overlay-overlay-network works. (That is, how do messages get routed
between the individual networks?)
I also think that your design has usability issues. Wouldn't it be
simpler if there was just one network? No invitations necessary, no
need to set trust levels. You just download the client and run it.
Voila, you're already working. Not to mention that there are possible
security risks if spammers start inviting a bunch of peers to their
networks, disguising themselves as anti-spammers, and then use those
peers to send spam.
Poltergeist
> In
> fact, my design is much simpler than yours, because
I should have said "simpler where it really matters." As long
as we're infested with bots there will be patches upon patches,
complexities upon complexities, crises upon crises. Once we're
rid of infiltrators we can work in peace with the rest.
Inevitably there will be a period when zombie bots outnumber
our frogs by a thousand to one. If you can solve this problem
convincingly using your topology, I'll probably become an
enthusiastic proponent. It really is wonderfully elegant,
if only there were a convincing, reliable solution for keeping
the bots out.
> Your network would also have to deal with many other functions.
Certainly. But many of those functions are quite trivial. But
indeed some are much more complicated than I really like.
Still, I just can't imagine that compensating for ever-present
foes in higher layers can be simpler. It's in comparison to this
that I think my solution is extremely simple.
> Not to
> mention the fact that you haven't discussed how the
> overlay-overlay-network works. (That is, how do messages get routed
> between the individual networks?)
Umm, excuse me, are you complaining that my test is /too short/? :-)
I think I have satisfactory solutions for this, but I felt that it
could wait a little. There are several things I've left out in order
to keep the length of the text reasonable.
So I'll get back to that.
One thing that may be worth mentioning now is that, if we use
my arrangement with several de Bruijn graphs, we might add yet
another de Bruijn graph, this one having a few more connections,
and let this network encompass all nodes that have a reasonably
high trust score. We'd use the more resilient trust networks
for trust metrics, coordination messages, voting, administration
and so on, and the big network for quick and efficient handling
of spam and other high-traffic tasks.
That would become a combination of your solution and mine.
Whenever the big network is brought to its knees, the trust networks
replace it, also for high-traffic work (possibly pared down), until
we have a functioning big network again.
This should give an excellent combination of resilience and efficiency.
> I also think that your design has usability issues.
An invited person who just wants to get his spam processed might get
this dialog:
,-------
| If you accept the default settings you allow nano to perform
| the following tasks on your behalf:
|
| -- Contact spammers and ask them to respect our opt-out list.
| -- Write opt-out scripts.
| -- Vote to approve or disapprove opt-out scripts.
|
| Also, if you accept the default settings you allow nano
| to delegate the following tasks, on your behalf, to other
| volunteers, who may in turn delegate them to others:
|
| -- Contact spammers and ask them to respect our opt-out list.
| -- Write opt-out scripts.
| -- Vote to approve or disapprove opt-out scripts.
|
| [Accept these defaults] [Change these settings] [Cancel]
`-------
I think the user should see and approve this personally, in order
to give the authorisation legal status.
His trust rating for the inviter (here nano) need not be shown,
and can be set to a default value. This setting is meaningful
only if there are several inviters, and stuff must be sorted
by trust/priority, or if he builds his own network of invited
people. The score has no effect at all on the inviter's (nano's)
score among his inviters upstream.
People only need to adjust these settings if they get involved
by creating their own trust network and/or by volunteering to
perform tasks.
> Wouldn't it be
> simpler if there was just one network?
It would certainly be far simpler if we were not under constant
vicious attack.
> Not to mention that there are possible
> security risks if spammers start inviting a bunch of peers to their
> networks, disguising themselves as anti-spammers, and then use those
> peers to send spam.
How do you use a frog peer to send spam? In my opinion we should not
have a [Become spambot] button... :-)
Jokes aside, I don't understand what you're getting at.
Spy der Mann
1. Poltergeist: I still haven't read your proposal :P sorry.
2. E-mail output by the frogs wil NEVER EVER be accepted by the
steering committee.
3. I think the basic file-sharing network idea proposed by Nano is the
most adequate for a first version of the software, then we can add up
the scalable trust and all that.
Poltergeist
Snif :-(
> 2. E-mail output by the frogs wil NEVER EVER be accepted by the
> steering committee.
A good decision.
Are you referring to the invitation e-mail? I didn't really
mean that it would be sent directly by the frog -- why should
the frog have SMTP capabilities? I wrote it that way because
I was trying very hard to make the text as short as possible,
so I tried to avoid details.
It's an attachment created by the inviting frog and sent by
the inviting user. To avoid social engineering the e-mail must
have no text, and the subject must be exactly "Okopipi"...
There are a lot of tedious details, but since you have little
time, this is not where you should spend it.
> 3. I think the basic file-sharing network idea proposed by Nano is the
> most adequate for a first version of the software, then we can add up
> the scalable trust and all that.
I find it odd that you never comment on the only reason for
my proposal, the thousand-to-one infiltration scenario. Are
you hoping it won't happen? Are you hoping we can weather
it without special preparations? Do you think we have that
scenario covered with other defenses?
I realize that you may not have time to answer, but please do
think about it.
One thing: It may be a bad idea to just wait and hope that we
can weather it. If we can't, people who have participated are
in worse trouble than before.
Jonathan Yaniv
We should have something like a reporting email address, like your...@reports.okopipi.org , and if they are using lets say, another email service like maybe shaw.ca or something like that, then they can forward their spam to thei...@reports.okopipi.org
But otherwise, the frog shouldnt have SMTP. The reporting server, maybe.
Have a nice day,
Jonathan Yaniv
Cellocity Incorporated
-----
-----
Fight back spam! Download the Blue Frog.
http://www.bluesecurity.com/register/s?user=YWRtaW44MDM4
Spy der Mann
network?
That's a great idea!
Also, I had been thinking of a way to prevent spammers from
overpopulating the net. I had posted it on "the life of an okopipi
SESSION" thread...
The point would be an admin PGP-signing an authorization certificate
for your node so you can be able to log in...
The current problem with my approach is how to prevent using duplicate
certificates and have 1000 nodes cloned with a same certificate...
Perhaps I should make a thread about it.
Oh, poltergeist, the reason i didn't quite like reading your long essay
is because it covers serveral topics... I think each needs to be
discussed in a separate thread. In any case, I promise I'll print your
mail today and read it :)
Spy der Mann
I see some problems with this approach. You assume that the members of
the network either:
a) Know your IP
b) Have a permanent unique (and unfakeable) ID that you can reference.
Unfortunately, we haven't agreed on a method to get a unique pemanent,
unfakeable ID on the network.
Poltergeist
Hooray! :-)
> I see some problems with this approach. You assume that the members of
> the network either:
> a) Know your IP
> b) Have a permanent unique (and unfakeable) ID that you can reference.
The invitation e-mail contains connection data, sent in an
attached file that was created by the inviting frog. This
connection data includes the IP of the inviting frog.
The newcomer frog reads this attachment.
If dynamic IPs are involved, the invitation attachment may include
a whole bunch of IPs, belonging to trusted close neighbors of the
inviting frog. These neighbors can help the newcomer frog get in
touch with the inviting frog.
I doubt that dynamic IPs will be a problem. I believe that today
broadband with semi-permanent IP is ubiquitous enough that if you
have the IP of several close neighbors, then each time you connect
you are certain to find several neighbors that are still on the
same IP as the last time you disconnected. These neighbors can
get you in touch with the others.
We're dealing either with a trust network of friends, who have
a high level of trust, in which case the IPs of several trusted
neighbors can be handed out, or with a large trust network such
as that of an ISP, in which case a permanent IP will be available.
Did I understand you correctly? Did I answer the issue that you
meant to discuss?
Spy der Mann
How will your "mini-net" connect to the rest of the network? Who will
connect, this is, who will be the brave IP that will become exposed to
the unknown world of spammers and DDOS attacks?
Poltergeist
I'm replying in the other thread where the same question came up.
In case somebody wants to know where:
http://groups.google.com/group/okopipi-dev/browse_frm/thread/287a67c655d77b69/b8619f580544e8d5#b8619f580544e8d5
Spy der Mann
It won't work. What you describe is not a network, but a kilometric
interconnection of people. And it's extremely fragile. You could get
disconnected from the network if you have few people in your trust
list. And not ALL of them will be running Okopipi.
Instead of advocating this idea, why not just use a global network,
period? With enough people connected spammers won't even be able to
breathe because we'll be too many.
Poltergeist
> So the small networks are interconnected like a chain?
No, it's not a chain.
As I said in my previous message:
| It all starts with somebody creating one of these trust networks.
| Let's say it's Jim. Jim invites some people he trusts, maybe you
| and nano. You in turn invite me and Emmanuel to your trust network.
| I invite Tortanick. Tortanick invites wayne and secondwheel.
Note that Jim invites both you and nano. He might also invite Alice,
Bob, Celia, David, Eric and Frank. Jim's member nano might invite
Alice, Frank, Gordon, Harold, Ike, John and Kim. Jim's member Adam
might invite 137 friends. You invite me and Emmanuel, and maybe also
Celia, David, Lucas, Martin and Nelson. I invide Tortanick and also
Alice, Celia, Ike, John...
It's hugely interconnected mesh. Any message has lots of differrent
routes to any destination.
> why not just use a global network,
> period?
Because it can't work.
The spammers know that their days may be counted if they don't
shoot us down.
In the beginning, while our network is small, the spammers won't
just sit still, calmly waiting for us to grow so we can take
them out. They'll be desperate to to shoot us down while they
still can.
Being desperate, they will bring in all the artillery they
can muster.
> With enough people connected spammers won't even be able to
> breathe because we'll be too many.
In the beginning, while we're small, there will be 99.9 % zombies.
Spy der Mann
a web of chains) has an amorphous topology and it's very difficult to
handle - besides, it depends on social contact for activation and the
growth will be really slow.
About the zombies, we're dealing with it. We're planning on starting a
grassroots campaign on educating the public about botnets, so they'll
scan their PC's for viruses and whatnot. Hopefully, by the time we
launch Okopipi, the botnet problem will be weak enough for us to
prosper.
EmmanuelGoldstein
Spy der Mann wrote:
> About the zombies, we're dealing with it. We're planning on starting a
> grassroots campaign on educating the public about botnets, so they'll
> scan their PC's for viruses and whatnot. Hopefully, by the time we
> launch Okopipi, the botnet problem will be weak enough for us to
> prosper.
Don't count on it :) If you've ever seen a machine infected with
botnet rootkits, you'd know that you aren't dealing with your every-day
script kiddie. I have seen systems that have been completely owned by
these rootkits. One system that I saw a few years back had installed
all the usual suspects (ftp server, irc client, the payload for
infecting other machines, etc) and also installed hooks into the
windows kernel so that any attempts to search for its processes came up
with nothing. I /knew/ that something was there, but even
fport/netstat/etc showed nothing at all. I had to fire up a packet
sniffer to see what was going where. The software was a ghost in the
system.
So, don't count on virus scanners detecting these things and dont count
on users being able to detect and remove the bot-net software
themselves. They are far more advanced than most people seem to
realize.
Spy der Mann
least reduce the botnet growth rate.
Poltergeist
> Still, the architecture you propose (ok so it's not a chain, more like
> a web of chains) has an amorphous topology and it's very difficult to
> handle
Finally you're approaching the one difficult problem. It's solvable,
but complicated.
I think "very difficult" is an exaggeration. It's not that hard.
And the complications can of course be well contained, so that
the rest of the code sees a normal network.
Even so, I'm half hoping that I can't convince you, so I don't
have to deal with this.
> and the
> growth will be really slow.
No, it will be quick. See http://en.wikipedia.org/wiki/Six_degrees
If you prefer a summary: The number of people grows exponentially
with every hop. If every person knows 10 people uniquely, then
after two hops there are 100 people, after three hops 1000, after
four 10,000, after six 1,000,000, and after nine hops there are
a billion people. The tenth hop encompasses all of humanity, with
room left for four billion space aliens :-)
But people know more than 10 prople each. Measurements indicate that
the average separation is somewhere near six hops.
Public perception will be a more limiting factor than the requirement
to get an invitation.
> We're planning on starting a
> grassroots campaign on educating the public about botnets, so they'll
> scan their PC's for viruses and whatnot.
If campaigns could solve this kind of problem there wouldn't be any
botnets in the first place.
It's far, far easier to get people to do something simple, like not
clicking on attachments, than to get them to do something complicated
that makes them nervous, like downloading, installing and running
a acanner.
nano
will be to leverage the large amount of press we've received to do
something good for the Internets. It doesn't really have anything to do
with Okopipi itself, beyond being beneficial to our cause.
Spy der Mann
would really like to see less machines infected with viruses and
spyware... and botnets.