Calafia Café in Palo Alto is one of the smartest eateries in the world. With Google’s former executive chef Charlie Ayers at the helm, the food here isn’t just for sustenance. This is California — eating is also a path to self-improvement. Each dish is carefully crafted with ingredients that not only keep you slim, but make you smarter and more energized too. A half-dozen venture capitalists pick at their dandelion salads. A sleepy suburb at night, by day Palo Alto becomes the beating heart of Silicon Valley, the monied epicenter of the greatest gathering of scientific and engineering talent in the history of human civilization. To the west, across the street, lies Stanford University. The Googleplex sprawls a few miles to the east. In the surrounding region, some half-million engineers live and work. A tech tycoon or two wouldn’t be out of place here. Steve Jobs was a regular.

Excusing myself to the men’s room, however, I discover that Calafia Café has a major technology problem. Despite the pedigree of its clientele, the smart toilet doesn’t work. As I stare hopefully at the stainless steel throne, a red light peering out from the small black plastic box that contains the bowl’s “brains” blinks at me fruitlessly. Just above, a sign directs an escape path. “If sensor does not work,” it reads, “use manual flush button.” And so I bail out, sidestepping fifty years of progress in computer science and industrial engineering in the blink of an eye.

Back at my table, I try to reverse-engineer the model of human-waste production encoded in the toilet’s CPU. I imagine a lab somewhere in Japan. Technicians in white lab coats wield stopwatches as they methodically clock an army of immodest volunteers seated upon row after row of smart johns. The complexity of the problem becomes clear. Is it supposed to flush as soon as you stand up? Or when you turn around? Or pause for a fixed amount of time? But how long? Can it tell if you need another flush? It’s not quite as challenging an engineering task as putting a man on the moon, or calculating driving directions to the airport. Somehow, though, that stuff works every time.

My bewilderment quickly yields to a growing sense of dread. How is it that even in the heart of Silicon Valley it’s completely acceptable for smart technology to be buggy, erratic, or totally dysfunctional? Someone probably just cured cancer in the biotechnology lab across the street and is here celebrating over lunch. Yet that same genius will press the manual flush button just as I did, and never think twice about how consistently this new world of smart technology is letting us down. We are weaving these technologies into our homes, our communities, even our very bodies — but even experts have become disturbingly complacent about their shortcomings. The rest of us rarely question them at all.

I know I should stop worrying, and learn to love the smart john. But what if it’s a harbinger of bigger problems? What if the seeds of smart cities’ own destruction are already built into their DNA?

I’ve argued that smart cities are a solution to the challenges of 21st-century urbanization. I’ve told you that despite potential pitfalls, the benefits outweigh the risks, especially if we are aggressive about confronting the unintended consequences of our choices. But in reality we’ve only scratched the surface.

What if the smart cities of the future are buggy and brittle? What are we getting ourselves into?

Buggy

A few weeks later, I found myself wandering around the MIT campus in Cambridge, Massachusetts, with nary a thought about uncooperative toilets in mind. Strolling west from Kenmore Square, a few minutes later I came across the new home of the Broad Institute, a monolith of glass and steel that houses a billion-dollar center for research in genomic medicine. The street wall was tricked out with an enormous array of displays showing in real time the endless sequences of DNA base pairs being mapped by the machinery upstairs.

And then, out of the corner of my eye, I saw it. The Blue Screen of Death, as the alert displayed by Microsoft Windows following an operating-system crash is colloquially known. Forlorn, I looked through the glass at the lone panel. Instead of the stream of genetic discoveries, a meaningless string of hexadecimals stared back, indicating precisely where, deep in the core of some CPU, a lone miscomputation had occurred. Just where I had hoped to find historic fusion of human and machine intelligence, I’d found yet another bug.

The term “bug,” derived from the old Welsh bwg (pronounced “boog”), has long been used as slang for insects. But appropriation of the term to describe technical failings dates to the dawn of the telecommunications age. The first telegraphs invented in the 1840s used two wires, one to send and one to receive. In the 1870s, duplex telegraphs were developed, permitting messages to be sent simultaneously in both directions over a single wire. But sometimes stray signals would come down the line, which were said to be “bugs” or “buggy.” Thomas Edison himself used the expression in an 1878 letter to Puskás Tivadar, the Hungarian inventor who came up with the idea of a telephone exchange that allowed individual lines to be connected into a network for the first time. According to an early history of Edison’s own quadruplex, an improved telegraph that could send two signals in each direction, by 1890 the word had become common industry parlance. The first documented computer bug, however, was an actual insect. In September 1947, Navy researchers working with professors at Harvard University were running the Mark II Aiken Relay Calculator through its paces when it suddenly began to miscalculate. Tearing open the primitive electromechanical computer, they found a moth trapped between one of its relays. On a website maintained by Navy historians, you can still see a photograph of the page from the lab notebook where someone carefully taped the moth down, methodically adding an annotation: “First actual case of bug being found.” As legend has it, that person was Grace Hopper, a programmer who would go on to become an important leader in computer science. (Hopper’s biographer, however, disputes this was the first time “bug” was used to describe a malfunction in the early development of computers, arguing “it was clear the term was already in use.”)

Since that day, bugs have become endemic in our digital world, the result of the enormous complexity and ruthless pace of modern engineering. But how will we experience bugs in the smart city? They could be as isolated as that faulty toilet or a crashed public screen. In 2007 a Washington Metro rail car caught fire after a power surge went unnoticed by buggy software designed to detect it. Temporarily downgrading back to the older, more reliable code took just twenty minutes per car while engineers methodically began testing and debugging.

But some bugs in city-scale systems will ripple across networks with potentially catastrophic consequences. A year before the DC Metro fire, a bug in the control software of San Francisco’s BART system forced a system-wide shutdown not just once, but three times over a 72-hour period. More disconcerting is the fact that initial attempts to fix the faulty code actually made things worse. As an official investigation later found, “BART staff began immediately working to configure a backup system that would enable a faster recovery from any future software failure.” But two days after the first failure, “work on that backup system inadvertently contributed to the failure of a piece of hardware that, in turn, created the longest delay.” Thankfully, no one was injured by these subway shutdowns, but their economic impact was likely enormous — the economic toll of the two-and-a-half-day shutdown of New York’s subways during a 2005 strike was estimated at $1 billion.

The troubles of automation in transit systems are a precursor to the kinds of problems we’re likely to see as we buy into smart cities. As disconcerting as today’s failures are, however, they are actually a benchmark for reliability. Current smart systems are painstakingly designed and extensively tested. They have multiple layers of fail-safes. With the urgency of urban problems increasing and the resources and will to deal with them in doubt, in the future many smart technologies will be thrown together under tight schedules and even tighter budgets. They will struggle to match this gold standard of reliability, with only a few short-lived, sporadic glitches each year.

The sheer size of city-scale smart systems comes with its own set of problems. Cities and their infrastructure are already the most complex structures humankind has ever created. Interweaving them with equally complex information processing can only multiply the opportunities for bugs and unanticipated interactions. As Kenneth Duda, a high-performance networking expert told the New York Times, “the great enemy is complexity, measured in lines of code, or interactions.” Ellen Ullman, a writer and former software developer, argues, “it is impossible to fully test any computer system. To think otherwise is to misunderstand what constitutes such a system. It is not a single body of code created entirely by one company. Rather, it is a collection of ‘modules’ plugged into one another. ... The resulting system is a tangle of black boxes wired together that communicate through dimly explained ‘interfaces.’ A programmer on one side of an interface can only hope that the programmer on the other side has gotten it right.”

In his landmark 1984 study of technological disasters, Normal Accidents, sociologist Charles Perrow argued that in highly complex systems with many tightly linked elements, accidents are inevitable. What’s worse is that traditional approaches to reducing risk, such as warnings and alerts (or the installation of the backup recovery system in the BART incident), may actually introduce more complexity into systems and thereby increase risks. The Chernobyl nuclear disaster, for instance, was caused by an irreversible chain of events triggered during tests of a new reactor safety system. Perrow’s conclusion: “Most high-risk systems have some special characteristics, beyond their toxic or explosive or genetic dangers, that make accidents in them inevitable, even ‘normal.’”

Normal accidents will be ever-present in smart cities. Just as the rapid pace of urbanization has revealed shoddy construction practices, most notably in China’s notorious “tofu buildings,” hastily put together smart cities will have technological flaws created by designers’ and builders’ shortcuts. These hasty hacks threaten to make earlier design shortcuts like the Y2K bug seem small in comparison. Stemming from a trick commonly used to save memory in the early days of computing, by recording dates using only the last two digits of the year, Y2K was the biggest bug in history, prompting a worldwide effort to rewrite millions of lines of code in the late 1990s. Over the decades, there were plenty of opportunities to undo Y2K, but thousands of organizations chose to postpone the fix, which ended up costing over $300 billion worldwide when they finally got around to it. Bugs in the smart city will be more insidious, living inside lots of critical, interconnected systems. Sometimes there may be no way to anticipate the interdependencies. Who could have foreseen the massive traffic jam caused on US Interstate 80 when a bug in the system used to manage juror pools by Placer County, California, erroneously summoned twelve hundred people to report for duty on the same day in 2012?

The pervasiveness of bugs in smart cities is disconcerting. We don’t yet have a clear grasp of where the biggest risks lie, when and how they will cause systems to fail, or what the chain-reaction consequences will be. Who is responsible when a smart city crashes? And how will citizens help debug the city? Today, we routinely send anonymous bug reports to software companies when our desktop crashes. Is this a model that’s portable to the world of embedded and ubiquitous computing?

Counterintuitively, buggy smart cities might strengthen and increase pressure for democracy. Wade Roush, who studied the way citizens respond to large-scale technological disasters like blackouts and nuclear accidents, concluded that “control breakdowns in large technological systems have educated and radicalized many lay citizens, enabling them to challenge both existing technological plans and the expertise and authority of the people who carry them out.” This public reaction to disasters of our own making, he argues, has spurred the development of “a new cultural undercurrent of ‘technological citizenship’ characterized by greater knowledge of, and skepticism toward, the complex systems that permeate modern societies.” If the first generation of smart cities does truly prove fatally flawed, from their ashes may grow the seeds of more resilient, democratic designs.

In a smart city filled with bugs, will our new heroes be the adventurous few who can dive into the ductwork and flush them out? Leaving the Broad Institute’s Blue Screen of Death behind, I headed back in the rain to my hotel, reminded of Brazil, the 1985 film by Monty Python troupe member Terry Gilliam, which foretold an autocratic smart city gone haywire. Arriving at my room, I opened my laptop and started up a Netflix stream of the film. As the scene opens, the protagonist, Sam Lowry, squats sweating by an open refrigerator. Suddenly the phone rings, and Harry Tuttle, played by Robert De Niro, enters. “Are you from Central Services?” asks Lowry, referring to the uncaring bureaucracy that runs the city’s infrastructure. “They’re a little overworked these days,” Tuttle replies. “Luckily I intercepted your call.” Tuttle is a guerrilla repairman, a smart-city hacker valiantly trying to keep residents’ basic utilities up and running. “This whole system of yours could be on fire, and I couldn’t even turn on a kitchen tap without filling out a twenty-seven-B-stroke-six.”
Let’s hope that’s just a story. Some days, it doesn’t feel so far-fetched.

Brittle

Creation myths rely on faith as much as fact. The Internet’s is no different. Today, netizens everywhere believe that the Internet began as a military effort to design a communications network that could survive a nuclear attack.

The fable begins in the early 1960s with the publication of “On Distributed Communications” by Paul Baran, a researcher at the RAND think tank. At the time, Baran had been tasked with developing a scheme for an indestructible telecommunications network for the US Air Force. Cold War planners feared that the hub-and-spoke structure of the telephone system was vulnerable to a preemptive Soviet first strike. Without a working communications network, the United States would not be able to coordinate a counterattack, and the strategic balance of “mutually assured destruction” between the superpowers would be upset. What Baran proposed, according to Harvard University science historian Peter Galison, “was a plan to remove, completely, critical nodes from the telephone system.” In “On Distributed Communications” and a series of pamphlets that followed, he demonstrated mathematically how a less centralized latticework of network hubs, interconnected by redundant links, could sustain heavy damage without becoming split into isolated sections. The idea was picked up by the Pentagon’s Advanced Research Projects Agency (ARPA), a group set up to fast-track R&D after the embarrassment of the Soviet space program’s Sputnik launch in 1957. ARPANET, the Internet’s predecessor, was rolled out in the early 1970s.
So legend has it.

The real story is more prosaic. There were indeed real concerns about the survivability of military communications networks. But RAND was just one of several research groups that were broadly rethinking communications networks at the time — parallel efforts on distributed communications were being led by Lawrence Roberts at MIT and Donald Davies and Roger Scantlebury at the United Kingdom’s National Physical Laboratory. Each of the three efforts remained unaware of each other until a 1967 conference organized by the Association for Computing Machinery in Gatlinburg, Tennessee, where Roberts met Scantlebury, who by then had learned of Baran’s earlier work. And ARPANET wasn’t a military command network for America’s nuclear arsenal, or any arsenal for that matter. It wasn’t even classified. It was a research network. As Robert Taylor, who oversaw the ARPANET project for the Pentagon, explained in 2004 in a widely forwarded e-mail, “The creation of the ARPA net was not motivated by considerations of war. The ARPA net was created to enable folks with common interests to connect to one another through interactive computing even when widely separated by geography.”

We also like to think that the Internet is still widely distributed as Baran envisioned, when in fact it’s perhaps the most centralized communications network ever built. In the beginning, ARPANET did indeed hew closely to that distributed ideal. A 1977 map of the growing network shows at least four redundant transcontinental routes, run over phone lines leased from AT&T, linking up the major computing clusters in Boston, Washington, Silicon Valley, and Los Angeles. Metropolitan loops created redundancy within those regions as well. If the link to your neighbor went down, you could still reach them by sending packets around in the other direction. This approach is still commonly used today.

By 1987, the Pentagon was ready to pull the plug on what it had always considered an experiment. But the research community was hooked, so plans were made to hand over control to the National Science Foundation, which merged the civilian portion of the ARPANET with its own research network, NSFNET, launched a year earlier. In July 1988, NSFNET turned on a new national backbone network that dropped the redundant and distributed grid of ARPANET in favor of a more efficient and economical hub-and-spoke arrangement. Much like the air-transportation network today, consortia of universities pooled their resources to deploy their own regional feeder networks (often with significant NSF funding), which linked up into the backbone at several hubs scattered strategically around the country.

Just seven years later, in April 1995, the National Science Foundation handed over management of the backbone to the private sector. The move would lead to even greater centralization, by designating just four major interconnection points through which bits would flow across the country. Located outside San Francisco, Washington, Philadelphia, and Chicago, these hubs were the center not just of America’s Internet, but the world’s. At the time, an e-mail from Europe to Asia would almost certainly transit through Virginia and California. Since then, things have centralized even more. One of those hubs, in Ashburn, Virginia, is home to what is arguably the world’s largest concentration of data centers, some forty buildings boasting the collective footprint of 22 Walmart Supercenters. Elsewhere, Internet infrastructure has coalesced around preexisting hubs of commerce.

Today, you could knock out a handful of buildings in Manhattan where the world’s big network providers connect to each other — 60 Hudson Street, 111 Eighth Avenue, 25 Broadway — and cut off a good chunk of transatlantic Internet capacity. (Fiber isn’t the first technology to link 25 Broadway to Europe. The elegant 1921 edifice served as headquarters and main ticket office for the great ocean-crossing steamships of the Cunard Line until the 1960s.)

Despite the existence of many chokepoints, the Internet’s nuke-proof design creation myth has only been strengthened by the fact that the few times it has actually been bombed, it has proven surprisingly resilient. During the spring 1999 aerial bombardment of Serbia by NATO, which explicitly targeted telecommunications facilities along with the power grid, many of the country’s Internet Protocol networks were able to stay connected to the outside world. And the Internet survived 9/11 largely unscathed. Some 3 million telephone lines were knocked out in lower Manhattan alone — a grid the size of Switzerland’s — from damage to a single phone-company building near the World Trade Center. Broadcast radio and TV stations were crippled by the destruction of the north tower, whose rooftop bristled with antennas of every size, shape, and purpose. Panic-dialing across the nation brought the phone system to a standstill. But the Internet hardly blinked.

But while the Internet manages to maintain its messy integrity, the infrastructure of smart cities is far more brittle. As we layer ever more fragile networks and single points of failure on top of the Internet’s still-resilient core, major disruptions in service are likely to be common. And with an increasing array of critical economic, social, and government services running over these channels, the risks are compounded.

The greatest cause for concern is our growing dependence on untethered networks, which puts us at the mercy of a fragile last wireless hop between our devices and the tower. Cellular networks have none of the resilience of the Internet. They are the fainting ladies of the network world — when the heat is on, they’re the first to go down and make the biggest fuss as they do so.

Cellular networks fail in all kinds of ugly ways during crises; damage to towers (15 were destroyed around the World Trade Center on 9/11 alone), destruction of the “backhaul” fiber-optic line that links the tower into the grid (many more), and power loss (most towers have just four hours of battery backup). In 2012, flooding caused by Hurricane Sandy cut backhaul to over 2000 cell sites in eight counties in and around New York City and its upstate suburbs (not including New Jersey and Connecticut), and power to nearly 1500 others. Hurricane Katrina downed over a thousand cell towers in Louisiana and Mississippi in August 2005, severely hindering relief efforts because the public phone network was the only common radio system among many responding government agencies. In the areas of Japan north of Tokyo annihilated by the 2011 tsunami, the widespread destruction of mobile-phone towers literally rolled the clock back on history, forcing Buggy, Brittle, and Bugged 263 people to resort to radios, newspapers, and even human messengers to communicate. “When cellphones went down, there was paralysis and panic,” the head of emergency communications in the city of Miyako told the New York Times.

The biggest threat to cellular networks in cities, however, is population density. Because wireless carriers try to maximize the profit-making potential of their expensive spectrum licenses, they typically only build out enough infrastructure to connect a fraction of their customers in a given place at the same time. “Oversubscribing”, as this carefully calibrated scheme is known in the business, works fine under normal conditions, when even the heaviest users rarely chat for more than a few hours a day. But during a disaster, when everyone starts to panic, call volumes surge and the capacity is quickly exhausted. On the morning of September 11, for instance, fewer than 1 in 20 mobile calls were connected in New York City. A decade later, little has changed. During a scary but not very destructive earthquake on the US East Coast in the summer of 2011, cell networks were again overwhelmed. Yet media reports barely noted it. Cellular outages during crises have become so commonplace in modern urban life that we no longer question why they happen or how the problem can be fixed.

Disruptions in public cloud-computing infrastructure highlight the vulnerabilities of dependence on network apps. Amazon Web Services, the 800-pound gorilla of public clouds that powers thousands of popular websites, experienced a major disruption in April 2011, lasting three days. According to a detailed report on the incident posted to the company’s website, the outage appears to have been a normal accident, to use Perrow’s term. A botched configuration change in the data center’s internal network, which had been intended to upgrade its capacity, shunted the entire facility’s traffic onto a lower-capacity backup network. Under the severe stress, “a previously unencountered bug” reared its head, preventing operators from restoring the system without risk of data loss. Later, in July 2012, a massive electrical storm cut power to the company’s Ashburn data center, shutting down two of the most popular Internet services — Netflix and Instagram. “Amazon Cloud Hit By Real Cloud,” quipped a PC World headline.

The cloud is far less reliable than most of us realize, and its fallibility may be starting to take a real economic toll. Google, which prides itself on high-quality data-center engineering, suffered a half-dozen outages in 2008 lasting up to 30 hours. Amazon promises its cloud customers 99.5 percent annual uptime, while Google pledges 99.9 percent for its premium apps service. That sounds impressive until you realize that even after years of increasing outages, even in the most blackout-prone region (the Northeast), the much-maligned American electric power industry averages 99.96 percent uptime. Yet even that tiny gap between reality and perfection carries a huge cost. According to Massoud Amin of the University of Minnesota, power outages and power quality disturbances cost the US economy between $80 billion and $188 billion a year. A back-of-the-envelope calculation published by International Working Group on Cloud Computing Resiliency tagged the economic cost of cloud outages between 2007 and mid-2012 at just $70 million (not including the July 2012 Amazon outage). But as more and more of the vital functions of smart cities migrate to a handful of big, vulnerable data centers, this number is sure to swell in coming years.

Cloud-computing outages could turn smart cities into zombies. Biometric authentication, for instance, which senses our unique physical characteristics to identify individuals, will increasingly determine our rights and privileges as we move through the city — granting physical access to buildings and rooms, personalizing environments, and enabling digital services and content. But biometric authentication is a complex task that will demand access to remote data and computation. The keyless entry system at your office might send a scan of your retina to a remote data center to match against your personnel record before admitting you. Continuous authentication, a technique that uses always-on biometrics — your appearance, gestures, or typing style — will constantly verify your identity, potentially eliminating the need for passwords. Such systems will rely heavily on cloud computing, and will break down when it does. It’s one thing for your e-mail to go down for a few hours, but it’s another thing when everyone in your neighborhood gets locked out of their homes.

Another “cloud” literally floating in the sky above us, the Global Positioning System satellite network, is perhaps the greatest single point of failure for smart cities. Without it, many of the things on the Internet will struggle to ascertain where they are. America’s rivals have long worried about their dependence on the network of 24 satellites owned by the US Defense Department. But now even America’s closest allies worry that GPS might be cut off not by military fiat but by neglect. With a much-needed modernization program for the decades-old system way behind schedule, in 2009 the Government Accountability Office lambasted the Air Force for delays and cost overruns that threatened to interrupt service. And the stakes of a GPS outage are rising fast, as navigational intelligence permeates the industrial and consumer economy. In 2011 the United Kingdom’s Royal Academy of Engineering concluded that “a surprising number of different systems already have GPS as a shared dependency, so a failure of the GPS signal could cause the simultaneous failure of many services that are probably expected to be independent of each other.” For instance, GPS is extensively used for tracking suspected criminals and land surveying. Disruptions in GPS service would require rapidly reintroducing older methods and technologies for these tasks. While alternatives such as Russia’s GLONASS already exist, and the European Union’s Galileo and China’s Compass systems will provide more alternatives in the future, the GPS seems likely to spawn its own nasty collection of normal accidents. “No one has a complete picture,” concluded Martyn Thomas, the lead investigator on the UK study, “of the many ways in which we have become dependent on weak signals 12,000 miles above us.”

Centralization of smart-city infrastructure is risky, but decentralization doesn’t always increase resilience. Uncoordinated management can create its own brittle structures, such as the Internet’s “bufferbloat” problem. Buffering, which serves as a kind of transmission gearbox to sync fast-flowing and congested parts of the Internet, is a key tool to smoothing out surges of data and reducing errors. But in 2010 Jim Gettys, a veteran Internet engineer, noticed that manufacturers of network devices had taken advantage of rapidly falling memory prices to beef up buffers far beyond what the Internet’s original congestion-management scheme was designed for. “Manufacturers have reflexively acted to prevent any and all packet loss and, by doing so, have inadvertently defeated a critical TCP congestion-detection mechanism,” concluded the editors of ACM Queue, a leading computer networking journal, referring to the Internet’s traffic cop, the Transmission Control Protocol. The result of bufferbloat was increasing congestion and sporadic slowdowns. What’s most frightening about bufferbloat is that it was hiding in plain view. Gettys concluded; “the issues that create delay are not new, but their collective impact has not been widely understood ... buffering problems have been accumulating for more than a decade.”

What a laundry list of accidental ways smart cities might be brittle by design or oversight! But what if someone deliberately tried to bring one to its knees? The threat of cyber-sabotage on civil infrastructure is only just beginning to capture policymakers’ attention. Stuxnet, the virus that attacked Iran’s nuclear weapons plant at Natanz in 2010, was just the beginning. Widely believed to the product of a joint Israeli-American operation, Stuxnet was a clever piece of malicious software, or malware, that infected computers involved with monitoring and controlling industrial machinery and infrastructure, known by the acronym SCADA (supervisory control and data acquisition). At Natanz some 6000 centrifuges were being used to enrich uranium to bomb-grade purity.

Security experts believe Stuxnet, carried in on a USB thumb drive, infected and took over the SCADA systems controlling the plant’s equipment. Working stealthily to knock the centrifuges off balance even as it reported to operators that all was normal, Stuxnet is believed to have put over a thousand machines out of commission, significantly slowing the refinement process, and the Iranian weapons program. The wide spread of Stuxnet was shocking. Unlike the laser-guided, bunker-busting smart bombs that would have been used in a conventional strike on the Natanz plant, Stuxnet attacked with all the precision of carpet bombing. By the time Ralph Langner, a German computer-security expert who specialized in SCADA systems, finally deduced the purpose of the unknown virus, it had been found on similar machinery not only in Iran but as far away as Pakistan, India, Indonesia, and even the United States. By August 2010, over 90,000 Stuxnet infections were reported in 115 countries.

Stuxnet was the first documented attack on SCADA systems, but it is not likely to be the last. A year later, in an interview with CNET , Langer bristled at the media’s focus on attributing the attack to a specific nation. “Could this also be a threat against other installations, U.S. critical infrastructure?” he asked. “Unfortunately, the answer is yes because it can be copied easily. That’s more important than the question of who did it.” He warned of Stuxnet copycat attacks, and criticized governments and companies for their widespread complacence. “Most people think this was to attack a uranium enrichment plant and if I don’t operate that I’m not at risk,” he said. “This is completely wrong. The attack is executed on Siemens controllers and they are general-purpose products. So you will find the same products in a power plant, even in elevators.”

Skeptics argue that the threat of Stuxnet is overblown. Stuxnet’s payload was highly targeted. It was programmed to only attack the Natanz centrifuges, and do so in a very specific way. Most importantly, it expended a highly valuable arsenal of “zero-day” attacks, undocumented vulnerabilities that can only be exploited once, after which a simple update will be issued by the software’s supplier. In its report on the virus, security software firm Symantec wrote “Incredibly, Stuxnet exploits four zero-day vulnerabilities, which is unprecedented.”

Stuxnet’s unique attributes aside, most embedded systems aren’t located in bunkers, and they are increasingly vulnerable to much simpler attacks on their human operators. Little more than a year after Stuxnet was uncovered, a lone hacker known only as “pr0f ” attacked the water utility of South Houston, a small town of seventeen thousand people just outside Texas’s most populous city. Enraged by the US government’s downplaying of a similar incident reported in Springfield, Illinois, pr0f homed in on the utility’s Siemens SIMATIC software, a Web-based dashboard for remote access to the waterworks’ SCADA systems. While the Springfield attack turned out to be a false alarm — federal officials eventually reported finding “no evidence of a cyber intrusion” — pr0f was already on the move, and the hacker didn’t even need to write any code. It turned out that the plant’s operators had chosen a shockingly weak three-letter password. While pr0f ’s attack on South Houston could have easily been prevented, Simatic is widely used and full of more fundamental vulnerabilities that hackers can exploit. That summer Dillon Beresford, a security researcher at (oddly coincidentally) Houston-based network security outfit NSS Labs, had demonstrated several flaws in SIMATIC and ways to exploit them. Siemens managed to dodge the collateral damage of Stuxnet, but the holes in SIMATIC are indicative of far more serious risks it must address.

Another troubling development is the growing number of “forever day” vulnerabilities being discovered in older control systems. Unlike zero-day exploits, for which vendors and security firms can quickly deploy countermeasures and patches, forever-day exploits target holes in legacy embedded systems that manufacturers no longer support — and therefore will never be patched. The problem affects industrial-control equipment sold in the past by both Siemens and GE, as well as a host of smaller firms. It has drawn increased interest from the Cyber Emergency Response Team, the government agency that coordinates American cyber-security efforts.

One obvious solution for securing smart-city infrastructure is to stop connecting it to the Internet. But “air-gapping,” as this technique is known, is only a stopgap measure at best. Stuxnet, much like Agent.btz, the virus that infected the Defense Department’s global computer network in 2008, were likely both walked into secure facilities on USB sticks. Insecure wireless networks are everywhere, even emanating from inside our own bodies. Researchers at the security firm McAfee have successfully hijacked insulin pumps, ordering the test devices to release a lethal dose of insulin, and a group of computer scientists at the University of Washington and University of Massachusetts have disabled heart-defibrillator implants using wireless signals.

These vulnerabilities are calling the entire open design of the Internet into question. No one in those early days of ARPANET ever imagined the degree to which we would embed digital networks in the support systems of our society, the carelessness with which we would do so, and the threat that malevolent forces would present. Assuring that the building blocks of smart cities are reliable will require new standards and probably new regulation. Colin Harrison, IBM’s smarter-cities master engineer, argues that in the future, “if you want to connect a computer system to a piece of critical national infrastructure it’s going to have to be certified in various ways.” We’ll also have take stronger measures to harden smart cities against direct assault. South Korea has already seen attacks on its civil infrastructure by North Korean cyber-warriors. One strike is believed to have shut down air traffic control in the country for over an hour.

Nothing short of a crisis will force us to confront the risk of smart cities’ brittle infrastructure. The first mayor who has to deal with the breakdown of a city-scale smart system will be in new territory, but who will take the blame? The city? The military? Homeland security? The technology firms that built it? Consider the accountability challenge Stuxnet poses — we’d likely never have known about it were it not for its own bug. Carried out of Natanz by some unsuspecting Iranian engineer, the worm failed to detect that it had escaped into the open, and instead of deactivating its own reproductive mechanisms, like a real virus it proliferated across the globe.

A New Civics

If the history of city building in the last century tells us anything, it is that the unintended consequences of new technologies often dwarf their intended design. Motorization promised to save city dwellers from the piles of horse manure that clogged 19th-century streets and deliver us from a shroud of factory smoke back to nature. Instead, it scarred the countryside with sprawl and rendered us sedentary and obese. If we don’t think critically now about the technology we put in place for the next century of cities, we can only look forward to all the unpleasant surprises they hold in store for us.

Smart cities are almost guaranteed to be chock full of bugs, from smart toilets and faucets that won’t operate to public screens sporting Microsoft’s ominous Blue Screen of Death. But even when their code is clean, the innards of smart cities will be so complex that so-called normal accidents will be inevitable. The only questions will be when smart cities fail, and how much damage they cause when they crash. Layered atop the fragile power grid, already prone to overload during crises and open to sabotage, the communications networks that patch the smart city together are as brittle an infrastructure as we’ve ever had.

But that’s only if we continue doing business as usual. We can stack the deck and improve the odds, but we need to completely rethink our approach to the opportunities and challenges of building smart cities. We need to question the confidence of tech-industry giants, and organize the local innovation that’s blossoming at the grassroots into a truly global movement. We need to push our civic leaders to think more about long-term survival and less about short-term gain, more about cooperation than competition. Most importantly, we need to take the wheel back from the engineers, and let people and communities decide where we should steer.

People often ask me, “What is a smart city?” It’s a hard question to answer. “Smart” is a problematic word that has come to mean a million things. Soon, it may take its place alongside the handful of international cognates — vaguely evocative terms like “sustainability” and “globalization” — that no one bothers to translate because there’s no consensus about what they actually mean. When people talk about smart cities, they often cast a wide net that pulls in every new public-service innovation from bike sharing to pop-up parks. The broad view is important, since cities must be viewed holistically. Simply installing some new technology, no matter how elegant or powerful, cannot solve a city’s problems in isolation. But there really is something going on here — information technology is clearly going to be a big part of the solution. It deserves treatment on its own. I take a more focused view and define smart cities as places where information technology is combined with infrastructure, architecture, everyday objects, and even our bodies to address social, economic, and environmental problems.

I think the more important and interesting question is, “what do you want a smart city to be?” We need to focus on how we shape the technology we employ in future cities. There are many different visions of what the opportunity is. Ask an IBM engineer and he will tell you about the potential for efficiency and optimization. Ask an app developer and she will paint a vision of novel social interactions and experiences in public places. Ask a mayor and it’s all about participation and democracy. In truth, smart cities should strive for all of these things.

There are trade-offs between these competing goals for smart cities. The urgent challenge is weaving together solutions that integrate these aims and mitigate conflicts. Smart cities need to be efficient but also preserve opportunities for spontaneity, serendipity, and sociability. If we program all of the randomness out, we’ll have turned them from rich, living organisms into dull mechanical automatons. They need to be secure, but not at the risk of becoming surveillance chambers. They need to be open and participatory, but provide enough support structure for those who lack the resources to self-organize. More than anything else, they need to be inclusive. In her most influential book, The Death and Life of Great American Cities, the acclaimed urbanist Jane Jacobs argued that “cities have the capability of providing something for everybody, only because, and only when, they are created by everybody.” Yet over fifty years later, as we set out to create the smart cities of the 21st century, we seem to have again forgotten this hard-learned truth.

But there is hope that a new civic order will arise in smart cities, and pull every last one of us into the effort to make them better places. Cities used to be full of strangers and chance encounters. Today we can mine the social graph in an instant by simply taking a photo. Algorithms churn in the cloud, telling the little things in our pocket where we should eat and whom we should date. It’s a jarring transformation. But even as old norms fade into the past, we’re learning new ways to thrive on mass connectedness. A sharing economy has mushroomed overnight, as people swap everything from spare bedrooms to cars, in a synergistic exploitation of new technology and more earth-friendly consumption. Online social networks are leaking back into the thriving urban habitats where they were born in countless promising ways.

For the last fifteen years, I’ve watched the struggle over how to build smart cities evolve from the trenches. I’ve studied and critiqued these efforts, designed parts of them myself, and cheered others along. I’ve written forecasts for big companies as they sized up the market, worked with start-ups and civic hackers toiling away at the grass roots, and advised politicians and policy wonks trying to push reluctant governments into a new era. I understand and share much of their agendas.

But I’ve also seen my share of gaps, shortfalls, and misguided assumptions in the visions and initiatives that have been carried forth under the banner of smart cities. And so I’m going to play the roles of myth buster, whistle-blower, and skeptic in one. The technology industry is asking us to rebuild the world around its vision of efficient, safe, convenient living. It is spending hundreds of millions of dollars to convince us to pay for it. But we’ve seen this movie before. As essayist Walter Lippmann wrote of the 1939 World’s Fair, “General Motors has spent a small fortune to convince the American public that if it wishes to enjoy the full benefit of private enterprise in motor manufacturing, it will have to rebuild its cities and its highways by public enterprise.” Today the computer guys are singing the same song.

I believe there is a better way to build smart cities than to simply call in the engineers. We need to lift up the civic leaders who would show us a different way. We need to empower ourselves to build future cities organically, from the bottom up, and do it in time to save ourselves from climate change. If that seems an insurmountable goal, don’t forget that at the end of the day the smartest city in the world is the one you live in. If that’s not worth fighting for, I don’t know what is.

www.anthonymobile.com