Comments on this.
Back then, the big concern was that hardware had advanced faster than our ability to produce software for it. Bigger, faster computers and all that.
A minor quibble.
That there were computers at all in the 50’s so greatly exploded the “adjacent possible” that programmers would have proliferated even if the computers had not since improved by 6 orders of magnitude.
With that and a like decrease in cost we have a revolution that is only beginning to come into focus.
We ain’t seen nothin yet.
On the other hand Chip’s text should be tuned for strategic impact in his note.
Why shouldn’t you be able to visit a random web site, click on a link in a strange email, or for that matter run any damn executable you happen to stumble across?
Why should anything bad happen if you do those things?
The solutions have been known since at least the mid ’70s, but it’s a struggle to get security and software professionals to pay attention.
Perhaps I am wrong but I think that the answer has always been of the form: “but if we make ‘auto-run’ the default then there are these cases where the user needs one less click.”
This is dumb and not from programmers but from someone with an implicit theory of what is happening in the user’s head.
They hope the user will stumble onto the right action and removing steps is of infinite value.
One of the reasons things are so bad is that the core infrastructure that we rely on — programming languages, operating systems, network protocols — predates our current need for software to actually not be crap.
Well said.
The engineers were mostly of the mind that all of the code in sight is devoted to doing the right thing.
Only occasionally would they check to see if the incoming message was according to specs.
Most of those checks were to avoid innocent errors introduced by the telco.
ITS was proud of the fact that they did not have passwords.
Anyway, we now have a giant installed base and replacing it is a boil the ocean problem.
Well I have a proposal for less than the whole ocean.
I see a three pronged strategy:
I have a forth, somewhat orthogonal thrust.
Mark advocates an incremental, top down approach: deliver an environment that supports creating and running defensively consistent application code, one that we can ensure will be secure and reliable as long as the underlying computational substrate (initially, a web browser) hasn’t itself been compromised in some way.
I want to meet Mark on the way up, and get some early returns in the meantime.