Subject: [Asrg] 2. Problem Characterization - Defining spam within consent paradigm

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 02 Jul 2003 12:45:50 -0400

Before every jumps on me for reopening this can of worms again, I would 
like to state that this definition only applies to spam WITHIN the consent 
paradigm:

spam = "any email that does not have consent from the receiver"

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 2 Jul 2003 13:44:46 -0400

> spam = "any email that does not have consent from the receiver"
	I don't think so... 
	It may be hard to define "spam" but that doesn't mean that we
should just accept definitions that don't make sense. There is, I
believe, a class of "unwanted" messages that the average person would
not consider to be "spam."
	For instance, a message from an ex-boy/girlfriend might be
unwanted but wouldn't normally pass the "smell test" for what is spam.
Similarly, a message from your mother which might have been rejected by
your spam filters because it was formatted in HTML (she doesn't know any
other way to send it...) wouldn't really be considered "spam" by the
average person.
	It would be convenient if we had a nice, tight, broadly accepted
definition of spam. However, I think we need to give up on even trying
to get there. Since we've pretty much proved that just about any
definition of spam is going to result in endless debate about its
correctness, let's just stop trying to define it and focus our energy on
solving the problem.

		bob wyman

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 02 Jul 2003 15:51:42 -0400

>other way to send it...) wouldn't really be considered "spam" by the

A human being expresses consent for specific messages. The consent system 
tries its best to implement those wishes. Unfortunately the wishes of 
humans and the results of computers do not necessarily match. There is a 
need for a distinction between consent expressed by a human being and how 
this consent is implemented by computers. However, the bottom line is that 
any message that a human receiver does not want - does not consent to, is 
considering spam according to that person.

Yakov

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 2 Jul 2003 16:42:28 -0400

Yakov Shafranovich wrote:
> the bottom line is that any message that a human 
> receiver does not want - does not consent to, is 
	I don't buy it. Such a definition erases the distinctions
between different kinds of unwanted messages and in so doing removes
from discussion what may be useful information.
	It may be "politically correct" to say that all unwanted mail is
spam, however, I strongly believe that taking such a fundamentalist
position is not conducive to the normally objective process of design.
	If you force all "unwanted messages" into the single category of
"spam" then you have either ignored existing distinctions or you have
just declared "spam" to be synonymous with "unwanted message". Thus,
your definition: "spam is any unwanted message" is simply a tautology.
i.e. "Spam is Spam".

		bob wyman

---

From: Barry Shein <[email-masked]>
Date: Wed, 2 Jul 2003 20:58:38 -0400

From: Yakov Shafranovich <[email-masked]>
>considering spam according to that person.

Although reasonable-sounding these descriptions are starting to remind
me of those long-ago Artificial Intelligence seminars where you'd get
to ponder why some seemingly simple human behavior was so difficult to
code into a program. "Time flies like an arrow" and all that.

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 03 Jul 2003 07:45:03 +0100

> your definition: "spam is any unwanted message" is simply a tautology.

No, this is no more of a tautology than to say "Fish are aquatic creatures
with fins". You may say that "Fish are scaly creatures with swim-bladders
and spots", in which case we have somewhat different definitions (one a
subset of the other). That's all.

The purpose of the group is to discuss the problem of "consent-based
communication". For these purposes people often use "spam" as a convenient
sorthand for "communication without consent". If you get rid of this "spam"
then your kind of spam will cease to be a problem.

To use a broad definition of the kind of message we're interested in
stopping DOES NOT make it impossible to talk about subclasses, anymore than
defining Mammals removes our ability to talk about Cats.

But it's a silly argument anyway...

--

---

From: "Tom Thomson" <[email-masked]>
Date: Thu, 3 Jul 2003 12:26:54 +0100

> then your kind of spam will cease to be a problem.

One trouble here is that one moment you write "does not want" and at another
you write "does not consent to" just as if they meant the same thing.  They
do not mean the same thing.

I consent to receiving bills from the people who supply my electricty, but I
don't want to receive those bills - I'd much rather have the electricity
free.  I don't think those bills are spam - in fact I believe that any
definition of spam that includes those bills is just plain wrong.  So spam
is NOT "email the recipient does not want".

Stick to conent, not desire.  A definition like "Spam is email the recipient
has not consented to" doesn't fall into that trap.

Of course there are issues about how consent is expressed, how we can say
that a user has consented to receive one email from one source he has never
heard of but hasn't consented to receive another email from another source
he has never heard of, and that probably brings us into the realms of AI,
probably requiring a level of sophistication in AI that hasn't been achieved
yet, but if we are lucky we may find that a good enough approximation will
be acceptable.

Then we will need some measure of goodness for approximations, which may
involve looking at how often the consent expression is misinterpreted (ie
our software "thinks" consent has been given when it hasn't, or "thinks" it
hasn't when it has).  We will find that what is good enough for some
purposes or some users is not good enough for other purposes or other users.
That leaves us right back with the same fundamental engineering issues we
have with content filters!

Of course some aspects of consent can be expressed cleanly:  "I do not
consent to receive mail which passed through a server which was, last time
MAPS checked it, an open relay" doesn't need sophisticated encoding to
represent it or clever AI to interpret it (although it does need more real
intelligence than exhibited by many sysadmins, as demonstrated by the large
number of corporate mail receivers that are using copies of the MAPS RSS
list that are over a year out of date - I imagine this pisses the people who
maintain MAPS RSS off as much as it pisses off the people who get messed up
by it).  Nor does "I do not consent to receive email from a server whose ip
address has no rDNS".  The trouble with these notions though is that the
average email recipient doesn't know what they mean, so he's not going to
express any part of his consent / non-consent (or his "consent policy" is
that's what we try to represent) in those terms.

Tom

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 03 Jul 2003 15:17:04 +0100

> definition of spam that includes those bills is just plain wrong. So spam

What are you on? Ar you talking about your electricity or your electricity
bills?

Of course you "want" (need or desire) your electricity bills, given that
your electricity *isn't* free. Otherwise the first thing you'd know is that
you get a court summons for non-payment. You "consent" (express a
willingness) to receive them when you sign up with your supplier, because
you need them.

What you "want" is a dictionary.

--

---

From: "Tom Thomson" <[email-masked]>
Date: Thu, 3 Jul 2003 17:37:13 +0100

"What are you on" is not a useful question to post on this list.

I'll risk Paul's wrath and reply in the same unhelpful vein as you have
adopted:-

I guess if you don't understand that there is a very clear distinction
between wanting something and consenting to it we will all do better to
ignore anything you say about the consent model for spam/spam control/spam
elimination, because you are clearly on something that has reduced your
ability to distinguish basic semantic concepts to the point where you can't
usefully communicate.

Tom

-----Original Message-----
From: Jon Kyme [mailto:[email-masked]]
Sent: 03 July 2003 15:17
To: Tom Thomson
Cc: ASRG
Subject: Re: RE: RE: [Asrg] 2. Problem Characterization - Defining spam
within consent paradigm

> One trouble here is that one moment you write "does not want" and at >
another > you write "does not consent to" just as if they meant the same
thing. > They > do not mean the same thing. >  > I consent to receiving
bills from the people who supply my electricty, > but I > don't want to
receive those bills - I'd much rather have the electricity > free.  I don't
think those bills are spam - in fact I believe that any > definition of spam
that includes those bills is just plain wrong. So spam  What are you on? Ar
you talking about your electricity or your electricity
bills?
 Of course you "want" (need or desire) your electricity bills, given that
your electricity *isn't* free. Otherwise the first thing you'd know is that
you get a court summons for non-payment. You "consent" (express a
willingness) to receive them when you sign up with your supplier, because
you need them.
 What you "want" is a dictionary.

--

---

From: "Bob Wyman" <[email-masked]>
Date: Thu, 3 Jul 2003 12:57:41 -0400

Barry Shein wrote:
> Although reasonable-sounding these descriptions [of consent] 
> are starting to remind me of those long-ago Artificial Intelligence 
> seminars where you'd get to ponder why some seemingly simple 
> human behavior was so difficult to code into a program. 
	We've had precisely the same issue with software licensing or
Digital Rights Management for years. The issue is one of managing
expectations. The reality is that machines can only manage things they
can detect yet people will often express their rules in terms that
involve things that machines can't detect. For instance, people will
often say that they only want mail from some specific user yet the
machine can't detect identity. The machine can only detect the use of
things which are assumed to indicate identity. (i.e. When if someone
says "Only Bob can send mail" what the machine needs to hear is "Only
someone using Bob's private key can send mail." For a person, "identity"
is an attribute of being. For the computer, identity is a property which
is assumed belong to users of certain proofs of identity. 
	But, this is all getting a bit philosophical. Barry has a point.
As we get into dealing with the issues of expressing and managing
consent, we must all be careful to ensure that people understand the
inherent limitations of machines in this realm. There is only so much
that the machine can do for you.

		bob wyman

---

From: "Madscientist" <[email-masked]>
Date: Thu, 3 Jul 2003 14:01:31 -0400

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Bob Wyman
>Barry Shein wrote:
>	We've had precisely the same issue with software 

<snip>

>detect identity. The machine can only detect the use of things 
>which are assumed to indicate identity. (i.e. When if someone 
>says "Only Bob can send mail" what the machine needs to hear 
>is "Only someone using Bob's private key can send mail." For a 
>person, "identity" is an attribute of being. For the computer, 
>identity is a property which is assumed belong to users of 
>certain proofs of identity. 
>	But, this is all getting a bit philosophical. Barry has 
>a point. As we get into dealing with the issues of expressing 
>and managing consent, we must all be careful to ensure that 
>people understand the inherent limitations of machines in this 
>realm. There is only so much that the machine can do for you.
>
>		bob wyman

There are some simple and effective mechanisms for the scenario of
identifying consent, though they may not be applicable in some cases.

Here is one that is not a complete solution, but is very effective and
solves the problem of expectation and identification in many of the most
critical scenarios (such as children and grandmothers avoiding porn
spam):

Simplified: 

1. The recipient issues a secret code (PL code) of their choice to each
of the people they wish to communicate with.

1.1. The secret code _should_ be cryptographically secure but _may_ be
anything unique enough to be effective for that user's purpose.

1.2. The user in this case _may_ be broadly defined as a group of users
such as a family, or a special team in a corporate environment.

2. The user filters out / rejects all messages that do not contain the
secret code in the body of the message.

2.1. The secret code becomes a mechanism of explicit consent.

2.2. In some cases (such as juvinile accounts) the ability to change the
code or adjust the filtering may be restricted.

3. Trusted users who receive the code may freely distribute the code to
other users whom they wish to include in the group. In this way the
"authority" to transmit messages to members of the group can naturally
extend to appropriate senders in a "viral" manner with very little
administration.

3.1. Kids will naturally share their PL code with their friends.
3.2. Parents will share/register the code with teachers and extended
family members.

4. If the PL code is compromized then it can be easily changed because a
new code can be generated and transmitted to everyone in the group (or
at least a large collection of them). If this mechanism is automated in
some way then the system can be very secure an lightweight.

5. Attempts to send to members of this group withou the appropriate code
can be used to detect attempted abuse - and these statistics can be used
to drive other mechanisms such as black lists or statisitical training
systems.

This mechanism can be implemented right now and is extremely effective.

The user's expectations are precise: If someone has the code I can hear
from them. If they do not have the code I should not hear from them.

The system's responses are precise: If the code exists then the message
passes, if it does not then the message does not pass. (The PL code may
be implemented with stronger controls such as placement in specific
message headers or other specific rules, however it generally works well
when simply included in the body of the message like a signature or some
kind of "inside joke").

The system is extremely secure because anonymous senders are not
generally able to extract or guess these PL codes and if they do then
the codes are easily changed.

The system can be extended to support legitimate mailing lists because
special codes can be provided to the mailing list author at the time of
subscription by the subscriber as part of the normal customization data
provided by the user. One variant of this is to subscribe to the list
using a cryptographic alias that can be turned off if it is ever abused.
A more secure implementation would require the author of the list to
include the code provided as part of the customized portion of the
subscriber's messages (customization is often the norm these days anyway
such as including the subscriber's name and so forth).

This mechanism naturally extends a COT model (Circle Of Trust) because
is a good example of that paradigm. COT systems provide for effective,
lightweight authentication mechanisms without a centralized authority.

This mechanism is not proprietary, not centrally controlled, represents
very little cost, and does not preclude any other mechanisms that might
also be enforced as part of a local policy.

Extended implementation example:

The mechanism can also be aggregated and driven forward within the
systems of a given provider such that individual users might register
their authorized codes with the provider (using some standardized format
established by the provider), those codes could then be aggregated into
a hash table, and message content reaching a border MTA could examine
incoming messages against the hash tables during the SMTP conversation
by scanning for the appropriate codes in the data segment before
accepting a message. If the message does not contain the code and also
does not satisfy an alternative policy evaluation then the message would
be rejected and incident recorded as abuse forcing a period of
rejections at the envelope level for some period of time (consistent
with the local policy of course).

A system such as the above might be implemented as a "Special Service"
for families with children on the internet. - This means low cost, high
value, and profit potential (so it's likely to be adopted), plus a
significant impact on spam reduction.

I recommend that this should be included in a suite of protocols and
practices that are part of the final solution.

Sorry for the length.
I hope this is helpful.
_M

PS: PL = Private Listening, from a common radio meachanism (PL tones). I
posted infromation about this in another thread I believe so I'm not
repeating it here.

PPS: We recommend and use this mechanism with great success, though I
don't have hard statistics to show. Hopefully it is logically obvious
how effective this solution can be in many scenarios. A TINY bit of
automation can go a very long way with this one also.

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 03 Jul 2003 20:00:29 +0100

> "What are you on" is not a useful question to post on this list.

Sorry, meant to say "What are you on about"

> ability to distinguish basic semantic concepts to the point where you

Tom, I do distinguish between "want" and "consent".
If you'll care to re-read my comment you'll note that I
say "You "consent" (express a willingness) to receive them when you sign up
with your supplier, because you need" (i.e. "want") "them."

It appears that you imagine "want" to mean only "really enjoy having".

Clearly an assertion of consent, unless originated by an insane person,
will cover those things "wanted".

To continue your rather strange electrical analogy, I may not like (wish,
"want" in your sense) to be charged, but given that I am charged, I do want
(need, desire) to be sent the bill.
 
I hopes this clears thing up.

--

---

From: "C. Wegrzyn" <[email-masked]>
Date: Thu, 03 Jul 2003 15:16:26 -0400

Seems like a lot of what you get with a cert. This is almost the 
approach I took with the design I did. I can tell you it works and works 
well.

Chuck Wegrzyn

---

From: "Madscientist" <[email-masked]>
Date: Thu, 3 Jul 2003 15:44:13 -0400

>From: C. Wegrzyn [mailto:[email-masked]] 

>approach I took with the design I did. I can tell you it works 

Thanks for that. The thing I feel most strongly about concerning this
type of "consent" and/or "identity" mechanism is that certification
mechanism should be open, decentralized, and entirely in the control of
the end users. Unlike certs, which usually require some centralize
authority for a signature, simple shared secrets can be created and
destroyed entirely at the behest of the user groups involved and require
no cost beyond that effort. 

(It is possible to have certs signed by some elected member of the
group, or to self sign, or to elect some local authority for the local
COT, however the entire cert discussion tends to add unnecessary
complexity I think.)

_M

---

From: "C. Wegrzyn" <[email-masked]>
Date: Thu, 03 Jul 2003 15:52:51 -0400

True. The problem is that without some kind of management scheme you 
might just find yourself having too many little secrets all over the 
place. And should you go from job to job or ISP to ISP how would this 
work? Is this a client side solution?

Chuck

---

From: "Tom Thomson" <[email-masked]>
Date: Thu, 3 Jul 2003 21:07:40 +0100

This is very like a closed use (sender) group where new members can be
introduced by any existing member. It is clearly very effective when a
CU(S)G is what you want - not quite as effective as insisting all incoming
email is encrypted with a key you provide (since sniffing the messages you
receive will eventually provide enough data to deduce the consent string)
but a lot simpler than that and likely to have far fewer deployment
difficulties.

Unfortunately, if a closed user group is not what you want, it's not very
helpful because you can never receive mail from a stranger.

The big problem with the consent paradigm is how to define consent in the
non-closed case, and what mechanisms can then be used to express it and to
police it:  how do I express which mail arriving from a stranger has my
consent and which has not?

Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Madscientist
Sent: 03 July 2003 19:02
To: [email-masked]
Subject: RE: [Asrg] 2. Problem Characterization - Defining spam within
consent paradigm

<snip>

Simplified:

Sorry for the length.
I hope this is helpful.
_M

---

From: "Madscientist" <[email-masked]>
Date: Thu, 3 Jul 2003 16:57:55 -0400

The solution "appears" to be client side, however a bit of automation
can provide for a great deal of leverage as we move from the client
toward the "center" of the network.

In practical terms, if the client moves from job to job, they might take
their secrets with them since the secrets allow them to send messages to
their contacts. (If they maintain their ISP in the move and the ISP
provides facilities to support this mechanism then there may be no
change at all).

Supposing an individual moves entirely from one place to another (ISP,
job, everything), they would simply cary their secrets with them and
then broadcast their new secret (or the old one) with their new address
to all of their other group members. This would allow the group members
to send messages back to them. With some simple protocols this entire
process could be automated.

For example, the moving group member caries with them their collection
of secrets. The secrets allow them to send message to their peers in the
circle of trust. When the moving member reaches their location, they
broadcast their old secret and email address along with a request for
change/addition which includes their new secret and email address. Other
members in the group receiving this request (as authorized by the
correct use of the shared secret) can then update their address books
(or server provided services and directory systems) with the new data.
As a result they are now able to communicate with the moved member
without any problems and without intervention.

... This mechanism cannot be abused because broadcasting this request
only updates the members secrets so that they may, if they wish, send
messages to you. The automation does not provide a mechanism for a third
party to open access to the group... only a member of the group can do
that.... and, if that member abuses that privelege then it is easy for
the group to expell that member from the Circle Of Trust and silence
them...

In general this mechanism can be deployed in phases so that it can easly
support a mix of early adopters and eventually defacto standards for
automation...

It can start as a client side solution by convention only.
At the next level there may be automation in the MUA.
At the next level the provider may make facilities available at the MDA.
At the next level the provider may aggregate user policies for filtering
at the MTA (This is where real pay-offs start).

The users can effectively manage their own secrets because their groups
are small. A user who is a member of 5 groups would have 5 secrets. Only
members of the group need know the secret (excluding the provider who
would know for the purpose of applying filters).

If extended to subscription services, each subscriber record would have
a single additional field containing that user's secret - not much more
difficult than storing their email address and any other data they may
need.

This mechanism is only one part of a more comprehensive solution, but if
it were pushed to it's limits then the proliferation of secrets would
not be a problem because the workload is naturally distributed among the
users with each replicating and managing only those secrets they need. A
few simple protocols can coordinate any automation between these users
and the messages for that purpose could easily be transmitted in-band.

One way of looking at this is that the available computing and human
resource scales almost linearly with the complexity of the system. In
general you would have some number of secrets equal to or less than the
number of email addresses you correspond with because collections of
email addresses (a group) would normally be associated with a single
shared secret. This only changes when an email address belongs to more
than one group if for some reason you need to differentiate your secrets
for that user.

The collective system of individual nodes organizes the complexity
naturally as each node keeps track of it's own context within the whole.

(There are a number of advanced mechanisms that can also be applied
which allow for some third party authentication within a COT but I don't
want to stray into that and dilute the conversation.)

_M

>Sent: Thursday, July 03, 2003 3:53 PM
>To: Madscientist
>Cc: [email-masked]
>Subject: Re: [Asrg] 2. Problem Characterization - Defining 
>spam within consent paradigm
>
>
>>destroyed entirely at the behest of the user groups involved and 
>>require no cost beyond that effort.
>>

---

From: "Madscientist" <[email-masked]>
Date: Thu, 3 Jul 2003 18:10:34 -0400

>From: Tom Thomson [mailto:[email-masked]] 
>Sent: Thursday, July 03, 2003 4:08 PM
>To: Madscientist; [email-masked]
>This is very like a closed use (sender) group where new 
>members can be introduced by any existing member. It is 
>clearly very effective when a CU(S)G is what you want - not 
>quite as effective as insisting all incoming email is 
>encrypted with a key you provide (since sniffing the messages 
>you receive will eventually provide enough data to deduce the 
>consent string) but a lot simpler than that and likely to have 
>far fewer deployment difficulties.
>
>Unfortunately, if a closed user group is not what you want, 
>it's not very helpful because you can never receive mail from 
>a stranger.
>
>The big problem with the consent paradigm is how to define 
>consent in the non-closed case, and what mechanisms can then 
>be used to express it and to police it:  how do I express 
>which mail arriving from a stranger has my consent and which has not?

It is definitely a closed use mechanism.

However, with a few tricks, it can also be extended to provide some
solutions for the anonymous case.

One way this can happen is based on policy exchange. This is a mechanism
by which you may accept certain policy decisions from certain members of
your COT. This provides a generalized mechanism for members to introduce
classes of anonymous users. For example, user a has a policy to accept
messages sourced from sources X, Y, and Z where the sources might be
defined as MTAs, or some combined metric that is easily identifiable
based on "normal" network properties or message headers.

User a and user b are members of a COT and have a reciprocal agreement
to accept "white-list" policies. An anonymous user from system X sends a
message to user b (who does not have a policy for system X at this
time). User b requests a validation of the new sender from user a (or
some other peer it the COT). User a (more specifically their agent)
returns a rating of the sending system X indicating that X should be
white listed. User b (the agent) accepts the policy and makes it local,
then accepts the message.

In a closed group system, some set of policies defining other mechanisms
will have to be in place to allow for the anonymous case. With the above
extension the work load of establishing and maintaining policies can be
dramatically diminished because that work is distributed across the
entire user base.

In this way the COT mechanism at work in the closed group system can
naturally extend to leverage policy decisions on a wide range of
systems. Work that we've been doing with Message Sniffer suggests
strongly that the majority of policy decisions are identical across wide
groups of users. This would allow for a collective black list and white
list to stabilize and act as a basis for a common policy.

Groups or users with different policies can map local exceptions to the
common group to manage the next largest group of policy decisions. The
smallest group of policy decisions which are entirely unique for small
groups or individual users can then be managed very closely to the MUA
or at the MDA level.

In practice the anonymous policies for a particular user would be
aggregated by the provider into a common policy for a group of users
based on the similarities of their local policies. Differences between
individual users and their assigned policy group would be mapped as
exceptions.

In the same way, super groups of policies might be established out of
smaller groups, and ultimately a master policy for the provider would be
aggregated from those. The number of levels in this network of policy
groups would be determined by the resources assigned by the provider. 

It is also important to note that the organization of the policy
aggregation system can be entirely separate from the organization of the
network of closed groups. This allows providers to implement any scale
of policy aggregation from none, to a broad collaborative network, and
allows the deployment of this "service" to be driven by market forces.

For the ISP, providing this service is a value added benefit and so is
likely to gain market share for them as their users will experience
better protection from abuse with less work. In addition, by applying
aggregated white/black list policies at their border MTAs they can save
significant resources. In very large providers where there are likely to
be a broad number of policies, intermediate MTAs or MDAs could process
individual policies for specific groups of users who's local policies
are close to those groups. This further reduces the service costs of the
provider since the message traffic naturally flows toward systems
serving users who wish to receive the traffic and is naturally blocked
from the others (reducing infrastructure costs).

A sufficiently advanced system might also implement a mechanism to
internally migrate a user's connection point to the appropriate MDA(s)
based on their policy proximity.

A further refinement (which we recommend) is for providers (or segments
within large providers or organizations) to establish COT groups to
share policies and abuse statistics (based on attempted violations to
those policies). With this mechanism, ISPs with similar policies could
divide the work of detecting abuse, and aggregate the work of rejecting
abuse. This moves quickly beyond spam to wit: ISP c and ISP d have an
established COT between them and have local policies which accept threat
rejection policies from eachother. ISP c begins to see worm delivery
attempts from external network q and establishes a policy to block that
network at the gateway routers until the abuse subsides. Since this is a
threat detection ISP c broadcast the new policy to the members of it's
COT and those with accpetance policies implement the same policy,
effectively disconnecting network q from their segment of the Internet.
ISP d is protected from the threat even before they have seen the first
arrival of the malware as are all other ISPs in that COT with similar
policies.

COT policies based on this model can be managed automatically and
securely through fairly simple rules governing cellular automata, with
local automata controlled by local hard policies and driven by the
effects of aggregated policies which in turn are driven by end user
policies.

---

Attacks to this system are rejected by collaborative detection and
collective action. If a member of a COT abuses the policies of a peer
then that peer will "distrust" the member and reject them as a matter of
local policy. Other members of the COT _may_ decide to automatically
reject the abuser, or may trigger that decision based on some threshold
of reports from peers in the COT... but in the end, the abuser is
rejected by the COT so that abuse is rejected. This prevents any
attempts to poison the groups policies since membership is driven by
consensus and radical differences from that consensus mean rejection
from the group. Ultimately the decision to accept or reject a member
from a COT is determined by the local policies of the members and the
proximity of the individual's policies to those of the other members in
the group.

The dynamic effects of an open COT model like this are that member
systems will naturally aggregate in COTs that have like policies, and
that changes in local policies will force changes in memebership thus
reducing or eliminating the opportunity for abuse, and consistently
driving toward an organization where the broadest leverage of common
policies can be achieved.

Since the model has no central governing agency the deployment of the
model can be driven by it's effectiveness alone, and the potential for
abuse by the agency, or abuse of the agency as an attack on the system
is eliminated.

Since the system provides a significant net savings in bandwidth and
services costs there should be no need to address economic models or
increase the costs of access to the network. We can continue to have a
Internet where the cost of access maintains parity with the cost of the
infrastructure so that it can remain widely available and "almost free".

Once wide deployment of this system is adopted the concept of spam would
likely be eliminated since there would be very few systems available to
that form of abuse... The amount of spam that did continue would be
isolated and minimized so that it's effects would not be generally
important.

Intermediate levels of deployment provide strongly accellerated
performance as participation levels increase.

There is also a strong benefit to this model in that the end user is
ultimately in control of the content they receive. To the extent allowed
by the provider's local policies, each user could receive their own mix
of anonymous messages based on their own policies and the mechanisms
available to them. The architecture itself does not establish any
limitations beyond those imposed by the available participants and
service capabilities.

There is also no strict definition of the mechanisms driving these
policies. This means that the system can adapt as new mechanisms are
devised, and that it can be implemented with the tools that are
currently available.

A typical policy using current technologies would contain a combination
of black list entries, white list entries, and heuristics which make use
of other mechanisms such as virus detection engines, RBLs, content
filters, abuse statistics as posted by peers in the COT, and adoption
policies regarding peer policy recommendations.

I realize that now I've essentially written a paper on this (with some
missing details). Sorry for the length.

_M