Internet Evolution — Complexity

I’m posting these here not because they are particularly good (they weren’t) but because I wanted to leave them online after Internet Evolution, the site which originally hosted them, went away.

How Complexity Is Crippling the Internet

Written by David Manheim 1/11/2011

The layering of protocols and the intelligence of the Internet’s users, and attackers, are driving increased complexity.

The idea of having a seven-layer OSI model for networking was great until we realized that we’ve built another half-dozen layers above the session layer — and HTML and the old application layer are being used as a substrate for multilayer systems of their own. And the layers aren’t stable; they interact in complex ways.

The operating systems we use are an example of base complexity on which rests the entirety of our systems. The lines of code supporting the infrastructure of the Internet number in the tens of millions per OS, of which there are many competing versions. The code for each of these has been developed over decades and has been layered in ways that are not clear. Microsoft Corp.(Nasdaq: MSFT) still uses code that was originally in DOS, which was “replaced” by Windows 95, and still hasn’t changed much since then — not since Windows 3.1, 3.0, or possibly even earlier. Do we know what problems exist with that code?

A great example of how code reuse and undiagnosed problems can proliferate is found in the case of Gamma errors in picture scaling. There was a bug in how luminosity was computed for resizing. This was originally a logic bug in how software was implemented, and the color differences were small. The error was copied by almost every major piece of image editing software. It took decades for someone to notice what was wrong. Imagine if something similar happened in a piece of security software: Would anyone notice an extreme case that was included carelessly, or planted maliciously?

Is this surprising? Not really. The question is: How do you know what bugs are getting written into all of our software stacks? When was the last time someone reimplemented the software stack that runs our now-critical infrastructure? Is the TCP/IP stack routinely reimplemented, or is Windows using a very slight variant of what was implemented decades ago? I know that there are dialogue boxes that are essentially unchanged since Windows 3.1, and I would add that in almost every case, no one has rewritten the underlying logic or code; these boxes are still using a version of the same code that was written originally.

Code bases don’t take kindly to removal of code. Software stacks develop badly understood dependencies, which break when parts are replaced or reworked. We haven’t replaced IPv4 yet, originally created in 1981. IPv6 was first standardized more than a decade ago, and 10 years in, the new standard had a less than 1 percent adoption rate. We can’t replace parts that we know limit our existing networks, and we know we need more secure networks. Parts that only compromise network efficiency are even further down the list.

It is unclear how exactly these dependent code bases that exist almost everywhere will be made to work with most changes in complex pieces of code. Testing has grown at speeds exceeding that of the coding itself. According to blogger Larry O’Brien, since Windows 2000, the Microsoft internal testing teams are larger than the development team. Despite this, the code itself is almost unmanageable, and the completeness of testing regimes is approximate at best. We have no idea what will break when we upgrade.

As another possible approach, modularization, already a popular tool, can be utilized more fully. If we can make code bases fully modular, then we only need to worry about requirements changing; when that happens, we are back to the problem of complex dependencies in the code, and kludgy solutions involving compatibility with multiple versions of a protocol.

— David Manheim works as a terrorism insurance modeling specialist at Risk Management Solutions.


Internet Evolution — Name Game

I’m posting these here not because they are particularly good (they weren’t) but because I wanted to leave them online after Internet Evolution, the site which originally hosted them, went away.

The Name Game Moves to the Web

Written by David Manheim 4/28/2011

Addressable space has been an issue with computers since time immemorial. My first computer had expanded, extended, and HMA memory, just so I could use the second DIMM of RAM. We had 2- or 4-gigabyte limits on addressable RAM on 32-bit machines, and FAT16 limits for hard drives that are similar. Hell, IPv6 faces the same issue. We just don’t know how much space we’ll need when designing a system.

But there’s an impending bigger deal, with a less well defined limit: There aren’t enough words to describe what we need!

You may have noticed this issue with acronyms over the last 10 years: There are too many of them that could stand for anything. The FAT16 I mentioned above stands for File Allocation Table, but that’s obvious only to those who know it. It could just as easily stand for Feature Acceptance Test, Factory Allowance Test, Failure Automation Triangle, and so on. Or fat.

Tech acronyms aren’t the only terms for which we’re running out of alternatives. We’re also running out of names for rock bands, for instance. Dave Barry has been worried about this longer than IPv6 has been around, and he has a useful starter list in case any budding musicians get stuck.

Pharmaceuticals is having a similar problem, but with more profound consequences: OPDRA(one of those acronyms again) is the branch of the FDA making sure that prescription names are not similar enough to be confused with one another. Giving clozapine instead of olanzapine, or giving serzone for seroquel, has injured or killed patients. Computerized medical systems would prevent transcription errors, but no one can prevent confusion or misstatements on the part of a prescribing doctor.

In computing, the latest generation of technologies is ignoring the problem and reusing terms with reassigned definitions: I use Windows (wooden framework with a glass pane) and Vista (a distant view or prospect) to get to clouds (a visual mass of water droplets) via LAMP (an artificial source of illumination), so I can access the grid (a regularly spaced pattern of lines).

If we don’t have enough space for new terms, we can always reuse old ones!

But this only works if the technology is widespread, and no one needs to copyright it. Otherwise, we need to expand the namespace, or what I’ve called Wordv1 to Wordv2, which squares the size of the available namespace for the low price of using two-word names.

So we have Facebook and Foursquare, Techcrunch, Techflash, and Techdirt. We even had an “Untitled Startup” for awhile, but it finally found a name that wasn’t already copyrighted and is now “Simply Measured.”

I guess it won’t be long until we complete the circle and names expand into Wordv3, and we get great three-word names like International Beekeeping Mavens. But, don’t worry, if it sounds too long, we can always use the acronym.

— David Manheim works as a terrorism insurance modeling specialist at Risk Management Solutions.


Expanding definitions and Obsoleting Industries

I’ve already explained why we can’t figure out if bitcoin is “really” a currency. But I think there is a lot more to say — because those 3 characteristics of money (Unit of Account, Store of Value, and Medium of Exchange) are not the only things that make money useful.

What else is needed?

Principally, gold stopped being used as currency directly because it was too hard to carry around as a currency — especially safely! But the gold standard was abandoned because the supply was too inflexible. Country’s economies started to expand much faster than their metal-backed currency, so that the value that existed was in excess of the medium of exchange for that value, and their needs for credit couldn’t be easily supplied with gold. This clarifies that these three tasks are not all a currency can do, nor is it the only thing we might care about. In fact, much before digital currencies, there were lots of things that we need that traditional forms of money don’t provide. Instead, systems were created to fill in the gaps, and these systems sprouted entire industries that software is getting ready to eat.

For example, we frequently need a system for measuring, processing, and communicating transactions. This is traditionally done by bookkeepers (not even necessarily accountants). I’ll refer to it as a “ledger of transactions” (4). Bookkeeping employs a couple hundred thousand people and costs around $50bn in the US alone. Under modern accounting principles, using third party verifiers, this system also allows an owner to provide a “proof of worth” (5) for a company or an individual. That’s accounting, (audit, not tax) and it employs another couple hundred thousand people and costs $100b. Both of these are bonuses that blockchain ledger currencies like bitcoin can provide, for example, using merkel hash tree signed proofs. Because of this, traditional businesses and currencies must rely on those large, expensive systems instead.

Next, we have more ancillary, non-currency systems that provide “tokens of ownership” (6) for non-currency goods, like real estate deeds or stock certificates. In order for these to be liquid and saleable, a “verifiable exchange market” (7) is needed, such as a county clerk for real estate, so that people can reliably sell their property without worrying that someone else will appear with a different deed to the property. If you’ve ever bought a house, you know the “title search” fee of $250+ you pay, instead of a 1 line query of a distributed blockchain database. And then you probably still need title insurance, in case the search missed anything.

The verifiable exchange can also provide a “transaction price log” (8) like the stock market’s ticker, where everyone can see the value of the goods currently being traded, and therefore be able to make decisions about whether to buy and sell. And all three of these can be accomplished using on-chain blockchain tokens, which track ownership, and the blockchain can show the prices paid for them.

We also want a “system of credit” (9) that allows for transactions that are contingent, risky, or require a future payment. This last is closely related to, and requires, a unit of account — but credit cards and most other typical forms of credit use outside systems for their unit of account. This is a feature that blockchain based currencies don’t do well, yet. Some smart contract platforms seem poised to allow, for example, collateralized loans, but the key difficult with extending credit via blockchain is that unsecured credit requires known identities, which blockchains don’t do. (If I lend money to you, then you stop paying me back and just start using a new wallet for your money, it’s not clear what recourse I have.)

Further, built on top of these systems, we have complex systems for many other features of the modern economy that are enabled by these various services and characteristics of money and related market systems. For example, fractional reserve banking relies on a “system of credit” for loans so that banks can have assets in excess of their reserves. For this to be trustworthy, we need (but don’t fully have) a robust “proof of worth” for these banks.

We have a repurchase agreement (“repo”) market that allows “tokens of ownership” (6) to assist the “system of credit” (9) which helps ensure liquidity on the basis of owned assets.

The Future

This large set of needs, combined with a healthy dose of historical path dependence, leads to the current complicated set of systems that are all intertwined. But as one 2016 Nobel laureate said, “The times, they are a changin’.”

Cryptocurrencies and Smart contracts have the ability to do all of these things. Definitions don’t dictate reality, they reflect it. Cryptocurrencies can do things currencies cannot, and focusing on the definitions is a red herring.