----- Forwarded message from Keith Lofstrom <[email protected]> -----

Date: Wed, 9 Jul 2014 11:43:47 -0700
From: Keith Lofstrom <[email protected]>
To: Server Sky - Internet and Computing in Orbit <[email protected]>
Subject: [Server-sky] Server sky and social architecture
Message-ID: <[email protected]>
User-Agent: Mutt/1.4.2.2i
Reply-To: [email protected]

Inspired by a brief conversation with Cory Doctorow at his
presentation 2014 July 8, Tuesday:

http://server-sky.com/CodeLawHardware

Keith

-- 
Keith Lofstrom          [email protected]
_______________________________________________
Server-sky mailing list
[email protected]
http://lists.server-sky.com/mailman/listinfo/server-sky

----- End forwarded message -----

Code is Law, Hardware is Code's Language

CodeLawHardware


The Law of Law is language. If your language is richly metaphorical and 
contains the word "schadenfreude", you will annex the Sudetenland, gas most of 
your ethnic minorities, and a surviving ethnic outlier will use your language 
to express general relativity. Other languages better express other crimes and 
concepts. A linguist will tell you all languages can express all concepts - 
languages are Turing complete - but this fashionable conceit does not tell us 
why different cultures do different things.

Code is law. Hardware is the language and law of code. Code can only do what 
hardware permits. A Turing complete machine can manufacture any set of symbols 
from any other set, but those symbols cannot go where the hardware doesn't 
connect.

In 1990 I designed a chip, a non-blocking crossbar routing device, for the 
startup I-Cube Design Systems. This chip routed signals from any pin to any 
other pin, and could route 240 inputs to any combination of 240 other outputs. 
But it also had fanout - it could route an input to two or more outputs. 160 
inputs could become 320 outputs. This was useful for the original task - 
hardware logic simulation. When the original logic simulator customers became 
enmired in patent lawsuits, I-Cube found a new customer, another small startup 
called Cisco. Cisco's routers distributed the backbone of the early internet, 
and still route most of it.

I realize, decades later, that I made one of the architectural decisions that 
allows the NSA to watch you as you read this webpage.

Cisco's routers flowed bitstreams, not "packets", a software metaphor for a 
time-bounded sequence of bits. Packet headers told the router which flow got 
the bits, the router told the crossbar device which path the bits should take. 
Sending the bits to more than one place was implicit in how the hardware 
worked, because the hardware had fanout.

Cisco remains, I-Cube was killed by incompetent venture capitalists. I'm not 
party to how Cisco designs routers today, but fanout is implicit in dataflow, 
hardware can stream one transmitter to multiple receivers, tracelessly.

Software is merely "judicial opinion" applied to that hardware, and we 
non-electrical macroscopic human beings only have opinions, not sure knowledge, 
about how the bits are actually moving and transforming from memory location to 
other (possibly multiple) memory locations.

Software can encrypt - or it can pretend to. Software becomes machine 
instructions via a compiler. Dennis Ritchie taught us that a compiler emits 
machine instructions chosen by the compiler author, who can override the 
decisions of the source code author. The hardware author can override both. The 
hard disk manufacturer decides what firmware bytes go on the boot tracks of 
your hard drive, the disk firmware decides what bytes you actually get to your 
RAM from which disk track, and this firmware is invisible to the machine code 
it dispenses. In an age of Viterbi coding and VLSI disk chips, even a hardware 
logic analyzer may not tell you what's actually on the boot tracks. For sure 
knowledge, you will need your own hardware, either your own replacement disk 
chips or a focused ion beam milling system (FIB) to take apart the disk chips 
and learn what they actually do.

The economics of chip production make it impossibly expensive to give everyone 
a different chip architecture, though you can cheaply individualize every chip 
(another of my inventions, see http://siidtech.com ). If there is a ghost in 
the hardware machine, it is in all the machines, and those versed in VLSI, 
equipped with FIB, can find the ghosts. The individuality can be perfectly 
hidden, and cannot be unmasked without destroying the chip.

Puzzling out a proprietary design is possible but time-consuming, perhaps 
costing as much as the original design. Verifying that an open source hardware 
design is faithfully replicated in silicon is relatively easy, and could be 
automated, perhaps as cheap as sequencing a genome. We do not do so, because 
software designers pretend the substrate does not exist, or is logically 
identical to all other substrates, and thus not worth controlling or verifying 
(doctors and pharmaceutical companies share the same pretense).

Open source hardware can also encrypt, and properly-designed hardware can 
encrypt without fanout (no feasible side channel attacks). If we choose, we can 
build individual hardware that encrypts each keystroke and decrypts it at each 
screen, whether the path between is centimeters or megameters. With proper 
hardware, you can still use Gmail for your mail host, but your messages are 
gibberish to Google, and to whoever they share the messages with. Google banner 
ads can be ignored by your decrypter. Google would starve, so they want to make 
your software and hardware "for free", protecting their product (which is you).

Hardware geeks will still need to re-examine (identical) copies of the hardware 
from time to time, to make sure the hardware matches specification, and crypto 
geeks will need to frequently re-examine the specification to make sure it is 
mathematically correct. And sometimes the hardware will be invalid, and we will 
need to replace it with new hardware. But a billion transistors costs pennies 
from Intel, which Amazon can get to you overnight.


Why this matters to Server Sky

Server sky will use far fewer routers. Access to server sky arrays will be 
trigonometric, agile antenna pointing, not packet routing via DNS and border 
gateway protocol; if the array is above the horizon and has what you want, you 
can talk to it directly without intermediaries, and your conversation can be 
encrypted end-to-end. Of course, each end can have fanout, with either the 
orbiting array or your ground terminal copying your conversation to your 
Designated Overlord. Each end can have a fanout of zero, censorship applied by 
that same (or different) Designated Overlord. No man-in-the-middle attacks when 
there is only vacuum and Maxwell's equations between sender and receiver. 
Orbital mechanics, Doppler shift, and twelve-nines-accurate shared clocks 
provide link authentication that cannot be spoofed without reshaping space-time.

There will be Designated Overlords - in the US, we call the overlords "Google" 
and "Hollywood", in China the overlords are the Communist Party and/or the 
People's Liberation Army. People can't seem to live without chains, sigh. But 
we must design our hardware so the overlords are explicit in the design, few in 
number, and subject to organized social opinion (which may be more true for 
China than the US, though I love Google more than the PLA).

This matters because the Server Sky team will make the design decisions now 
that will shape the hardware for decades, until the next big re-architecting 
(the last two were the Bell network, and internet protocol). These decisions 
should be informed by every capable brain on the planet. They should not be 
made by me, nor by my handful of smart but fallible collaborators. The best 
minds work elsewhere, and the best minds, if they know what's good for them, 
will get involved while the future is still conceptual and easy to shape. After 
launch, we can still replace all the satellites and all the ground terminals 
and all the end-user gear, but this is costly, and even the best minds don't 
have the money and persuasiveness to make this happen often. Better to get it 
approximately right the first time, and make it plug-upgradable.

This webpage is an appeal for help. Bad social design is easy, and regrettably 
common. Hardware is easy compared to competent social design. I beg you to help 
design the future you and your descendants will live in. I goofed up once, I 
would rather not do it again.

Reply via email to