Core SIR syntax rules

• Section divisions shall be used - similar to how UUEncode, PGP and many other formats work.
• Support of PGP style signatures to verify that each peer agrees with the SIR petition
• Line numbers in certain sections will be critical for signature creation - so the order data in each section will need to be strictly controlled. No peer can insert data into the middle of a section as it will break prior signatures.
• Each signature will specify the exact lines that were used in the encryption of the signature so subsequent verification is possible. This will also enable signing selective lines to prevent all-or-nothing traps which would inhibit SIR merging.
  

Section 1: Spam Incident Report -

• This top section will in effect serve as a fingerprint. The sample I made has some datum miscategorized here, but you get the idea. It will be predominantly URL based.
  
• NOTE: The client creating the SIR may need to "Click through" using a sanitized URL to see what the real server being advertised is. It would be helpfull if each peer did this to allow administrators to more rapidly identify families of SIR that all advertise the same service via relay servers.

Section 2: Supplemental Data

• Since making the sample, it occurs to me that some text will need to be re-arranged to facilitate signing & incrementing. I'll leave that for the next draft.
• Supplementatl data can contain: Client / Header spam ID information, user generated meta data added by an interactive rating process, and other content that is found to be usefull in downstream decision making but which is not suitable for a fingerprint..

Section 3: Petition Signatures

• Signature section shall allow rapid addition of signatures at the end of the list to reduce processing time to only append actions if possible.
• Signatures shall be based upon a subset of the prior section row entries. Some shall be mandatory (fingerprint data) and some shall be optional (supplemental data). In this way a peer may vouch for selective lines of data to enable subsequent processing of tabulated results.
  

Auditing:

There shall be a protocol to allow down stream random auditing back to the originating peer. For example, an administrator that wishes to confirm 1% of the signatures on a SIR report shall be able to send a compact query to a signing peer which requires a predictable answer to confirm that the signature was indeed originated by that peer and not fraudulently added.I

Prototype SIR

Below is my prototype SIR. If you don't know what this is - I appologize. :)

---BEGIN SPAM INCIDENT REPORT---
##INTEGRITY##
(insert trust scheme here)
##HEADER DATA##
ORIGIN IP: 160.79.32.178
STATED FROM: SANITI...@By-Zeb.com
SENT: Thu, 18 May 2006 17:47:50 -0700 (PDT)
SUBJECT: Free diet patch to help curb cravings
##PLAIN TEXT SUMMARY##
URL: http://www.linknetgrp.com/*TYPEA*/U.HTM ;COUNT=3
PHONE: 5 6 1 2 4 4 5 9 6 2 ;COUNT=1
##HTML SUMMARY##
URL-TEXT: http://www.linknetgrp.com/*TYPEA*/U.HTM ;COUNT=1
URL-LINK: http://www.linknetgrp.com/*TYPEA*/U.HTM ;COUNT=2
URL-LINK: http://www.linknetgrp.com/*TYPEB*/U.HTM ;COUNT=1
URL-LINK: http://www.linknetgrp.com/*TYPEC*/U.HTM ;COUNT=1
URL-IMAGELINK: http://www.linknetgrp.com/*TYPEA*/U.HTM ;COUNT=14
URL-IMAGELINK: http://www.linknetgrp.com/*TYPEC*/U.HTM ;COUNT=1
DOMAIN TOTAL: [23] www.linknetgrp.com
##ATTACHMENT SUMMARY##
ATTACH: NONE
IMAGE SPAM: NO
---END SPAM INCIDENT REPORT---

---BEGIN SUPPLEMENTAL DATA AGGREGATION---
##HEADER & CLIENT##
X-SPAM SUMMARY: [PEERS=2] [AVG.SCORE=7.3] SPAM-ASSASSIN
X-SPAM SUMMARY: [PEERS=1] [AVG.SCORE=9] SPAMO-SCRUBBER2000
X-SPAM SUMMARY: [PEERS=2] NONE
THUNDERBIRD STATUS: [PEERS=3] JUNK
OUTLOOK STATUS: [PEERS=2] JUNK
##SUPPLEMENTAL DATA - HUMAN META##
SPAM CLASS: [PEERS=3] GOODS-SERVICES
SPAM CLASS: [PEERS=1] 419-SCAM
SPAM CLASS: [PEERS=1] NO-VOTE
IMAGE SPAM: NO
VIRUS CONTENT: [PEERS=4] CLEAN
VIRUS CONTENT: [PEERS=1] NO-VOTE
FAMILY SAFE: [PEERS=4] YES
FAMILY SAFE: [PEERS=1] NO-VOTE
RUDENESS: [PEERS=4] 4.5
RUDENESS: [PEERS=1] NO-VOTE
---END SUPPLEMENTAL DATA AGGREGATION---

---BEGIN PETITION AGGREGATION---
SIG COUNT: [PEERS=5]
INITIAL SIGNATURE: ##UNIQUE HASHED ID OF OKOPIPI CLIENT##
PEER MATCH SIGNATURE: ##UNIQUE HASHED ID OF OKOPIPI CLIENT##
PEER MATCH SIGNATURE: ##UNIQUE HASHED ID OF OKOPIPI CLIENT##
PEER MATCH SIGNATURE: ##UNIQUE HASHED ID OF OKOPIPI CLIENT##
PEER MATCH SIGNATURE: ##UNIQUE HASHED ID OF OKOPIPI CLIENT##

(would grow...)
.
.
.
v
(to max size before starting new petition)
---END PETITION AGGREGATION---

Eh.. Had to re-post everything...

Sorry, but ignore the Blogger dates. I re-uploaded everything from my local files, and have put my original post dates in parentheses where required..

**it happens right?

Thoughts on Black Frog P2P

A lot of energetic folks are working up a lather on the Blue Security forums at CastleCops and all over SlashDot. In fact the whole web is a-buzz with Peer to Peer re-engineering of the Blue Frog concept now that it has been proven to work so effectively within the constraints of the law.

I'm 100% behind the idea, however I'm noticing a lot of folks are not paying attention to some key issues. In general people are glossing over everything that Blue Security did in their headquarters and focusing on the little frog client. (Which didn't do much in and of itself.)

In the interest of helping in some small way, following are my collected thoughts on the matter.

The CAN-SPAM legislation: It had no teeth, and it's provisions were vague - even seemingly useless. But it did establish the right to OPT OUT. Our problem under this framework now is that we don't have the technology (yet) to exercise this right to Opt Out in equal measure to the UCE (spam) we receive. At 500 spam per day, I could never match spammer's horsepower alone, but with a little backup from other frogs and an automation tool... Well, the landscape changes. Blue Security proved this.

SO! Spammers have automatic systems to advertise to us. We need automatic systems to opt out. Let us never send more than one Opt-Out for each e-mail received.

To keep everyone straight on this point I suggest a core and direct mission statement should be crafted to keep in mind and rally behind. Print it on mugs and mouse pads. Keep these thoughts in mind.

Proposed mission statement:

"The goal of the Black Frog project is to empower the public with the ability to exercise it's legal right to request removal from Unsolicited Commercial E-mail distribution (UCE). This will be accomplished by creating a tool that will safely and legally automate the Opt-Out process in equal and fair proportion to the methods used by advertisers to send UCE in the first place."

Relating to architecture:

The noble conversations in these forums (and I do think everyone is very noble to take up this cause) seem to be glossing over key parts of the puzzle that Blue Security had built into their servers which were under lock and key. The source code for the little frog client won't get you very far. I'll list the server side strengths which need to be emulated by the proposed P2P system here.

Strength #1: By collecting MILLIONS of e-mail per week, Blue Security could analyze millions of e-mails per week and find the patterns behind the origins of spam as well as what services were being advertised. Since so much spam came from compromised sources, no attempt should be made to touch them - only to identify them and pass along the data to the responsible ISP's and Enforcement agencies. The Blue Frog client has no analytical capabilities. Learning how to do this is what may make Blue Security rich some day.

P2P Challenge #1: Figure out what analysis tools Blue Security used and/or develop them independently. Devise a way to conduct distributed analysis and data aggregation to make Opt-Out decisions and to then feed into reporting tools. If the FBI and others could have access to a real time and reliable source of data on UCE activity as they did while Blue Security was doing it, they would probably be on your side. It would be a Real Time Black List on steroids with IP numbers, statistics on spam generated, sites advertised from that server, illegal penny stock scams, worm distribution sources, compromised bot clients and their ISP's, and on and on.

*** THIS is what scared the excrement out of the spammers and caused them to start a no-holds barred fight. As long as this information is scattered across the web, they are safe. When all this data is collected in one place, it eliminates places for them to hide and will force them to become responsible.

Strength #2: Identification of the companies which stood to profit from this method of advertisement. Where blue security hurt the Spammers next was by registering complaints to the advertised services in a volume that made the advertised company question if they wanted to continue to advertise through the guilty Spammer. What pill seller wants to sift through thousands of opt-out requests searching for one legitimate sale? (If it can be called legitimate..) Each Opt-Out only represented one e-mail and with only 400,000 protected e-mail accounts it was very effective. (Pre-Mayday figures when the BF clients were still cranking away. They never had .5M protected e-mails when the system was still up.)

P2P Challenge #2: Develop method to gobble up local spam and accurately cut through the subterfuge and countermeasures employed by spammers to lodge legal requests for list removal at the advertised service. I see no way this could be done without an oversight committee that scouted ahead of the frogs to determine if the collected data warranted an Opt-Out campaign. To let every P2P client run amok would weaken the project. Someone somewhere needs to stand up and be willing to coordinate this effort and then be attacked when the going gets tough. They will need powerful Google/Microsoft sized friends for the first few years to fend off and counterbalance the criminal syndicates. I am ruling out government assistance because they are generally non-responsive and technologically inept. They have crafted a law for us to work within. It's for us to use it.

Strength #3: Provide a safe and simple means for responsible UCE advertisers to clean users from their lists. Blue security provided a great service with their list cleaning utility. It needs to be that simple for the spammer. Run a program, input the list, proceed with the output list.

*** There is NO WAY around the spammer learning who the users are. Everyone needs to get real with this. Any tool that removes you from an e-mail list will reveal you when the old and new lists are compared. Once the system matures, it may very well turn into a matter of pride to have your e-mail associated with this Frog service, but until then - it needs to be disclaimed up front when using this hypothetical P2P tool that anyone who cares enough can figure out if you are a member through difference testing e-mail lists. But since they already have your address and are spamming you - what do you have to lose? (I personally went from 200 spam per day pre-attack to 500 spam today. There is no difference in my day to day life.)

P2P Challenge #3: Develop a simple way for Spammers to clean their lists. If it isn't REALY easy, nobody will do it. One obvious (but exceedingly difficult thing to code) would be to have each and every client capable of "growing" it's own list of individual e-mail hashes over time via an aggregator option (default off). A simple companion utility could then process this hash list against a text file list of addresses when required. Pro's and Con's of this idea are too many to list here, but I'm just sending ideas up the flag pole.

Strength #4: Trained human intervention. The spammers have all day to play cat and mouse games devising countermeasures to the countermeasures. No automated system can defeat a group of humans devoted to breaking it. Humans need to be involved constantly to provide executive guidance on both Opt-Out campaigns and on software development. I've seen several good ranking / voting schemes to control Opt-Out campaigns. Also people are already talking about things like Captcha countermeasures and other endless improvements. The software tools on both sides of the fence will evolve and he who can't match pace will loose.

P2P Challenge #4: Create a decentralized group of trusted individuals who make the system work and keep it working. Have a public face that can be seen by all, can manage PR and offer a trusted source for information on the system and provide safe downloads for potential customers. (At least while not under DDoS attack.)

Summary:

I dare to say that the little Blue Frog client application was the easy part. The heavy lifting was happening inside of Blue Security Headquarters. If these things can be shifted to a P2P topography effectively, it will work. But money will be -the- limiting factor at some point in this projects evolution.

Benefits of P2P are clear:

During attacks which might take down your main public presence on the web, the distributed system would continue to do it's job indefinitely.

Learning from those who have gone before us:

Blue Frog didn't have P2P technology, it was a central server to many clients arrangement. Despite this one limiation though, it DID have all of the other puzzle pieces in place. We shouldn't underestimate the challenges that lay ahead in emulating what Blue Security got right. The Blue Security client Public License source code is the least of our concerns as a serious software engineering project is involved.

God willing though, perhaps it can be done. Can't be harder than getting to the moon can it?

Blue Frog my buddy, R.I.P.

(Originally Posted 5/17/06)

Well after my short life (3 weeks) as an avid Blue Frog user, Blue Security has announced that it's kicking the bucket. I recorded careful statistics each day - perhaps I'll post them when I get a chance.

I did see it in action, and it worked! My spam was dropping slowly right up to the day the attacks started at which point it jumped from 200 per day to 500. It's now holding stead around 400 and dropping as the attack on us Blue Frog users run out of steam.

But it's wasted effort on behalf of the spammers. We Blue Frog users are the worst kind of anti's and we just cause hell for their affiliates. Spam Assassin is again set to filter (as opposed to only mark headers) and it's pooling server side for admin's to delete when they feel like it. When the odd spam makes it through the hurdles and lands in my inbox (assuming Thunderbird doesn't eat it) I usually take a few minutes to harass the advertised site or forward the phish scam to the bank or service that was spoofed.

So go read all about Blue Security for an exciting story of Cyber Warfare. Having just lived through it all watching each blow in real time, it's too much of a headache to post links. But that's what Google is for. I doubt that links on my humble blog will affect indexing. :)

Does Blue Frog Employ DDoS Attacks?

(Originally Posted 5/7/06)
Some points to consider.

One. When any man woman or child on earth receives an Unsolicited Bulk E-mail message, (UCE) it is essentially just an advertisement:

1a. The recipient has been -invited- to visit the advertised service and conduct business. Real Distributed Denial of Service (DDoS) attacks are never preceded by an -invitation- from the party that is to be allegedly attacked. By sending the advertisement, the advertiser is consenting to receive a response if the recipient feels so inclined. It is advertisers hope that visiting will yield them money. It's called a market economy.

1b. Dissatisfaction is a valid transaction. Advertisers may not just cherry pick the cash yielding sales. If an advertiser does something to insult or enrage their target audience, they can expect to get a lot of phone calls - this is a healthy market dynamic which drives improved business performance and customer satisfaction. If it works for broadcast and print media, why would UCE marketers be immune from this healthy form of feedback?

1c. The recipient of the advertisement is not prohibited by law to conduct business transactions with the advertised service - just as the service is not prohibited by law to advertise. Should the recipient be dissatisfied and not wish to receive future advertisements, a single request for distribution list removal each time an advertisement is received is a valid practice within the law. The advertiser bears some duty to comply with removal requests in good faith. 1 to 1 responses do not constitute a DDoS attack as the sender of the solicitation has direct control of the responses they will receive. No court of law would be convinced otherwise for the following reasons: Intent to disrupt is not present, the objective of the opt-out request is clearly stated in civil terms, the origin of the opt out request is not hidden (though rendered anonymous for practical reasons), no extortion, blackmail or other form of crime is involved in the request, the advertiser has a clear and simple method of avoiding this undesirable traffic and was given due time to conform. None of these conditions are true under a typical real denial of service attack which sets apart the Blue Security method.

1d. Prior to the existence of the Blue Security service, recipients were technically not able to respond in quantity or form equal to the advertisements received. Filtration was the only effective solution to conduct e-commerce and personal correspondence amidst a constant flood of UCE. Historically to respond to a UCE was often dangerous or caused retribution attacks against the unhappy recipient. (The UCE industry refers to vocal negative recipients as "anti’s".) Responding to UCE has now become safe and feasible via the Blue Security system. The underlying method employed by Blue Security whereby "Party A advertises - therefore Party B responds" remains both ethical and legal. Not an attack.

Two. Regarding why the services advertised in UCE might crash or fail as a result of Blue Frog Opt-out requests, there are exactly two possible causes:

2a. The advertising party did not sufficiently design their infrastructure to be capable of managing the traffic which was generated by their ad campaign.

2b. The advertising party did not decrease their ad campaign to be commensurate with their capacity to manage response traffic.

-- The issue of UCE advertised servers crashing has nothing to do with the recipients of the ad campaign or any imagined DDoS attack. It has everything to do with the UCE senders being irresponsible and unprepared for their own actions. In simple terms, it would seem that UCE marketers who target Blue Frog members end up biting off more than they can chew.

Three. Regarding making money from UCE and the irrational nature of Blue Frog resistance:

3a. In the world of business - some traffic generates revenue - some does not. All successful businessmen and women want to maximize one and minimize the other. Blue Frog (BF) users are a demographic group which has the stated goal to never generate sales for bulk e-mailers or their affiliates. Why anyone would ever want to advertise to this vocal advocacy group via bulk e-mail is a true puzzle.

3b. BF users as a community have decided to stop sleep walking when it comes to spam. They feel that endlessly absorbing and filtering the UCE flood solves nothing and is a wasteful use of public and private internet resources. Blue Security has found a way to be vocal and effective while remaining ethical and legal. As with the evolution of all industries around the globe, the UCE industry must evolve with newly developing market forces if they wish to remain profitable. (See point 3a above.) The BF community has become a market force.

3c. BF users are not trying to shut down the UCE industry - this absurd claim to war was initiated by pro-spam forces who were to proud to comply with the BF Do-Not-Disturb registry. Many users outside the BF community -do- respond to UCE and buy product. UCE marketers with any sense should focus on these paying customers as their core demographic audience.

Four. Irresponsible constituents of the Unsolicited Bulk E-mail industry are very worried about Blue Frog because:

4a. The BF service will hold up in any court of law as both legal and ethical. If this weren’t the truth, I believe that in the last year many cases would have already been brought against Blue Security. The advertised illicit drug and fraud rings will not hold up. The irresponsible and punitive marketing practices will not either.

4b. BF does proudly infringe upon their previously unlimited ability to be irresponsible. For those who do not elect to obey the civil opt-out requests – they have the potential of adding cost to the otherwise low overhead industry of sending UCE. Some in this industry are not familiar with having to operate with any type of constraints and simply aren't used to the concept. Change fosters resistance.

4c. BF members are consenting and willing in their use of the service. This is in stark contrast to the hi-jacked criminal zombie networks of the world. The term "bot net" as popularly defined can not be applied to users running the Blue Frog client while actively participating and forwarding their UCE to the Blue Security analysts. This has all the legal markings of consensual usage and legal software licensing.

4d. Should BF member numbers grow too great, the analysts at Blue Security will have vast real time data on the operations of nearly all illicit e-mail driven activity on the web. Nobody has yet succeeded in putting together a system with this much breadth of scope on such a large scale. Blue Security stands a strong chance of being the first. Blue Security has already declared that they will constantly feed their collected data on criminal activity to all relevant authorities and has begun doing this. Having this much light cast upon a shady industry makes those responsible rightfully nervous.

4e. BF members are standing up to irresponsible Spammers. This is a first in history for many of them, and they are having trouble adjusting. In the past, individuals fighting spam could be punished via "Joe Jobs" or placed upon "anti" lists for additional punitive UCE targeting. As a group though, the BF community challenges their safety and has been proven to cause great rage as it nullifies their control over the individual. People in a state of anger do irrational things as recent events have shown. Their recent overtly criminal actions will likely be their undoing.

Five. Anyone still claiming that Blue Security employs illegal DDoS attacks is either:

5a. Not adequately informed regarding what exactly the Blue Frog client actually does and does not do.

5b. Is not in possession of faculties which are capable of sound deductive reasoning.

5c. Is a pro-Spam advocate trying to spread misinformation in a thinly veiled attempt to protect an obsolete way of life.

5d. Simply has a bitter, small heart.

It may sound like the old "if you aren't with us you're against us" bit, but it is not.

-- To those who wish to sit on the bench and watch, you have nothing to lose and everything to gain by allowing Blue Frog members to try this grand experiment in SPAM management. Everyone dislikes SPAM. Everyone agrees that Blue Security is forging into uncharted territory - like it or not. So sit back, see what happens and get yourself some popcorn. Before too long I’m sure the law will test the involved principles and we shall then see which way the wheel turns.

-- To those who are engaged in this experiment, as a person who also does not appreciate thugs entering my in-box, I applaud your bravery and am right there with you.