In Memoriam: Peter G. Neumann
One of the great applied computer scientists, Peter G. Neumann, died on May 17. There have already been obits published, including in the New York Times. I knew Peter since at least 1992, and I’m honored that he considered me one of his colleagues and friends, even staying overnight at my house once. And that in itself shows another facet of his personality—while he had very strong opinions on technical subjects (and other things—for example, he did not think that Shakespeare wrote the the plays generally attributed to him), and was of course exceedingly accomplished (as the other obits made clear) in many fields, he was at heart someone who preferred simplicity even in his personal life. He was always happier staying with friends instead of in hotels, and preferred simpler restaurants to fancy ones. Simplicity, always.
What I really want to talk about, though, is that Peter, more than almost anyone else I’ve known, understood and strongly believed in the systems nature of problems. That is, there’s not one cause to a problem; everything, including the humans involved, interact.
Take, for example, buffer overflows, long a security scourge on the Internet. Is it the fault of the programmers? I knew someone who, 40 years ago (and several years before the Internet worm made the problem obvious), wrote a string-handling library before embarking on a text-heavy, security-sensitive program, because he felt that he’d never get things right otherwise. He was a very good programmer—is that the solution?
Maybe the problem in the C language. Lots of people have criticized C for its lack of memory safety, but in fact that’s an implementation and OS issue—exceeding array bounds is left undefined by the standard, which means that compilers are free to add array bounds metadata and to check it on array references. That requires different pointer implementations, which destroys ABI and OS compatibility. It’s also slower, because of the need to fetch and compare against the bounds on all references, so maybe we should blame compilers that don’t optimize enough or hardware that doesn’t make such checks efficient. (Hardware array bounds checking? The Burroughs B5000 had it in 1962.)
Take your choice, then: the person, the language, the compiler, the OS, or the hardware? The real answer is that it’s a system problem: all of these pieces interact.
This is what Peter really understood—and taught others. Go back and read the RISKS Digest or the Inside Risks columns and you’ll see what I mean: a very high percentage of the failures described, including of course some of my favorite ones, happened because of multiple interacting issues. It’s why he was a fan of the famous Einstein quote, “Everything should be as simple as possible—but no simpler” (and Peter got to discuss that one morning with Einstein himself!). But pay special attention to the second clause: “but no simpler.” Peter was a fan of simplicity, but he realized that some things were inherently complex. The real trick, and one fiendishly difficult to pull off, is to eliminate the unnecessary complexity. But you can’t eliminate complexity by changing one part of a system, because they all interact. He understood that, both the problem of complexity and the difficulty in eliminating it. Too few people do.
Peter Neumann will be missed. May his memory be for a blessing.
A New Book: "Don't Get Hacked!"
I have a new book out, Don’t Get Hacked! Protecting Yourself at Home. It’s released under a Creative Commons license, so it’s freely sharable and redistributable. I’m working on making print copies available.
Why Legislators Need Technologists
A rather bizarre bill has been introduced in the Michigan legislature, the Anticorruption of Public Morals Act, H.B. 4938. While there’s a lot to object to in the bill, I’ll leave the broader criticisms to others and focus on some technology issues.
The goal of the bill is specified in §3(1): “A commercial entity, public institution, private actor, or internet platform shall not knowingly distribute or make available prohibited material”—basically, their perception of pornography—“via the internet to any individual in this state.” Even legislators know that location-spoofing is easy, so §3(5) bars the sale of “circumvention tools”—and that’s where the trouble starts.
§2(a) defines “circumvention tools” as “any software, hardware, or service designed to bypass internet filtering mechanisms or content restrictions including virtual private networks, proxy servers, and encrypted tunneling methods to evade content restrictions.” “Designed to bypass” and “to evade” are doing a lot of work here, but the technologies named are most certainly vital and multi-use. Virtual private networks (VPNs), for example, go back at least to SP3, a US government design intended to protect communications on the Internet. I wrote about a mechanism to create VPNs in 1990. Most important, the IETF defined some VPN protocols in IPsec (1998). None of these were designed to “bypass” filtering or “evade” content restrictions, because there were no such things back then. Rather, they were designed to provide broad traffic protection and to extend corporate networks beyond the firewall.
And tunneling? It’s been part of ssh since its beginning, in 1996. Again, there was no conception of evading content restrictions.
VPNs and ssh tunnels are vital business tools—but this bill requires Michigan ISPs to “actively monitor and block known circumvention tools” (§3(3)). Not only ordinary businesses use them, ISPs use them to manage their infrastructure. This bill might outlaw secure operation of any ISP in the state, to say nothing of business travelers to Michigan.
Can this detection even be done? Well, if you use standard port and protocol numbers, you can detect ssh and IPsec, but there’s no requirement to do either. This implies using deep packet inspection on all traffic, which is hideously expensive and trivial to bypass.
It gets worse. §4, which applies to any “internet platform, website, or social media service that is accessible by a user in this state”, imposes a pile of restrictions. “Any website… acessible by a user in this state” is basically the entire Internet—but every such site has to comply. The Michigan-specific filtering has to be applied “uniformly across all users,” presumably including those not in Michigan. Everyone has to implement content moderation tools, except that automated ones don’t work and human ones don’t scale. And of course, every web site on the planet has to file an annual report with the Michigan state police. I wonder how many languages the state police can read—the bill doesn’t seem to require that the reports be in English…
In a minor vein, §2(f)(ii)(A) exempts “peer-reviewed academic content”. I suspect that the people behind this bill have never heard of, e.g., arxiv.org, a a preprint site. Most (but not all!) content there is intended for eventual peer review, but it hasn’t been peer-reviewed yet. Subsection (B) exempts “material to be used for scientific and medical research or instruction”, but not all material there is intended to further future scientific research.
In short: even if getting “pornography” were a good idea, this bill is a horrible way to go about it.
Security Turtles All the Way Down
An amazing security lapse just occurred: a journalist was accidentally included on a group chat via Signal to discuss sensitive war plans. This was wrong on so many different levels—read the article; it’s one of the msot amazing things I’ve ever read—but what I want to talk about is what “secure” means.
Let’s start with what Signal is. It bills itself as a “simple, powerful, and secure messenger”. It works more or less like any other text/voice/video communication platforms, but it’s strongly end-to-end encrypted. But is it really “secure”? That depends on your definition.
The first layer up is the cryptographic protocol employed. It’s almost certainly correct, though cryptography is notoriously hard to get right. And the NSA has stated that AES-256, for example, is good enough for top secret material. But there’s a catch: the application must be "properly implemented". On that, I’m much less confident; the rate of bug fix releases in Signal is quite high, and it has lots of features. That’s all well and good, but features imply code, and having lots of code implies lots of bugs, and bugs are the enemy of security. Is the code in Signal correct enough to be secure? I have no idea—but I’m nervous.
Past that, we have to think about identity: how do you know to whom you’re talking? That matters—is Squirrel really talking to Moose or to Boris or Natasha? The NSA’s secure phone systems apparently uses certificates containing the user’s name and clearance level. Signal doesn’t do that, for good reason—it’s for easy communication among arbitrary people, with no central authority wanted or needed (or possible) to issue such certificates. But if you get a call on your secure phone from someone claiming to be the head of the CIA, you want to know that’s who it is. You also want to know their clearance level, a concept rightfully foreign to Signal. In fact, apparently what is displayed on the screen of an NSA secure phone is the lower of the clearance levels of the two parties on the call. There is of course no analogue to this in Signal.
If you’re talking about war plans, your adversaries are major foreign intelligence agencies, organizations with vast technical capabilities. Is your phone or laptop secure against such attackers? Almost certainly not. And such adversaries have all sorts of other ways to eavesdrop on what you’re doing, which is why top secret conversations, even over secure gear, must take place in SCIFs (Sensitive Compartmented Intelligence Facilities). Notably, ordinary mobile phones and other personal electronic devices are not allowed in SCIFs.
So let’s look at the chain of failures here. First, the Signal messages were sent from devices on the open Internet. Almost certainly, at least some of these were not in SCIFs. They were thus exposed to hacking and to other forms of surveillance. People were in the chat without strong assurance of who they were. There was no visual indication of the security level of the chat. And all of this happened because these very high level people didn’t follow basic security rules. Adding a journalist to the group was the least of the problems and might have resulted from someone mistapping a name on a list (though “Jeffrey Goldberg” is not a rare name; I know someone else of that name)—but on a secure chat system, the wrong one probably wouldn’t have been listed at all.
The rules and procedures can be annoying, but they’re there for a reason. Here, every single safeguard was negated by one simple decision: to use Signal rather than a really secure platofrm for the discussion.
Update: Just when you thought it couldn’t get any stupider…
One of the members of the group Signal chat was in Russia at the time.
Also, just last week, the Pentagon warned that Russia was targeting Signal, that a vulnerability in it had been found, and that in any event, Signal was not approved for any non-public information, even unclassified information.
DHS Axes All Advisory Committee Members
According to multiple news reports, the Department of Homeland Security has fired all current members of all DHS advisory committees, including the Cyber Safety Review Board. This is a dangerous move, based solely on politics, and is guaranteed to produce committees that will tell DHS what it (or, more accurately) Trump wants to hear. It’s also in flat-out contradiction to how such committees were run in the past.
A bit of personal background first. In the past, I served on or worked with two different DHS advisory committees, the Science and Technology Advisory Committee (HSSTAC) and the Data Privacy and Integrity Advisory Committee (DPIAC). (I’ve also served on many other FACA-regulated committees.) I was appointed to HSSTAC during George W. Bush’s second term and served into Barack Obama’s second term, and I became a subject matter expert for DPIAC around the start of Obama’s first term. In both cases, the DHS folks running the committees were scrupulous about adhering to the rules.
For HSSTAC, I was given a form that asked my political affiliation. The form stated explicitly that the information to be provided was voluntary and that legally they couldn’t require an answer, but that their purpose in asking was to be able to demonstrate to the press and the country that it was politically balanced, that it was not stacked for one party or the other. I declined to answer, but another committee member told me that he wrote down "liberal Democrat"—and they didn’t exclude him.
The membership was ideologically very diverse, with people like a county sheriff, a retired air force general, a high-level executive, several academics, and more. During one meeting, when we were discussing some recommendations, someone proposed an idea that seemed to have support. I asked, "Wouldn’t that be unconstitutional?" Another member, who had both a PhD and a JD, confirmed it—and it was dropped. Never mind ideology or preconception; we all wanted to follow the law.
Mind you, things weren’t perfect. HSSTAC was created by statute, and how much attention was paid to our recommendations depended on who the Undersecretary for Science and Technology was at the time. Some (I worked under several) valued our input; others did not. But there was never a question of partisan politics interfering.
DPIAC was even more interesting. At the very beginning of Obama’s first term, he charged DHS with telling him what to do about cybersecurity. He cared and he wanted an answer as soon as possible, from highly qualifed people. But standing rules still applied. The White House ordered that all members who needed it be given interim TS/SCI clearances. Homeland Security pushed back, saying that the rules did not permit interim SCI clearances—and the White House said, "OK—stick with standing policy." They did not try to override this. One person who was affected (and I won’t say who it was, though if you were my age you’d recognize the name) and had a head stuffed full of far more sensitive stuff than I’d ever dreamed of hearing had to miss some meetings, because his SCI clearance has lapsed. The Obama White House was not going to override standing policy, even though in his case there was almost certainly no risk.
Now, things weren’t perfect, either in terms of what we recommended, what was done with our recommendations, or how we operated. But I can say that no one cared about ideological or party leanings, just expertise. We never once tried to "push agendas that attempt to undermine its national security mission, the President’s agenda or Constitutional rights of Americans." From what I’ve seen of the CSRB’s activity (and that’s the only one I follow these days), they don’t, either.
The CSRB is an extremely vital activity. I’ve advocated for something like it since at least 2012, and have continued to write and speak on the subject, most recently in 2022. As Adam Shostack and I wrote when the Board was first created, it isn’t a perfect structure, but it’s far better than what we had before. If nothing else, the CSRB should be independent of DHS, just like the the National Transportation Safety Board is not part of the Federal Aviation Administration: sometimes, the NTSB has to criticize the FAA’s regulations. Similarly, the CSRB may have problems with how DHS regulates, say, the cybersecurity of critical infrastructure companies.
That said, gutting it for what appears to be political reasons, especially in the middle of something as important as the Salt Typhoon investigation, is seriously counterproductive and harmful to the economy and national security.
A Last Blog Post About Voting
A few miscellaneous notes about voting…
First, it’s a subject I’ve often blogged about before. Go to the tag index on my blog and search for voting; you’ll see a number of posts.
Second: when I looked at the tag index, I saw that 16 years ago I’d actually written up something about my experiences as a poll worker. You can read that in conjunction with my post from yesterday.
Finally, you may have heard about lever voting machines but don’t know what they are. A few years ago, I created a short video about them, using an instructional model that I bought on eBay. The questions and candidates are all Columbia-specific, but that shouldn’t be an obstacle.
Voting: The Role of Process
A lot of attention in the technical elections community has to do with the actual mechanism for casting a vote, and in particular the use and type of voting machines, risk-limiting audits, etc. But the process of actually getting to cast the ballot is quite important, too. I was a poll worker in New Jersey in 2008 for Obama’s first term. We encountered quite a number of interesting situations, things not well covered by our training, but important for the honesty and accuracy of the process. It’s worth describing what happened.
I should note: this is just a small part of the full set of processes involved. It’s limited to what I saw personally as a poll worker and not even all of that—I was not an election official. There is more information on voting and process in some class slides of mine.
Background: in New Jersey in 2008, so-called DRE (Direct Recordinh Electronic) voting machines were used. Voters would check in at a desk, sign the poll book, and be handed a ticket. They would hand the ticket to another poll worker at a machine; this person would then unlock the machine and let them vote. When they finished voting, they were supposed to press a large red button to cast their vote and reset the machine. The tickets were all numbered. The number of each ticket would be written in the poll book next to their name; their voter registration number would be written on the ticket. (It’s a useful exercise for a security person to understand why both such numbers were needed, and what threats this does and does not protect against.)
Fleeing voters: A voter who leaves without pressing the button is called a fleeing voter. How should this be handled? There have been instances where poll workers have gone into the machine and changed the votes to what they or the local political bosses wanted. An alternative is to just reset the machine, causing that person’s vote to be lost. The third choice, which I saw done, was for a worker to reach inside the curtain, without looking, to press the button. Is this the best option? It is if the workers are honest—but are they honest? (A quick Google search suggests that some jurisdictions permit this if two poll workers of different parties do this cooperatively.)
Court orders: If someone believes that they are registered, but their name does not appear in the poll book they can cast what is called a provisional ballot. This is handled like an absentee ballot: the actual ballot is inside a secrecy envelope, which in turn is enclosed in an envelope with the person’s name and address. That permits later verification of their registration status. If it is determined that they are in fact, registered, the inner envelope is opened by someone else, someone who has not seen their name and address, and the ballot is counted. If not, the inner envelope is discarded, unopened. However, there is another possibility: you could obtain a court order, allowing you to vote on the voting machines. We were informed, in fact, that every judge in the county was on duty that day to handle such requests. One person, a young Black woman, came to us with a court order. How do we handle this? What do we write on the ticket? Where do we write the ticket number? The poll workers all got together to discuss this issue. She got rather agitated, thinking we were trying to deny her the right to vote on the machine, despite her court order, but we just had to figure out the proper procedure. Our eventual solution was to write on our copy of the court order "Court Order #1," write that on the ticket, and write the ticket number on the court order. That would provide the same sort of cross checking that an entry in the poll book would have. (Aside: given the racial issues in the election, for the first several hours of voting there was an observer from the ACLU to ensure that we were not trying to exclude minority voters. He was satisfied that we were not and left before this particular incident took place.)
Wrong person: Someone came in, gave us his name, and signed the poll book entry for that name. Later on, someone else came in, and gave the same name and address. (Generally speaking, we were legally barred from asking for ID.) A bit of inquiry let us figure out that this was a father and son, senior and junior. The father had signed the wrong line in the poll book and nobody had noticed. We eventually told the son to sign in his father’s slot. Arguably, he should’ve been told to cast a provisional ballot.
Voting While Temporarily Disabled
I’m temporarily disabled: I fell and fractured my shoulder about a week and a half ago. My right arm is in a sling; I can’t write. It’s election season in the US, so I wondered what the experience would be like casting a vote in New York City. (Aside: I wrote this post with the assistance of dictation software. It mostly works…)
The first step in voting is to check in. New York City uses electronic poll books. You can either tell the poll worker who you are, or you can display a barcode that you were sent by the Board of Elections. In fact, a mailing that you will receive from the Board will include a QR code that you can use to download an electronic copy of this barcode to the wallet app on your phone. Naturally, I prefer this option, so I don’t have to clutter up my wallet or keychain with a piece of plastic I will use about twice a year.
You then sign the poll book. In New York City, that’s done with a stylus on a tablet. The poll worker can then compare your current signature with what on file. I can’t write with my right hand at the moment. What are the provisions in New York State election law for such a situation?
They’ve thought of this, of course. §8-304(2) says that
if such a person claims that he or she is unable to sign his or her name by reason of a physical disability incurred since the voter’s registration, the board, if convinced of the existence of such disability, shall permit him or her to vote, shall enter the words "Unable to Sign" and a brief description of such disability in the space reserved for the voter’s signature at such election.That isn’t quite what happened. Instead, the poll worker I talked to initially filled out some form and conducted me to some other desk. At this desk, I had to show my barcode again, at which point the machine printed out the appropriate ballot for me. It is unclear to me why I had to go to this separate desk or why a form was used instead of following the explicit provision of state law. If they had offered me a provisional ballot instead, I would’ve offered to come back with an attorney. (Aside: when I used my phone again to display my barcode, the person at this desk said "you can’t sign your name but you’re tech-savvy?" I replied that I was a computer science professor who just happened to have an injured arm. I’m sure that people with more permanent disabilities get this sort of nonsense all the time. I’m contemplating filing a complaint.)
The next issue is actually casting the ballot: I do not think I could accurately fill in the bubbles on the ballot writing with my left hand. Again, this is something provided for in state law: I can have assistance in filling out the ballot. New York City, though provides a better option: a ballot marking device in every precinct. Without going into details—see the linked-to the webpage—the machines, which can accommodate many kinds of disabilities, read and scan a regular ballot and let you vote. They then print the appropriate markings on the ballot and hand it back to you. The machine was slow and annoying to use—it used a resistive touchscreen—but it did the job. It then took forever to actually print the marked ballot. Being the sort of person that I am, and knowing something of the failure modes of BMDs, I checked the marked ballot to verify that all of the choices were as I had intended. They were; I took the ballot over to one of the scanners and actually cast the ballot.
Overall, I give the city and the state an A-. The personnel were properly trained, and (except for the crack about tech-savviness) were quite polite, and all of the necessary procedures and hardware were there. Of course, I would very much prefer not to have to vote this way again, but I could actually cast my ballot in privacy without someone else’s assistance.
My Retirement Talk
I’m in the process of retiring, and although I will not be settling back in my rocking chair—I have lots of writing I want to do—I’m no longer teaching.
On April 30, I gave a farewell talk. If you’re interested, the video is here and the slides are here. (And you can always find both on my "Talks" web page.)
Brief Notes on Computer Word and Byte Sizes
This is not my usual blog fodder, but there’s too much material here for even a Mastodon thread. The basic question is why assorted early microcomputers—and all of today’s computers—use 8-bit bytes. A lot of this material is based on personal experience; some of it is what I learned in a Computer Architecture course (and probably other courses) I took from one of my mentors, Fred Brooks.
There are three starting points important to remember. First, punch card data processing is far older than computers: it dates back to Hollerith in the late 19th century. When computerization started taking place, it had to accommodate these older “databases”. Second, early computers had tiny amounts of storage by today’s standards, both RAM and bulk storage (which may have been either disk (for some values of “disk”!) or tape). Third, until the mid-1960s, computers were either “commercial” or “scientific”, and had architectures suited for those purposes.
Punch card processing was seriously constrained. Punch cards (at least the IBM type; there were competing companies) had 80 columns with 12 rows each. There was a strong desire to keep all data for a given record on a single card, given the way that data processing worked in the pre-computer era (but that’s a topic for another time). This meant that there was a premium on ways to compress data, and to compress it without today’s software-based algorithms. The easiest way to do this was to put extra holes in a card column. Consider a column holding a single digit “3”. That was represented by a single hole in the 3-row of a single column. There were thus 10 rows reserved for digits—but in a numeric field, the 11-row and the 12-row weren’t used. You could encode two more bits in that colum, as long as the “programming” knew that, say, a column with a 12-3 punch was really a 12 punch and the number 3 and not the letter C. Clearly, 10 digit rows plus two "zone" rows gives us 40 possible characters; a few more were added when things were computerized.
Let’s look at such computers. The underlying technology was binary, because it’s a lot easier to build a circuit that looks at on/off rather than, say, 10 different voltage levels. When reading a card, though, you had to preserve the two zone bits separately, because their meaning was application-dependent. Accordingly, they used 6-bit characters: two zone bits, plus four bits for a single digit. But you can fit 16 possible values in those four bits, not just 10, so machines of that era actually had 64-bit character sets. In a purely numeric field, the zone bits were used for things like the sign bit and (sometimes) for an end-of-field marker of some sort, but that’s not really relevant to what I’m talking about so I won’t say more about those. The important thing is that each column had had to be read in as a single character, more or less uninterpreted.
Representing a number as a string of (effectively) decimal characters was also ideal for commercial data processing, where you’re often dealing with money, i.e., with dollars and cents or francs and centimes. It turns out that $.10 can’t be represented in binary: 1/10 is a repeating string in binary, just like 1/3 is in decimal, and CFOs and bankers didn’t really like the inaccuracy that would result from truncating values at a finite number of places. (Pounds, shillings, and pence? Don’t go there!) The commerical computers of the day, then, would do arithmetic on long strings of decimal digits.
Scientic computers had a different constraint. They were often dealing with inexact numbers anyway (what is the exact diameter of the earth when computing an orbit), and had to deal with logarithms, trig functions, and more. Furthermore, many calculations were inherently imprecise: a Taylor series won’t yield an exact answer except by chance, and it might not be possible even in theory. (What is the exact value of π? It’s not just irrational, it’s transcendental.) But there were other constraints. Sometimes, scientists and engineers were dealing with very large numbers; other times, they were dealing with very small numbers. Furthermore, they needed a reasonable amount of precision, though just how much was needed would vary depending on the problem. Floating point numbers were represented internally in scientific notation: an exponent (generally binary) and a mantissa. There were thus two critical parameters: the number of bits in the mantissa, which translated into the precision of numbers stored, and the number of bits in the exponent, which translated into the range. (Both fields, of course, included a sign bit in some form.) Given these constraints, and given that commercial data processing, with its 6-bit characgters, came first, it was natural to use 36-bit words: plently of bits of precision and range, and the ability to hold six characters if that’s what you were doing.
That’s where matters stood when the IBM S/360 series was being designed starting in 1961. But one of the goals of the 360s was to have a single unified architecture that could do both scientific and commerical computing. There was still the need to support those old BCD databases, whether they were still on punch cards or had migrated to magetic tape, and there was still the need to support decimal arithmetic. The basic design was for a machine that could support memory-to-register arithmetic for scientifc work and general utlity computing, and storage-to-storage decimal arithemtic for commercial computing. This clearly implied a hybrid byte/word architecture. But how big should bytes be? One faction favored 6-bit bytes and either 24-bit or 36-bit words; another favored 8-bit bytes and 32-bit words. Ultimately, Brooks made the call: 8-bit bytes permitted lower-case letters, which he foresaw would become important to permit character processing. (Aside: Brooks, apart from being a mensch, was a brilliant man. It’s sobering to realize that he was appointed to head the S/360 design project, a bet-the-compay effort by IBM, when he was just 30 years old, and this was just after his previous project, the 8000 series of scientific computers, was canceled. I wasn’t even out of grad school when I was 30!)
The reduction from 36 bits to 32 bits for floating point numbers was challenging: there was a loss of precision. You could go to double-precision floating point—64 bits—but that cost storage, which was expensive. In fact, 8-bit bytes were also expensive: 33% more bits for each character. (IBM did many simulations and analyses to confirm that 32 bits would usually suffice.) But Brooks’ vision of the need for lower case letters has been amply confirmed. (Other character sets than the American Latin alphabet? Not really on folks’ radar then, which was unfortunate. But it would have been hard to do something like Unicode back then. The lowest plane of Unicode is based on ASCII, not IBM’s EBCDIC. Many people within IBM wanted to go to ASCII for the S/360 line (there was even support in the Program Status Word for ASCII bytes instead of EBCDIC ones when dealing with decimal arithmetic), but major customers begged IBM not to do that—remember those pesky zone punches that still existed and that still couldn’t be converted in a context-independent fashion?)
8-bit bytes have other, albeit minor, advantages. If you’re trying to create a bit array, it’s nice to be able to lop off the lower-order 3 bits and use them to index into a byte. But Brooks himself said that the primary reason for his decision was to support lower-case letters. (Aside: Gerritt Blaauw, one of the other architects of the S/360, spent a semester at UNC Chapel Hill where I was a grad student, and I took a course in computer design from him. There were rumors in the trade press that IBM was going to switch to 9-bit bytes for future computers. I happened to overhear a conversation between him and Brooks about this rumor. Neither knew if it was true, but they both agreed that it would be unfortunate, given how hard they’d had to fight for 8-bit bytes.) USASCII fits nicely into 7 bits, but that’s a really awkward byte size. The upper plane was used for a variety of other alphabets’ characters. That usage, though, has largely been supplanted by Unicode. What it boils down to is that every since the S/360, there has never been a good reason to use a byte size of anything other than 8 bits. On IBM systems, you have EBCDIC, an 8-bit character set. On everything else, you have ASCII, which fits nicely in 8 bits and was more international.
Word sizes are more linked to hardware. The real issue, especially in the days before cache, was the width of the memory bus. A wide bus is better for performance, but of course is more expensive. The S/360 was originally planned to have five models, from the low-end 360/30 to the 360/70, that shared the same instruction set. It turns out that the 360/50 was a sweet spot for price/peformance and for profit—and it had a 32-bit memory bus. If you’re trying to do a 32-bit addition, you really want the memory operand to be aligned on a 4-byte boundary, or you’d have to do two memory fetches. 32 bits, then, is the natural word size, and the size of the registers. You could do half-word fetches, but that’s easy; you just discard the half of the word you don’t want. A double-precision 64-bit operand requires two fetches, but on a higher-end machine with a 64-bit bus it’s only one fetch if the operand is aligned on an 8-byte boundary. And on the IBM Z series, the modern successor to the S/360? Words are still 32 bits, because the nomenclature is established. A pair of 64-bit registers together is said to hold a “quadword”. That is, what a “word” is is was defined by the original history of the architecture; after that, it’s likely historical.
