« September 2006 | Main | November 2006 »

October 30, 2006

Infoworld Jumpstart your SOA with ESB... ?

Infoworld just sent me an email advising me to "Jumpstart your SOA with ESB".


Why the need to speak in code? Have people suddenly found computer networking too easy to understand?


Jargon is a bad habit that most of us suffer from in the information technology sector. Some people say that the problem with jargon is that it encourages sloppy thinking. I disagree, the problem with jargon is that it encourages people not to think at all. Ideas that should be clear become muddy.


I like the term Web Services because it is reasonably descriptive of the idea it is intended to describe. I like the term Mashup for the same reason. When did we start talking about SOAs?


The reason I dislike the technology talk is that we are distracting ourselves from what should really matter to us: the business processes that all these TLAs are purported to serve. If we look at the technology the choices are inocherent, changing rapidly. If we look at the business problems we find clarity.

October 25, 2006

CEI: Are cyber-vigilantes the answer?

The Competative Enterprise Institute asks if allowing vigilantes to go after hackers is the anser to Internet crime and in particular file sharing. Their report is well worth reading.


The arguments usually advanced in favor of cyber-vigilantes are essentially the same ones made by traditional vigilantes. Predictably then the arguments against cyber-vigilantes are remarkably similar as is the conclusion that individuals should not take the law into their own hands.


Internet crime is at root a problem caused by people, not technology. If people were perfect there would be no crime at all. Vigilantes are also people and therefore imperfect. Vigilantes only publicise their successes, their mistakes and their consequences are conveniently forgotten. It is easy in the movies, Charles Bronsen never hits an innocent bystander in the Death Wish series, however many police department rules Dirty Harry might break we know that he would never commit a crime himself. lawless law enforcement has real consequences in real life.


The Internet infrastructure is closely coupled and interdependent. An attack against one target is almost certain to affect many others. If the law allows exceptions for vigilante action it may become impossible to convict the genuine criminal. It is routine for a hacker to claim that they were targeting pedophile rings or terrorists. Sven Jaschan, convicted of authoring the Sasser worm attempted to claim that his objective was to rid victims machines of other malware, a claim that might have been more credible if the code had not carried a malicious payload that shuts down an infected machine at random.


Ultimately the problem with vigilantes is accountability. When people take the law into their own hands and refuse to be held accountable for their mistakes they are to all intents and purposes criminals themselves.

October 23, 2006

EKR writes about the politics of standardizing shipping containers.


His punchline:

Remember, this is a rectangular metal box with fittings at the corners. What makes standards-setting complicated isn't primarily that the technical issues are difficult--though they certainly can be--but that they require coordination between multiple players who often have radically different incentives.


I would go a stage further. The simplicity of the problem is what allowed the solution to be so complex. Anyone can have an opinion about a rectangular box with fittings at each corner. The number of degrees of freedom is huge. Its not just the size that can vary, its the weight and the number that can be stacked on top of each other and so on and so on.


Fortunately the number of people who have an opinion on cryptographic security protocols is rather smaller. We tend to suffer from the opposite problem, in many cases the problems we are trying to solve are over constrained. It is not always possible to do what we want to do and maintain compatibility with the past.


This is why I beleive that the dual track strategies adopted in many recent standards initiatives are the correct approach. Email authentication has adopted a two track approach: SPF/SenderiID to provide a fast route to market, DKIM to provide solid cryptographic authentication. A similar pattern is emerging in the case of federated identity" OpenID provides an infrastructure that is backwards compatible, CardSpace asks 'what if we start from a blank sheet of paper and decide to go for total security and total usability as goals'?


Commentators frequently misread these divergent approaches as repeats of the standards wars of the 1990s. The difference is that in the past the parallel efforts tried to work out how to leave a scorched earth for the alternative proposal, today we look for ways in which to re-integrate in the future.

October 16, 2006

Shakespere on Trusted Computing

Glendower. I can call spirits from the vasty deep.
Hotspur. Why, so can I, or so can any man. But will they come when you do call for them?


Every so often I am asked about Trusted Computing as if it was a new idea. On the contrary we have trusted computing today. The problem is that what is Trusted is not Trustworthy. As Hotspur would put it, anyone can make a computer trusted by simply deciding to trust it, the problem is knowing if that trust is well placed or not.


There is a tendency to dismiss the difference as marketting speak. In fact the difference is a core security concern. Security is risk management, not elimination of risk. The term 'trusted' implies a binary condition. The term Trustworthy reminds us that we should always remember to ask for what purpose?


Trustworthy hardware addresses one part of the computer security puzzle - preventing compromise of the operating system platform. That is an important goal and one that will become increasingly important as vendors gradually wring the security bugs out of the critical execution parths in the upper operating system layers. But merely adding a TPM chip does not make the user of the computer invulnerable to attack.

October 01, 2006

The exactly right tool

The maple trees surrounding the house are starting to shed their leaves. Unless the gutters get cleaned each year they quickly get clogged. The house is a Dutch colonial so the roof comes down to the first floor even though the house has three stories.

Cleaning the gutters with a purported gutter cleaning wand for the hose the last two years took me the best part of a day which is to say the actual work took me three hours and investigating the multiple design failures in the gutter attachment took the same again. Whoever designed the thing did not consider the fact that forcing water into a narrow jet creates a huge amount of pressure. Each year the same pattern: multiple minor failures followed by the wand breaking completely because the glue holding the parts of the shaft together are simply not strong enough. Eventually I have to climb up on a ladder and empty the gutters by hand.

This year I tried something different, an attachment to the shop-vac blower port. I saw one demonstrated on This Old House a few years back but had never seen one in a store. Reviews on the Web were uniformly positive. After some effort I found a shop that had a kit in stock.

To make a long story short $19.95 plus tax is rather a lot for four pieces of plastic tube but a small price to pay for cleaning out the whole gutter in less than five minutes. Using a jet of water to clear a clogged drain is a loosing proposition in every way imaginable even before the wand breaks. The failure of water to clear the clog is the reason the gutters need cleaning in the first place. Using a jet of air just works, as soon as the blower is turned on the debris is blasted out of and far away from the gutter.

Technology often works this way. A technology that is 95% right is nowhere near as effective as one that is 100% right. The idea of blasting the leaves out of the gutter with a jet of fluid is right, the 5% change that makes the critical difference is that the fluid must be gas (i.e. air) rather than a liquid (water).

Today the architecture of the Internet Security infrastructure is 95% right: it delivers a very high degree of security for the people who understand how to use it, the problem is that the Internet user of 2005 is not the same as the Internet user of 1995 when the systems were being developed.

Fixing the problem does not mean that we should tear everything down and start from scratch, doing so would merely create another 95% successful solution. Instead we need to focus on the reasons people are not using the security systems that exist and redesign those systems so that they deliver security in ways that are useful to the typical Internet user of 2006 and beyond.