Schneier on Security

Clive Robinson • February 7, 2017 10:31 PM

@ Anura, Dirk Praet, Nick P,

Oh I forgot to mention the “herding cats” issue of trying to get a bunch of programs written by different people that are only loosely aligned to work together.

To see what it involves you need to look back in time, when Apple and Sun were the kings of graphical desktops and MicroSoft had not got into let alone left the graphics starting gate and was staring moodily into GEMs for inspiration.

A tiny organisation called NeXT was being talked about and Apple thought up it’s colour card projects of which the “Pink Project” offered much. It was to be Object Oriented but the objects were to be independent and cooperative alowing you to select the parts you wanted to use and develop your own.

I was a “working stiff” back then looking to climb out of the coffin like box the PC world was in, towards the joy that was NeXT Step. Pink looked like an answer a potential shining path to walk into the bright light of day…

Yup was I ever deluded :$

You can read a bit of the history,

http://www.roughlydrafted.com/RD/Q4.06/36A61A87-064B-470D-8870-736DD59CEF48.html

These days Apples Pink Project is not famed for it’s vision but given as the prime example of a software managment “Death March”… A clasic example of the “Corporate immune response” in any existing company it was viewed as a bitter rival not a step to the future.

We have seen this repeated over and over, the aspiration of a rising tide to an open future, draged down by turf wars and infighting. It also happens in the FOSS communities, where standards are seen as a burden on inspirational development. With the ever present truism of “Standards are like toothbrushes, every one agrees you need one, but nobody want’s to use anyone elses.”.

Clive Robinson • February 8, 2017 4:59 AM

@ Thoth,

I guess we can continue to bang on about proper assured codes, stress testing, modelling and all the techniques to bring security assurance higher but I guess few ever bothers and even find our work laughable.

Then as the history of this blog shows they will steal our ideas without credit.

As in many things timing is key. A few can see further into the future, not by some luck of genetics but by solid experience. To see a likely occurance, problem or solution ahead of the pack when the majority are fighting over yesterdays scraps is often a curse. Because others do not want to get out of the frey or even put their heads up to see what is comming, they instead want to drag you back to their way, where they think they have the advantage.

As I’ve mentioned before as have others, people you work with steal from you, the ridicule etc is an easy way to distract others. I’ve actually had to see an idea I had fully worked out be given to another and been told to assist them doing the development and correct them when they were wrong. Then get told to do all the work on getting the patent arguing with the assesors and getting it through. Was my name on the patent? As they say “Don’t be silly” such is politics in companies. Then you see the patent used to tie up a market sector, which closes down your employment options. It is not a good feeling either, which is why I put my ideas out for free. It atleast gives some prior art, which means it does not close down the employment and other options.

Yes I know, some will see me as being selfish –I’ve actually been told that in the past– but then their ideas on the common good is to “Rent Seek off of others work” so their view is shall we say a little self centered at best.

I’ve found the best thing to do is “publish and not be dammed to fight fight fight” because you don’t waste your time with worthless people and their pointless political infighting. I guess I’m by no means the first as the prose poem “Desiderata” (by American writer Max Ehrmann in 1927) suggests avoiding such people,

https://en.m.wikipedia.org/wiki/Desiderata

Though from the above, you will see that the poem became subject to that which it advised against. Such apparently is the way of life.

Clive Robinson • February 9, 2017 3:47 AM

@ Figureitout,

That was your advice a few years ago, remember that? Fail long and hard on errors.

That was advice about reducing covert channels in an information communications –not storage or processing– system.

The advice was specifically about “aborting a transmission and re-sending at a later point in time”. This was to be done at the instrumented choke points in a compartmentalized secure high reliability system.

Importantly to do the fail hard and long, then resend means it is clearly a “store and forward” system so data would not be lost. Which is the key point to note.

Most code cutters however develop code for an information processing system which then might feed a storage system.

The code cutter usuall assumption is down stream is reliable, that is they feed a “reliable” data sink, which does not have errors or exceptions. They also assume that all checking of data is done before processing, thus have no way to deal with processing errors or exceptions. Thus they do not even attempt a way to hand data back to the data source. As this occures at each stage in a pipeline there is the issue of each stage storing a data object which means that on fail the number of data objects lost is the same as the number of stages in the pipeline…

There are known ways of dealing with these problems which you see implemented in communications systems and occasionaly and imperfectly in storage systems. But I’ve yet to see them used effectively in “information processing” systems.

The simplest example that most will be familiar with is “auto-save” in editors. In modern editors they are generaly far from perfect and you can lose 10-60minutes of work. Nor are they anywhere as good as they used to be when storage and communications systems were less reliable.

I’ve mentioned these problems in the past and will no doubt be mentioning them for the foreseeable future. Because the general case is that for errors or exceptions the coding time spent on them is proportional to their likelyhood of happening, not the effect of what happens when they do.

Look at it this way, if your editor crashes out once in a blue moon, if you lose a few keypresses then it’s an anoyance. But if the underlying –say networked– file system crashes about the same rate and wipes out your PhD thesis then you are going to be some what more put out. Older style editor designers were aware of the unreliability of the file store thus they used to copy the file onto disk first, then would update the copy. Thus if either the editor or the network file system crashed out the original work would be safe.

More modern systems being considerably more reliable, the code cutters / designers tend not to build in the same level of data protection, thus whilst problems are less frequent, the harms are considerably greater when they do happen.

Now before people try to bite my head off and jump down my throat, I’m aware that a large part of the problem is shortening project time scales. But a very real part of that is the need for defensive programing is not getting passed on to successive generations of programmers. Worse where it is mentioned the attitude is that such defensive measures are a waste of coding time as the events they protect against “just don’t happen any more”. So the easy win on project time scale is to cut defensive coding that surounds errors and exceptions. It’s a more insidious problem than the notion of “input data is clean” because “it’s been checked upstream”, which as we know has given rise to the abundantly fruitfull hunting ground of “attack vectors” that “little bobby tables” is joked about.

Clive Robinson • February 10, 2017 1:56 AM

@ ,

No it was not that phrase I was refering to.

Charles Babage –supposed– inventor of the computer hated Organ Grinders, who would play outside his house disturbing his peace. A war broke out between him and them and they won in the short term by congregating in groups outside his house at all hour’s of the day to make his life even more unbearable. In the longterm he won by act of Parliament, though the grinders got revenge on his final days as he lay dying.

He was known to have made comments about them involving a comparison between the monkey and the grinders respective intelligences, or lack there of in the case of the grinders.

https://www.newscientist.com/article/mg17924085-100-blasts-from-the-past-mr-babbage-and-the-buskers