The Solution to Spam

I was just reading today on the register about how spammers have defeated the CAPTCHA protection to stop automated registrations with the major email providers.

http://www.theregister.co.uk/2008/03/11/global_spam_trends/

Some time ago it struck me that there may be quite a simple solution to the whole spam issue, in fact I think my current ideas are based on a suggestion by none-other-than Bill Gates(!), who I think suggested having a 'stamp' or small cost associated with sending an email.

The idea is that if you can introduce a cost to sending email, no matter how small, it will deter spammers because when you are sending millions of emails, these costs rapidly add up and make the whole thing unprofitable.

I think this idea is really good, the variation I currently am thinking might be successful (I can't remember whether I read this or just came up with it after Bill's suggestion) is as follows:

Instead of having a fixed cost per-email, have every person creating an email account make a DEPOSIT. That is, a deposit of good faith to indicate that they are not going to use the account for spamming. Now the idea is, when someone receives an email that they regard as spam, they mark it as so, and through 'an undetermined mechanism', the sender loses their deposit.

There are 2 obvious variations here:

1) The deposit is large (say 10 pounds) and the sender loses access to their account on confirmation of spam activity.

2) The deposit is small (say 1 pound) and the sender loses the ability to send mail until they REPLACE the deposit.

The obvious problem is the problem of abuse by the receiver of the message. If they don't like you, or want to play a joke on you, they could classify your mail as spam and e.g. lose you a pound, which is unfair. So in a way you would need an impartial human to vet the reported spam and check it before giving the penalty.

Anything where there are humans involved becomes more costly. BUT WAIT!! If the spammer is losing their deposit, you can actually use this money to pay the checkers!! :)



It has occurred to me you could use a similar system for telephone spam too, if you receive an unwanted call, you simply press your SPAM button on the phone, and the caller loses their deposit.

Of course the issue is that a new email protocol would need to be used in order to prevent spoofing the sender, but if we bear in mind how long the existing system has been used, is it unreasonable to expect a revision, based on the experiences of use over the past 30 years? Any system undergoing widespread use usually shows flaws which can be corrected in a revision to the standard to make it more robust.

There is actually no reason why a new email standard could not be used in parallel to the existing system for a number of years, and if the benefits are significant, the market will adapt to using it.

Music Composer App

As a little side project I've been writing a music composing application. I've been planning to for a few years now, just never got round to it! Actually I've learned a bit more win32 programming since I last did a music app around 10 years ago, so things are coming along quite quickly. Having said that, although I've done a lot of programming I haven't done a lot of windows GUI type coding, partly because lots of flashy user interface stuff doesn't interest me as much as the things going on underneath... so the user interface so far is pretty basic lol! Of course once I have the basics working I can photoshop up some graphics and make it look more flashy.

My aim is to produce something like fruityloops (FL studio) in functionality, but more geared towards composition. In the past I've found many sequencers very annoying because although they tend to be very versatile, and let you program any music, they tend to make it a very tedious process that takes many hours. I instead want a system designed for rapid composing, with lots of helpful tools and systems that are 'composer friendly' instead of being 'tech friendly'.



The other thing I used to find really annoying back in the old days of MIDI and multitrack tapes was the nightmare of getting everything in sync. I completely solve this problem in my app by placing samples / instruments in precisely calculated accuracy, sample accurate so accurate to 1/44100th of a second typically. Of course to get bang on sync, you also need to make sure your samples start on the B of the Bang, so I have tools for simplifying this. The interesting case is for instruments with a slow attack (such as a slow bowed string sound). To get this tight, should you chop off the attack, or start playing the sound BEFORE the 'note start'? Some interesting questions that a human player would do naturally, but a computer needs a plan of action for this type of thing.