Schneier on Security

Clive Robinson • February 12, 2023 2:51 AM

@ Ismar, ALL,

“Taking advantage of system’s imperfections”

Whilst correct, does not quite cover it…

Consider the question,

“When is an imperfection, not an imperfection but a consideration or similar?”

There are many times as a designer I’ve had to make trade offs.

For instance the lighter I make a design the less impact energy it has on impact with the ground after being dropped from say 2m. Which means I can make the case thinner thus lighter and you get into a kind of spiral where although the case will survive being used it won’t be strong enough to survive a touch screen “firm” finger press in cold weather because a user has a glove on and does not realise that it stops the touch screen from working.

Which is the “imperfection” if any, the thinner case, the touchscreen or both?

Designers go through these sorts of thought processes every day so hundreds of times in any modetately complex or above design such as anything containing electronics or small or relatively small moving parts.

It sometimes leads to what appears to be very strange design choices.

For instance few actually know these days that there was no distinction between hard drives and floppy drives early on they were all in effect removable storage and hard drives due to IBM and others design teams. That is the “platter” that was coated with magnetic material was made of metal like aluminium and structurally self supporting, even though “magnetic tape” removable storage preceded disks floppy drives were much later in the game.

But… These days the platters in hard drives are made of what most would consider very fragile thin glass… As one designer put it,

“When you thin down aluminium enough you get ‘Bacofoil’, thin glass gives you fiber glass stronger than steel”.

At some point there was a “transition zone” where neither material had clear advantages over the other.

This is true in some way for all things you have transition zones and it is here that the playground of hacking be it good or bad exists.

The laws of nature demand such transition zones from all physical objects, you can see them in the plotted graphs. And we try to hide the curves from our thinking with piecewise curve fitting of straight lines. The reality is that very few things in nature follow straight lines in anyway, and we even find that impossibly awkward exponential cure lurking beneath even the turning of a wheel.

Information objects are no different than physical objects in this respect, they too have their own “laws of nature” –that in some cases we are only just discovering– they to are curves on a graph we try and often fail to linearize by piecewise curve fitting…

So the penultimate question is,

“Are the imperfections in us or the objects?”

From which the “ultimate question” is yet to arise.

Clive Robinson • February 12, 2023 6:17 PM

@ Ballermann3000,

“My definition of hacking would be to make use of something for a purpose it is not designed for.”

That is only a part of it.

Originally a “hack” was an improvment, which could mean new functionality, or making existing functionality somehow better like automating process steps or making the steps use less resources or more efficiently.

“Also there is this weird machine interpretation where your system has an intended part and an unintended part, the weird machine”

Ultimately all computers are “state machines” with few people actually understanding the implications of this.

Thus mostly programmers write programs where only very few of the many many states are considered in the “business logic” let alone the rest of the program.

A state machine has two basic actions,

1, Not change state.
2, Change state based on current state and input.

It can thus be “halted” or changing state. The changes of state can be,

1, Without loopback.
2, With loopback.

The first is a chain where no state is returned to that must by definition at some point run out of states and halt.

The second has the potential to loop endlessly thus not halt. Deciding which is going to happen is in some cases either not possible, or only possible by exhaustion. In essence this is what the Church-Turing results on the “Halting problem” proved.

What you describe as a “weird machine” is caused by incorrect implementation of state transition, such that execution can get into states that were either not implemented or implemented for a different purpose incorrectly.

The thing about state machines is that you can design them in a way where the states are correctly controled with only minor changes in the way a programmer writes programes.

One method is by using “design by contract” correctly and designing the interfaces such that state transition is restricted.

This is not liked as “code re-use” can get hammered, which many managmers find unexceptable even though it gives good code reliability and low maintainance.

Thus any “weird machine” is a “major red flag” about bad design and implementation practices, thus a code shop that should where possible be avoided and at the very least their product strongly mitigated.