Design Patterns for Identity Systems

These are design patterns in the Christopher Alexander sense rather than the object oriented design sense: they address the physical and network environment rather than focusing on software abstractions. The patterns were introduced in my book Authentication.

There are four patterns: local, direct, indirect, and off-line.

Continue reading Design Patterns for Identity Systems

A Simple CPU Demonstration

Simple CPUCPU = Central Processing Unit

The CPU is the working part of the computer.

It runs your programs, makes changes to the contents of memory, and sends data to peripheral devices.

Thus, it causes the computer to produce the results you want.

The Simple CPU demonstrates how a computer works: what some very simple computer instructions look like and how they are combined to perform a calculation.

Continue reading A Simple CPU Demonstration

Fixing the Insider Threat: Separation of Duty

The insider threat isn’t easy to fix. We can fix it with Separation of Duty, but it requires planning ahead, discipline, and effort. But it’s essentially why banks can hire low-wage tellers and not worry about theft at the till (or at least not as much).

San Francisco lost control of their FiberWAN. It’s not clear how much this affected day to day operations, since the city appeared to still be working. And that in itself is a tribute to separation of duty.

Continue reading Fixing the Insider Threat: Separation of Duty

Files using Classic FORTH

(circa 1970-85, maybe later)

The Forth programming system was developed in the late 1960s by Chuck Moore. It provided a very powerful, text based mechanism for controlling a computer and writing programs when RAM and hard drive space were extremely tight. Early implementations were routinely restricted to 8KB of RAM. Some early implementations relied exclusively on diskette drives that stored less than a half a megabyte of data.

Starting in the 1970s, typical Forth systems treated hard drives as consisting of a linear set of numbered blocks, each 1KB in size. The first block on the drive (block 0) contained the bootstrap program to get Forth started, and a small number of subsequent blocks might also contain binary executable code that was loaded into RAM when Forth started.

Following the blocks of executable code, the remaining hard drive blocks generally contained ASCII text and were referred to by number. If a programmer needed to modify part of a Forth program, he would edit the hard drive block that contained that program, and refer to the block by its number.

Here is an assessment of Forth’s file system in the context of the eight concepts noted above:

  • File storage – each file was essentially of a fixed, 1KB size. Other measures had to be used to link multiple blocks together into longer sequences of data.
  • Locating files – files were referred to by block number, and the number had to be remembered by the programmers.
  • Free space management – programmers had to remember what blocks had not been used, or which blocks contained obsolete text that could be erased so the block could be reused.
  • Easy to implement – Yes, yes, yes!
  • Speed – Very fast at the hardware level, since no hard drive searching had to take place
  • Direct vs. sequential – supported both
  • Storage sizes – no built-in limit, but this obviously became impractical as drives increased dramatically in size
  • Robustness – there is little on-disk structure to destroy, so the robustness becomes a social issue having to do with the reliabilty of the people using the system: will they forget, or resign, or otherwise be unavailable? Can others fill in the gaps left by missing people? Will the hard drive get too big for humans to keep track of its contents without a more conventional file system?