Why would I ever need that?

I was glad to hear that most of you enjoyed the Wired article titled “The Long Tail” by Chris Anderson. It’s not a new article, but it has had real staying power. One of the things that I like best about the paper is its implication that taste is not as mainstream as once thought. It’s great to have things that most of the population finds interesting and exciting, but as the paper powerfully points out, this same population of individuals also have their own unique tastes. We are multidimensional in our tastes. Some of our dimensions tie into large communities and some into small communities. Some of us might be members of only small communities, and we shouldn’t assume that the small communities are necessarily subsets of any large community. Tolerance of unique interests turns out to be good business!

Speaking of taste, not everyone in my family understands my excitement with the new Star Trek series that CBS recently launched. Star Trek: Discovery tries both to hook a new generation of Trekkies into the media franchise of space-age morality tales created from the mind of Gene Roddenberry and to appeal to the older generations that grew up on the Original Series and many subsequent series. I won’t try to convince you to watch the new series, but simply encourage you to think about the churn that continues in television and video markets. Unlike a lot of TV shows today, you can watch Discovery on Sundays at 8:30pm ET, but if you miss the broadcast, you can’t catch up on the streaming site for CBS without subscribing directly to CBS. Stated another way, your cable subscription does not give you streaming access to Star Trek: Discovery like it does for CBS’s primetime show Salvation. Further complicating things, you can get the show on Netflix, but only international viewers outside the U.S. can access it there.

The streaming world is a lucrative business, as the Long Tail paper points out, and it is not surprising that CBS wants to get into it and not just provide content for it. However, we’re going from a world where we pay for cable access and a few streaming services, which collect all the back content, into a world where every studio, network, and cell-phone manufacturer wants to launch its own streaming service. I can’t imagine that this will make Joe and Jane Consumer happy; I certainly don’t want to pay for multiple streaming services. It’s bad enough that I have multiple apps on my iPad, but then at least, I pay only one bill. (Ok, two. One to my cable provider and one to Netflix.) It seems like this space is ripe for disruption again. It will be interesting to watch.

Jim and I talked about a range of design topics and a bit about how today’s Internet works in the seminar this week, and I thought I’d write my blog in the same “scattered” fashion. While at first seemingly scattered and long, if you bear with me, we might get to the second half of this blog’s title. Ready?

I’ll start with a pointer to a Wired article about DNS hijacking. On Monday, we discussed, at a high level, how the Domain Name System (DNS) on the Internet helps people to get to web sites (or other resources on the Internet) by converting easy to memorize domain names (e.g., college.harvard.edu) to the numerical IP addresses (i.e., 184.73.172.23 in my example). The IP address is simply a standardized name space that works like U.S. postal addresses. For example, the address of Pinocchio’s Pizza & Subs shop is 74 Winthrop St., Cambridge MA. You’d find it by traveling to Massachusetts and then to the Massachusetts’s town of Cambridge. In Cambridge, you’d look for Winthrop Street and hope you’d find a building with the number 74 on it. IP addresses work the same way. The first numbers take you to a particular part of the network, and the last number corresponds to some particular machine (house) on the identified subnet (street). The Wired article talks about how adversaries have attacked this system to cut certain resources out of the Internet for a short time.

Unfortunately, adversaries are tougher to defeat than Mother Nature. So let’s stick with getting around the problems that Mother Nature throws at us for the rest of this blog post.

While Jim and I were repeatedly expressing our deep admiration for the Saltzer et al paper this week, we somehow stumbled into a discussion of bit-error detection and correction. I’m worried that I glossed over things too quickly. So, here’s a bit more explanation of how this stuff works. There’s a whole science behind this, but I’ll attempt to just give you a flavor of how it works and why it is powerful.

As we discussed, you can detect a single bit error by adding a parity bit to any group of bits. For example, if I wanted to protect a 4-bit data string against single bit errors while the packet was in transmission, I would add a single bit to the data string (creating a 5-bit packet), and the value of this fifth bit would be the sum of the other four bits modulo 2. As described, I’ve added what’s called an even parity bit to my packet. It’s called this because the addition of the parity bit makes the number of ones in the 5-bit packet even (or zero). Lots of things in the digital world have duals, and the same is true here for we could also create an odd parity bit that would make the number of ones in the packet odd. Let’s stick with even parity.

How does this work in practice? The machine sending the original 4-bit data string computes the even parity bit, appends it to the end of the four bits of data, and sends a 5-bit packet. The receiving machine grabs the 5-bit packet and computes the packet’s parity (over all 5 bits). If the result of this computation is zero, the first 4 bits are the data it wanted without any single-bit errors. If the result is one, then there was an error in transmission and the packet needs to be resent.

Notice that we can’t correct the error without retransmission because we don’t know where the error occurred in the 5 bits we received. One of the 1s was flipped to a 0 or a 0 was flipped to a 1, but all we know is that a bit was flipped somewhere.

Of course, this scheme isn’t guaranteed to work for 2 bit errors. If you flip any two bits, the effect of their flips cancels each other out in the parity calculation. I’ll let you figure out what happens when you have more than 2 bit errors.

We, however, were interested in fixing (Mother-Nature-type) errors in the network so that you could create a reliable network and remove the need for retransmissions. To explore this question, let’s assume that your network never has anything more than a single bit error in a packet no matter what its size (an unrealistic, but pedagogically interesting situation). What would I have to do to guarantee that the receiving machine had enough information to correct any single bit error in the packet?

Well, you could send the same data string twice in a single packet, which guarantees that you would get a clean copy of the data bits. Unfortunately, if the two received copies don’t match, you don’t know which copy of the duplicated data bits is the one you want. You simply made a very space-expensive, single-bit error detector that not only tells you that an error occurred, but where it occurred in the string of data bits.

Ok, that design failed, but fear not. We can always try again. Let’s try sending three copies of the data bits in a single packet. Now in the case of a single bit error in the packet, we can use a simple voting mechanism to decide what is the correct string of data bits. Success! The cost of this success was that we need a packet three-times longer than the data we wanted to send. Hmmm, maybe we can do better.

This is where the work of Richard Hamming comes in. Hamming did pioneering work in the middle of the last century on error detection and how to build efficient error correcting codes. Continuing with our example of wanting to send 4 data bits over a network, Hamming showed that you could add just 3 parity bits to the 4 data bits (creating a 7-bit packet) and correct any single bit error that occurs in the entire 7-bit packet. That’s less space overhead than we added in our first duplication scheme that failed to achieve error correction! More impressive, the overhead of Hamming’s approach decreases very quickly as you send longer and longer strings of data bits. For example, when we send 4 data bits in a 7-bit packet, the efficiency of the transmission is (4/7 =) 0.571. If we wanted to send 247 data bits, we’d need only 8 parity bits to cover all (247+8 =) 256 bits in the packet for a (247/256 =) 0.969 efficiency! Nearly every bit sent is a useful data bit! That’s the power of exponentials and clever encodings.

To see exactly how this works, I encourage you to look at the example on the Hamming(7,4) Wikipedia page. The matrix arithmetic might look intimidating, but it’s just a mathematical way of saying that the three parity bits looked at as a 3-bit number can cover all 7 locations in our 7-bit packet, allowing us through clever encoding to know exactly which bit was flipped, if one was. If no bit was flipped (i.e., no single bit error occurred), the eighth encoding of the three parity bits means no single bit error occurred.

In class, I said we needed to add only three parity bits to correct any single bit error in eight data bits. Off by one error! You clearly need four parity bits to correct a single bit error in eight data bits (a 12-bit packet). Please fix your notes if you took some.

I want to bring us back to design as I end this blog post. I often cold call on some of you during our seminar asking, for example, “Yasmin, what would you do to make this work?” In asking this, I’m asking a design question, and design questions are, at first, hard. Why? Because design questions have no right answer. (Please go back and read the previous line again.) And because they have no right answer, you can answer any way you like! The worst thing that will happen is that you’ll describe something that doesn’t do what we hoped it would do, as I did above in the doubling-the-data-string example. No problem with that. Maybe we’ll design something cool for a different application, or we’ll learn something and restart our design process a bit smarter.

Now, most of you, probably, have never done any significant design. That’s ok. More importantly, in my humble opinion, the only way to learn to do design is to do it. How might you start doing it? (How might you answer my question to Yasmin?) Well, you know where you want to go and so just take a small step in that direction. Suggest something that sounds like it moves us in the desired direction and maybe give the reason why you think it moves us in the right direction. We did that above. With enough practice, you’ll see patterns in design that lead to fundamental advances like Hamming did, and like Saltzer and his colleagues did.

We’ve mentioned several times while discussing the development of the ARPANET, which we’ll see this week led to the Internet, that the security of the network itself, the security of the data passing over it, and security of the hosts connected to the network were not a front-of-mind concerns for the original designers. As we all experience today, this design decision has created numerous problems for a world so dependent now on the operation of what we all hope is trustworthy Internet.

Trust. The news this week shows that trust is increasingly hard to come by.

First Equifax, a company whose purpose for being is to create a trusted source of all of our credit worthiness, admits that it could have prevented the catastrophic breach of its networked systems if it had patched an Apache Struts web application vulnerability sometime in the two months between the announcement of the vulnerability (and its corresponding patch) and the later intrusion using that vulnerability. Patch management has been a best practice since the mid-1990s, and I hope all of you run automatic software updates on your laptops and other personal networked devices.

And on September 13, 2017, the U.S. Department of Homeland Security (DHS) issued Binding Operational Directive 17-01, which questions the trust that many people, corporations, and governments put in “information security products, solutions, and services supplied directly or indirectly by AO Kaspersky Lab or related entities.” If we can’t trust the anti-virus and intrusion prevention software running on our networked machines, whom can we trust? As you may or may not know, in order for these programs to protect our systems they must have unencumbered access to practically everything on our systems, which is pretty much our entire lives these days. And to keep up-to-date in the never-ending battle against malware and malicious hackers, these trusted programs communicate regularly with a trusted server somewhere (typically run by the anti-virus and intrusion prevention manufacturer) on the Internet.

What’s the path forward in Binding Operational Directive 17-01? Two things that have me scratching my head.

On the one hand, the directive sets a timeframe for action: 30 days to identify what Kaspersky products are installed on government systems; 60 days to plan for their removal; and 90 days to complete the removal. Does that sound like Internet time to you? It sounds to me like this thinking was what got Equifax into trouble.

On the other hand, the U.S. government says that it is willing to consider a written argument from Kaspersky Labs that would address their fears. So far, Kaspersky has issued only a commercially based argument as to why the U.S. government should trust Kaspersky products with its sensitive data. I hope that that doesn’t convince anyone in DHS with a rudimentary understanding of networks and computer science. Then again, Kaspersky will have a hard time proving that their program won’t release any sensitive information on the system it is meant to protect. Doing that sounds a lot like trying to solve the Halting Problem. And do you even bother trying when the security program downloads new functionality as an integral part of its functionality (i.e., to update itself so that it can protect against new threats)?

It will be interesting to see where this all goes. It’s hard to operate in this world without some level of trust.

I’ve been thinking about the past this past week. Some of this urge to reflect on days gone by was, of course, a result of this week’s reading and discussion. The remaining impetus came from a discussion this weekend with my wife about getting our 10-year-old a cellphone.

I grew up in New Jersey in a town caught at the time between its rural, farming past and a suburbanite future, where cornfields one fall sprouted strip malls and elegant McMansions the next spring. For me, being 10 meant that I could walk everyday to a school that my mother couldn’t see from our front door. Sweet independence. Recognition that I was growing up and didn’t need an adult watching over me every second of the day. And for me, it was the beginning of new rules: (1) get the hell out from underfoot; (2) make sure that my share of the daily chores were done before supper; and (3) whenever I went during daylight hours, come immediately when I heard my parents holler from the backdoor that it was suppertime.

The world has certainly changed. Yes, my wife and I are finding ways to give our 10-year-old more freedoms. One of us no longer has to watch his every move, but the purchase of a cellphone for him doesn’t represent the new way to holler from the backdoor that dinner is ready. It’s a recognition that his days are now more complicated. His after-school program is no longer in the same location as his elementary school. He can’t walk from home to school, or from school to his after-school program, and the coordination required between all the adults involved in this dance across the school year rivals the logistics of an Amazon distribution center. If something in this daily dance runs off the rails, he needs to be able to contact us. I had to have a dime in my pocket so that I could find and use a payphone. Payphones no longer exist except in a few quaint places, and the dime has become a contract for $40 monthly cellphone plan.

In class this week, we talked briefly about interoperability, walled gardens, and what principles influenced the design of the ARPANET, which as we will see laid the foundation for the design of today’s Internet. In particular, robustness and responsiveness drove the earliest design decisions, and for my son’s cellphone, my wife and I certainly want his phone to work when he needs it and for him to respond when we call or text. We also realize that the latter desire has less to do with the Internet than with our son’s own decision making, but his decision making won’t be the main impediment if the Internet and the cellphone network aren’t themselves responsive!

However, what occupied most of our thinking this weekend was safety and security. If we get our son a cellphone, are we making him more or less safe? Despite the name, cellphones are not just a communication device that connects two people together through a cellular network. They are repositories of our personal information. They are portals to every part of today’s world, the good and the bad. Finally, they are ways for others to have unmediated access to our children, our children’s personal information, and their location.

My parents may have decided it was fine for me to gain some additional freedom, but they knew that the risks of that freedom were relatively small. I couldn’t go to far from my neighborhood (a couple of miles at best on my bike), and my parents knew the good and the bad that existed within that circle. If I started spending more time with some other adult in town, it was almost certain that they would hear about it. There are few secrets in a small town.

Today’s cellphones are, by default, open portals to the whole wide world and at the same time devices difficult for those sitting right next to you to know with whom you’re communicating. My parents, in letting me out of their sight, were fairly certain that they weren’t putting me into some other adult’s hands. I certainly worry that putting a cellphone in my son’s hands might mean putting him in some other unknown adult’s hands.

The answer seemed obvious to me: Balance the good and the bad by locking down our son’s new cellphone to the extent possible. If you want to get more informed about such things yourself, you might check out the this Wired article as a place to start.