The second half of the chapter was much more straightforward, but still rather interesting.   The main goal of this chapter was to explain and illustrate the concept of recursion and show how it appears in life.  Prior to this reading, I identified recursion mostly as a specific programming technique where a function calls itself, (and also as a technique for animated GIFs).  Hofstadter set out to explain recursion both in and out of the context of programming.  He explains how the computing concepts of pushing, popping, and stacks within recursive processes appear in music.  He also shows how language is recursive and where recursive patterns appear in matter.  Recursion is not just “a function that calls itself,” but a much broader concept of a certain repetition that appears all around us.  It can even be somewhat subjective.

One recursive pattern I find interesting is how it’s said that the structure of atoms resemble that of our solar system.  It reminds me of the closing scene of Men In Black, which struck me as a kid: the camera zooms out to show our galaxy as one little marble of many galaxy marbles being played with by aliens.  Awesome.

I was expecting the second piece of our reading, Firewalls and Internet Security  to be just as technical and dull as the previous, however the I rather enjoyed this reading it was interesting to read about to predict actions taken by users. The theory being discussed in this book has been in use for thousands of years, now we are just applying it to computing and the Internet. It is nice that in the introduction they give a run down of all the major ideas on security, a notable one is “don’t underestimate the value of your assets”. I think this is a great point the books starts off with, and even I can think of a time or two where hacker went onto someone’s network and took something the host thought didn’t’ matter, unfortunately the victim realized to late that the data taken did matter. Throughout the reading I realized this tug of war between one side and the other will continue for a long time to come.

Knuth’s description of algorithms is perfect and simply timeless: they are, as he describes, just like a recipe, and they must be definite and clearly defined. The emphasis on finiteness, definiteness, input, output, and effectiveness is brilliant and still spot-on.

And, now I will spend the rest of this post on the random number generation chapter. This chapter was incredibly interesting on an intellectual level because random numbers are incredibly strange, impossible to grasp concepts, and yet we deal with them (or something resembling them) all the time – in reality and, of course, in programming. As Knuth points on, simply for the sake of ascetics we need them – a touch of randomness really works wonders. And yet, that touch of randomness is incredibly difficult to obtain.

I already knew that computers use pseudo-random methods – ussome sort of algorithm to generate numbers that appear random but that are actually based on some complex calculation, but that, for all intents and purposes for the user, are random. I did not know the depths of those procedures, or the complications involved, until this reading. Simple as it is, I really like the example at the beginning of taking 10 digits, squaring the number, and taking the middle ten digits as something pseudo-random. It’s too simple, but clever, too.

One quote I find interesting: “Intuitive hunches are no substitute for rigorous mathematical proof. If we are willing to do more work – say 100 or 1000000 times as much – we can obtain sequences for which substantially better theoretical guarantees of randomness are available.”

What really struck me was not just the details on the mod procedure to find a random sequence, but the many, many tests designed to determined just how random a generated sequence really is, the myriad effectiveness of these tests. I had no idea of the extent to which simple testing was an art in random number generation.

I also really like the comment that as humans, we are incompetent in testing for random numbers (and generating them). We refrain from putting the same numbers next to each other – though this happens – and we find patterns even in random numbers. This ties into another interesting point in this chapter: a truly random sequence will exhibit nonrandomness. What a perplexing idea.

The other aspect of this chapter that really intrigued me was the philosophical attempt to define what a random number is, and the difficulty associated with this task, especially for a nonrandom sequence of numbers. Also, pi is so cool – I never knew of th weird patterns at work inside of its sequence of numbers, and I love the line that it is conjectured that pi is infinitely-distributed, but nobody has been able to even prove that it is 1-distributed.

A lot of really cool ideas in here. I guess what I take out of it in terms of coding is a deeper appreciation for what happens behind the scenes; when we type a simple-looking random function, we’re invoking something much deeper and much more complex, and still only generating an illusion of randomness. That’s something to think about next time I innocently try to simulate a coin toss or some such equivalent.

Networks and security! These aren’t areas where I’m particularly knowledgeable, so these readings were both new and confusing. For the TCP/IP Illustrated, it was interesting to delve a little bit into the actual coding and structure of networking, subjects on which I am woefully ignorant. For instance, the three layers that networking code is organized into: socket, protocol, and interface – who knew? Also interesting was reading the way information is handled – that the UDP output occurs through sendto calls here, where the datagrams are placed on an input queue where interrupts are scheduled to execute the IP function – it’s very interesting to think of the various interrupt levels, with various priorities. Completely new to me. The diagram was also pretty cool.

Thinking less about coding and more about the general idea of security in the Firewalls and Internet Security book was quite fun. A lot of quotes from here struck me: “Programming is hard,” by Dijisktra, citing the impossibility of making something perfectly secure; “A program or protocol is insecure, until proven secure”; “Security is a trade-off with convenience.” A lot of the points in here made a lot of sense, and put clearly into words ideas that should be obvious: what resources are you trying to protect? Who is interested in attacking you? How much security can you afford? Above all, this really built up the importance of firewalls as a good balance in security and functionality. And, of course, layers – multiple layers. You are only as strong as your weakest link.

Also interesting looking at encryption and the point that it is not the answer to all our problems because, as it is so well put, “You don’t go through security, you go around it.” I enjoyed the chapter about the various types of attacks. The bit on password theft was fun and thought-provoking – we all use passwords, all the time, so it is interesting to read about the deeper analysis behind how effective a password is (not terribly, generally). Also, I never heard of Denial-of-Service attacks, but sheesh, they seem nasty, and I’m glad I read about them.

My favorite section of all was the chapter about “Berford,” simply because it was fascinating to look at the process through which one attempts to deal with a hacker and the battle of wits that almost ensues – it really feels like some sort of information duel, a sword fight in the modern age. Yeah, that sounds geeky. But it’s interesting observing that struggle of wits, and the idea of creating a “jail,” allowing him certain access in a controlled way. Moral of the story: be prepared. Got it.

Examples of this more subtle type included demonstrating recursion and stacks by creating a story about The Tortoise and Achilles’ adventures where they dove into stories within stories (in which he also managed to include metaphors of musical stacks with tonics and pseudotonics) and explaining linguistic recursion while simultaneously including examples of the types of German sentences containing recursion.

His explanation of the difference between recursion and infinite regress or paradox was well stated; “A recursive definition (when properly formulated) never leads to an infinite regress or paradox. This is because a recursive definition never defines something in terms of itself, but always in terms of simpler versions of itself.”

He picks this up again later in the section “’Bottoming Out’ and Hierarchies” when he further points out that; “This is the crucial fact which distinguishes recursive definitions form circular ones. There is always some part of the definition which avoids self-reference, so that the action of constructing an object which satisfies the definition will eventually ‘bottom out.’”

My favorite part of the reading was towards the end, when Hofstadter spoke about the special task of a computer programmer- “to perceive when two processes are the same in this extended sense, for that leads to modularization.”

I love the “ah-ha!” moment that comes when noticing a pattern in what you’re programming that allows you to make the code more intelligent and aesthetically pleasing.

Excellent final reading assignment!

I am a computer.

More accurately, my brain is a computer, and I am the computer bundled with its peripheral, the body.

Just like a computer, whether in music or language or math, I recurse, call routines and subroutines, manage data.

I am made of neurons, little things that can be turned on and off by the same thing. It may not be traditional computer architecture, but it is a computer.

All of this strikes me as extremely profound somehow, suggesting that I have a certian purpose, a certian destiny and program to execute. I have billions upon billions of lines of code left to execute in my life, many of which involve writing more code. I become giddy when I dream of the prospect of programming personalities, of sitting down in front of a text editor and letting thoughts and emotions and opinions and all the fundamental necessities of humanity flow from my fingertips into my creation. I can become the recursive human being, a human being creating a human being creating a human being, etc.

Even more exciting is the idea that, as a computer capable of programming, I might be able to program myself. We know this better as learning, but all it is is forming new rules, rewriting code, tweaking functions, fixing bugs. The idea of Stefan 2.0 or Stefan 7.3 or any version greater than myself is exciting. What will the new version, this version wonders, think of this or that. Will there be new features, will these bugs ever get fixed, can I at least skin the interface? I can become the human Singularity, programming a better me who in turn programs a better me who in turn programs a better me, etc. I achieve infinity there, at the place where I improve, evolve, and change.

I’m sorry, I’ve been awake for far too long and coding far too much. I hope you gained something from this. I know I certianly did, even if it is hard to put into words.

The section on data types was more familiar to me, but it was nice to see all my old friends, the Boolean, the string, the integer, broken down and examined at a more basic level. I sometimes try to imagine what life was like before arrays and other complex data types. It’s hard to imagine.

I’m sorry for the rambling nature of this response, but I’m questioning whether I would be as technically inclined as I am today if I didn’t have the tools I do now. Could I have survived as a programmer in the world of my BYTE magazine? Am I a worse person or a worse programmer if I admit that I probably couldn’t?

The other reading, Firewalls and Internet Security, was a little more fun to read.  I was expecting it to be much more technical.  The introduction laid down all of the basics of security, most of which were not computer-specific, but universal principles about security.  I was expecting this reading to tell you exactly how you need to set up your machines so that they are as secure as can be, however it did not do this at all.  It began by stating that the level and types of security you should employ are dependent on your situation, and more specifically, the value of the information you’re securing.  There’s no one catch-all solution.  The reading went on to explain numerous different types of security holes and how to prevent them.  I like that this reading had sort of a faint social aspect to it, something you don’t often see in technical computer books.  Here you’re not working to prevent bugs in your code, you’re working to prevent other humans from accessing your information, whether it be some pesky teenager in another country or the guy who works the night shift watching the servers.

The second section was quite a bit less entertaining to read, but it was also considerably clearer. I’m already familiar with recursion as a whole, as a concept, as a technique, etc. What I took out of this reading wasn’t so much the idea of recursion in programming, but rather the unexpected applications recursion finds in completely strange places. I never thought about recursion in other terms before besides an occasional technique in programming, often with applications in number theory or some similarly abstract math realm. Exploring recursion in physics, however, and in chess, was really insightful and eye-opening. I was most astonished in thinking of our very language as following a recursive structure – I never realized it before, but it completely does. Even as I type this I am now painfully aware of how often I am using recursive structures in my sentences, something I never thought about before. Really wild.

Overall a really interesting reading; I feel like I’m taking things I already knew about algorithmic thinking and seeing them increasingly around me, in all sorts of unexpected places. This was also probably the most clear explanation of recursion I’ve ever seen.

In terms of the specific sections we read, I’m listening to “Little Harmonic Labyrinth” right now for some context, so I’ll talk about that one first. The Achilles and the Tortoise story was cute, but buried beneath all the punning there was a lot of really great stuff. The way the story ends one layer below where it started, like the recording of “Labyrinth” in the story, was a nice touch. I find it interesting the Western classical tradition really just uses mathematical systems, like counterpoint, to manipulate emotions in the listener. Masters of theory, from Bach to the Beach Boys, have always utilized the rules and equations of music theory, because they make things sound good. The difference is that the Beach Boys had 300 extra years of musical “systems” to draw on, not to mention all the other technological and cultural advancements over that time.

The essence of recursion, which Hofstader used this whole section of narrative to introduce, was captured really well by the GOD dialogue between the dimension-jumping companions and the Djinn. Recursive loops, as I understand them, are questions that include themselves in their answers. So, GOD stands for GOD over Djinn. The golden ratio is 1+1/(1+1/(1+1/1+…))) There’s no end or ultimate solution to a recursive loop, but at the same time there is a constant in that the equation always remains. In a way, recursive loops are the most powerful questions for that reason: they define themselves. Recursive loops are mirrored in all aspects of reality. Life is cyclical, sure, but not circular. It’s a spiral. You always end up back where you started, but with a little more information, and a new vantage point, but the question keeps pulling you on, whatever the question is.

“5 o’clock in the morning, life doesn’t seem to be the same. It’s beautiful, beautiful, so remember, remember.” – The Millenium

Particularly cool was the “Recursion at the Lowest Level of Matter” section, where the diagrams were most helpful in explaining what was going on, even though they were merely squiggles.  In fact, all the diagrams and graphs were incredibly interesting.  Recursion was something I hadn’t actively applied to particles, but the idea that no particle can ever be referred to without referring to other particles is very accurate.  

Hofstadter’s Law was funny (with its own little bit of recursion), but accurate, and reminds me both of my job and of the software management studies that I’ve been doing lately.  It is so true that nothing is ever done on time, and you can’t even fix that by knowing or guessing that it won’t be done on time.  

There has been a theme in some of the readings of programming, algorithms and programming languages being compared to the type of languages that we communicate daily with.  The programming language to communication language comparison is easy to see, and is touched upon is this book.  I’d obviously made the connection before, but I had always thought about it as translating how my “primary” language (English) converts to a secondary language (X programming language), instead of the other way around and thinking about how to apply terms that work for the secondary language (like stacks and recursion) to my primary one.  I think it is especially interesting that spoken language, kept in the memory of a human, requires stacks to be small and concise, while programming stacks, stored in the memory of a computer, can be very large and still effective and expressive.

“The Little Harmonic Labyrinth” is my favorite dialogue after the “Crab Cannon” and ever since I read it I think about it in various situations. In calculus, the popping of Achilles and the Tortoise in and of various stories reminds me of derivatives and integrals; “popping” in and out of various levels of an equation. I enjoyed most his example of recursion in physics, specifically dealing with subatomic particles. I thought it was very interesting the way he talked about defining electrons, protons and neutrons with respect to each other. Another physics example that Hofstadter did not bring up is electromagnetic waves. An electric field is caused by a changing magnetic field and a magnetic field is caused by a changing electric current or field.

As interesting as I find the various examples of recursion in science, math and language the most pertinent part for this class was at the end of the chapter where Hofstadter discussed the role of recursion in computer science. He starts about by defining ‘modularization’, the breaking up of a task into natural subtasks. He then goes on to discuss how this leads to loops; instead of writing out a sequence of operations a programmer can tell the computer to perform those operations and loop. When I first read Godel, Escher, Bach I did not have any computer programming experience so it is very interesting for me to read this now that I have experience with C.

Another small thing that I noticed is the way that Hofstadter formatted and organized the story is similar to how code is formatted. When Achilles and the Tortoise pushed into a different level the story was indented. Similarly, we indent in a program when we place an instruction inside a larger instruction. While this may seem like a petty thing to bring up, it reminds me of many of our previous readings that made a point to emphasize style and clarity of code. It is interesting to me that Hofstadter wrote the “Little Harmonic Labyrinth” in a style similar to code and then wrote about recursion in programming later on. It seems that as well as organizing his dialogue he was giving a subtle indicator of what he is going to discuss later.

1. Distinct versus similar recursive elements: I found this to be by far the most interesting point, mainly because I have run into this issue many times before: when you are dealing with distinct iterators, there is a clear difference between their purposes, and therefore, it is much easier to keep track of which ones are running when, and what they are doing. In short, life is nice and simple, and you don’t have to worry so much about remembering placement. When they are similar, or perhaps even exact, things get complicated. Life gets tougher, because you have to understand the structure instead of the roles; I feel like when youre using similar recursive elements, the recursion itself isn’t as important as much as the structure its in; they are riding the structure of something rather than determining it, and that makes things a lot more complicated.

2. The best possible option: this has always fascinated me: chess has this all the time, and i remember last year trying to get the move decision part of the program working as a very frustrating yet engaging time; within the first few steps of the program, the hardest part becomes determining what option is best, and doing so to a point where it actually is the best possible move. To me, the key point here is you must remember the best so far, and the value attributed to it; after that the most important thing is finding the structure so that all points are met. but, we also want to do it with pruning, and that’s where it gets interesting: when do we decide that an entire branch is worthless?

Had to say that.  But no really, I thought this acid-trip of a reading was really quite fascinating.  I really enjoyed when Hofstader showed that stacks and recursion existed in language.  I had never thought of it, but they do; in English, we put the adjective before the noun, as in “the big black spider”.  We don’t know what “big” and “black” refer to until we get to “spider”, at which point we “pop” the adjectives and then apply them.  The opposite occurs in French, where they generally put the adjective after the noun – for example, “l’araignée noire”, translated “the spider black”.  They put the nouns in a stack and then pop them out.  Even more confusing is when more than one adjective is used, as they are then generally split around the noun (for “auditory beauty”, as they tell me): “la grosse araignée noire” (translated, “the big spider black”).  And then there is the accord of adjectives to nouns, which requires one to navigate the complex grammar of French to figure out which noun the adjective is referring so to be able to accord it in gender and number.  Whatever.

I suppose that recursion occurs in everything.  Take cooking for example; as you prepare each step of a recipe, you can, at the end of the step, stop and clean whatever you’ve dirtied in the course of the preparation.  But nobody does that; rather, you wait until the end and clear everything.  Each ingredient pushes you deeper into the recipe, then each step that combines these to the final product pops you up a level; but at the end, you still have the loose ends: the dishes.  Or a phone system full of angry callers on hold.  Or a never-ending “to-do” pile.  Or a series of terrible puns.

That said, Hofstadter’s writing is much stronger when he’s doing critic work. Where the dialogue shows recursion in an amusing way, the chapter explains the concept clearly. I wasn’t familiar with the term “infinite regress” but now understand that it refers to the infinite doubling of a function that does nothing but call itself. He clearly defines non-destructive recursion as a recursive function that, while one or many of the possible results of the function would lead to a recursive call, there is at least one path that will break out of the function, thereby eliminating the possible of infinity, which while fun to think about is terribly frustrating in any practical application.

The idea of indirect recursion also caught my attention and reminded of the deadlock we looked at in class. There, neither function one its own would have reached infinite regress but, when they were fighting over shared resources, they got stuck in a sort of indirection recursion where each function called the other but didn’t have the authority to change any variables, which meant that the next time it called the other function the exact same process repeated itself. It’s not exactly recursion because the functions weren’t directly calling one another, but in that instance the result was the same.

Speaking directly of computer programming, it is interesting to think of a loop as a recursive process. Now that he points it out the connection is obvious, but I hadn’t noticed it because in a for or while loop there is a conditional built into the syntax. However, this is merely shorthand for a simple loop that has a condition to break just above a branch to the top of the loop.

As for his claim that intelligence is can be thought of as a series of functions that can reprogram themselves, I don’t know what to think. But I’m sure that it is exactly a case of recursion. A function calling a function is definitely recursive, but a function rewriting itself seems like something else, maybe meta-recursive since it affects the function that is calling itself…

In the next chapter they discuss a newscaster playing a recording of which has a recording which has a recording in it. It really made me want to make people read this who quote people quoting people in the BFP, they can never get their punctuation correct, or maybe that was just the bater article. When discussing recursive transition networks, it reminded me of graphing sentences in elementary school, but also of how one writes a parser. Later he mentions that a friend thought the graph of an infinite of infinite as a “picture of God,” which may have been his basis of GOD in the previous chapter. It’s kind of like when Dr. Matrix “observed that pi, when correctly interpreted conveys the entire history of the human race.” The fact that no particle can be described without describing every particle which throws you into a beautiful infinite loop, also follows a similar vein.  We’ve been looking in mathematics of the fundemental laws at particles in a magnetic field, it is interesting to think about that math being effected by also being in a crystal.  Also in a previous reading it was mentioned that we can do the mathematics for catching a ball in our heads without knowing it, is similar to being about to do the math in musical compositions without understanding it. There are so many things that are brains do that we aren’t aware of.

Wow, reading TCP/IP Illustrated, Volume 2 made me (A) feel stupid and (B) think I should really read Volume 1.  I didn’t really understand much of it, but there were two things that struck me.  The sections on memory were cool, since they are so utterly close to all the memory diagrams and exercises we do with Joe.  Also, the big diagram in Introduction 1.11 showing the communication for input and output was fairly understandable.

The absolute best part of Firewalls and Internet Security was the part in the preface which I happened to glance that said “IT IS OK TO SKIP THE HARD PARTS” in bold letters.  Other than that, it was still a very enjoyable read and reiterated some of the things I’ve learned about security before.  The part about how keeping your security all at the same level was brilliant common sense and reminded me of how, when selecting hardware components for a computer, a computer will only be able to perform as well as its slowest/worst part.  And how, in a raid of 25 World of Warcraft players trying to kill a dungeon boss or a soccer team, the group will only perform as well as its weakest player.  Clearly, a lesson that transcends security alone.  “Security through obscurity” is a great phrase but, I agree with the writer, a bad idea solely on its own.

“What are you protecting?” and “Who wants to attack it?” are, in my opinion, the fundamental questions when designing security.  If you’re not likely to be attacked by more than a middle schooler who’s seen Hackers too many times, you can obviously lessen security to lessen costs.  For example, I live in an apartment building and have a secured wireless network.  Most people have internet here, and there is even free internet in the café downstairs.  My WPA password is a seven digit string of numbers and letters designed to be easy to remember.  I did it his way because I’m confident that most people in the building won’t bother with a network that isn’t their own anyway.  The few people (residents or guests) who might be looking for a network to join will probably be deterred by the little lock next to the network name anyway.  The percentage of people left that will make an active effort to hack into my system is negligible, considering I have nothing that needs protecting, per se, and am only concerned with maintaining my bandwidth.

At the same time, the muti-million dollar company that I work for has two separate departments (one on the IT security side and one on the information security side) whose sole jobs are to provide the layers of security we use across our networks and world-wide offices because we deal with very private employee information and very private client information about stocks and trades.

The reading this week is from Gödel, Escher, Bach: an Eternal Golden Braid by Douglas Hofstadter. Read “Little Harmonic Labyrinth” and chapter 5 “Recursive Structures and Processes.” Together they comprise pp. 103-152. I read this book when I was in high school and to say that it changed my life is an understatement. I encourage you all to get this book for your personal library and read it over the summer. (Note that the author is related (cousins (I think)) to Dan Hofstadter.)

Preface:

I like the approach of starting bottom-up, since this is how I’d construct it in my mind when trying to understand. For reference:

“Bottom-up approach to the TCP/IP protocol suite, starting at the data-link layer, then the network layer (IP, ICMP, IGMP, IP routing, and multicast routing), followed by the socket layer, and finishing with the transport layer (UDP, TCP, and raw IP).”

It was interesting to go into detail about IP APIs (“Two APIs for writing programs to use Internet protocols are sockets and TLI.” (p5)). The discussion on system calls and library functions was the most enlightening. To the user, the difference is not as a critical, but to the implementor, the difference is fundamental.

For example, using send vs. sendto: “The advantage in implementing send as a library function that jsut calls sendto is a reduction in the number of system calls and in the amount of code within the kernel. The disadvantage is the additional overhead of one more function call for the process that calls send itself.” (p8)

Something in Section 1.15 that brought to mind our in-class discussions on interrupts: “When an IP datagram is received by a device driver, the datagram is placed onto IP’s input queue and a software interrupt is scheduled to cause the IP input function to execute. …Since many of the networking data structures are shared by different layers that can execute at different interrupt priorities, the code must be careful when accessing or modifying shared structures.”

This makes me wonder about the best way to make notes to yourself as a programming when you get into building more and more complex programs. The programs I’ve written so far are nowhere near the size of the massive ones I’ll make in the future when I spend years working on certain programs. I’ve been curious lately how well I’ll be able to store the whole program in my head or how I’ll make notes to myself to remind me of the infinite interrelations between all of the elements I’m working with.

Read the Introduction pp. 3-18, chapter 5 “Classes of Attacks” pp. 95-118 and chapter 16 “An Evening with Berferd” pp. 287-299.

Introduction:

A striking metaphor paired along with one of the security truisms:

Truism: Keep the level of all your defenses at about the same height.
Metaphor: It makes no sense to fit a bank vault with a screen door in back, yet we have seen equivalent arrangements on the Internet. Don’t waste time and money on one part of your defenses if other parts have glaring weaknesses.

I’m always on the lookout for rules of thumb, to get a sense of what’s considered the norm in any discipline or area, and the authors of Firewalls and Internet Security state:

“We like crucial security programs to be about a page long. Huge security-sensitive programs have been a constant and reliable source of security problems.” (p5)

That’s an impressive benchmark, considering how those programs have to do something extremely important and distill that into such little code.

What’s fun to read about this book is the intelligent questions and the lack of clutter. In the “Picking a Security Policy” section there are three and only three main questions to consider; “What resources are you trying to protect?”, “Who is interested in attacking you?” and “How much security can you afford?” Intelligently, each is dissected from more than one angle- the third for instance isn’t just a financial question, it’s also a matter of time and convenience.

“If you do not make explicit decisions, you have made the default decision to allow almost anything.” True for more than internet security!

Chapter 5 “Classes of Attacks”:

Terms like “least privilege” and sentiments like “…It’s harder to understand exactly what it means for a system to be ‘securce’ – you have to know what it’s designed to do as well,” are reinforced in this chapter, along with details of various types of attacks and ways to think about and confront them.

At this point I don’t have any immediate use for knowing types of attacks, besides finding them interesting in terms of strategic thinking and future planning, so there’s less for me to intelligently comment on this section.

An Evening with Berferd:

This was a good story to follow, especially being able to see how the security professionals created an invisible monitoring machine to get more clues on Berferd (catchy nomenclature). Given that Berferd was convinced by some noticeable hints, like the disgarding of the no ps command rule and the unconvincing nature of the Jail, I would have been bolder about trying to lure Berfered into revealing more about himself somehow. Agreed though, “Damange control is much easier when the actual damage is known,” so logging his activities was a decent start.

Imagine a city. Gleaming corporate skyscrapers and vast, air-conditioned apartment buildings rise high above seedy streets littered with want ads and lined with ramshackle storefronts. Here and there, great open expanses, areas of free expression for one and all, parks and galleries, form the spaces in the great solid mass of the city. If you look hard enough, you can find the older city, venerable museums, shuttered old landmarks, and industrial-looking complexes of pipes and humming steel boxes. It is from those last places that you can descend into the depths below the city, a place forgotten by all but the architects who created this place and who continue to expand it. Endless miles of tunnels, cryptic signals barely readable to humans, and ancient, poorly-built foundations are connected by these dark spaces, the world below HTML, the raw TCP/IP itself.

We live more and more in this city, and the knowledge that I so poorly understand it fills me with kind of a mix of amusement and shame. Admittedly, I’m a step ahead of most Internet users, but I still sometimes can’t fathom that the Internet works. As a programmer, it seems counter-intuitive to me – the core of the Internet is so ancient and primitive it makes me shudder. Joe’s famous SMTP demonstration, the forbidden lore of spoofing, has always really brought home how much we take for granted a system never designed to integrate the very features we rely on it for.

For example, any one of you could break up with my girlfriend while I’m in class tomorrow. All you’d have to do is spoof my email, and she’d trust, just because that name is there, that it’s me on the other end of the line. Sure, it’s a problem that would last all of an hour, but that trust, that fundamental security flaw in my relationship, is there all the same. Consider the example of one of my friends, a shy girl who’s Internet use tends towards LiveJournal as opposed to more conventional social networking sites. All it took for here to develop a wild reputation was for one classmate to create a fake Facebook profile. We rely on the Internet so profoundly, not just as a tool but as a definition of our very identity (sup /b/) to the point that being unable to understand it pretty much renders us helpless in the face of someone with superior power over it.

And that power is not easily acquired, either. Sure, anybody can use Dreamweaver, but consider this – CSS and JavaScript are implemented on top of HTML which is implemented on top of TCP/IP. We have three separate systems to do pretty much the same thing, because we couldn’t be arsed to update our existing system and make it easier to use – and there will be more layers to the Internet, something on top of CSS to make prettier web-pages faster and easier to create. Does anybody remember Internet 2.0? Not Web 2.0, but that weird little college network with the crazy protocol and the crazy bandwidth that several news articles assured us was the future? I sure don’t. Because it was easier just to write a wrapper over what we had than to truly update it. Not that this is a bad thing – rewrites are bad, I know, but I still think the Internet is a miracle in some way.

One final tale before we part. 4chan, my district of choice in the great wide Internet, was taken down about a week ago by a massive DDoS attack. The way in which this attack was accomplished was very clever – someone posted a Trojan on 4chan. This trojan did two things once it infected a machine. First, it would post itself on 4chan every so often. Second, it would wait for a predetermined signal. We dismissed it as a spambot, even as the number of posts grew, and it was only when the signal went out and a massive botnet attacked the site that anyone realized what had actually happened. Through the social power of the Internet, some clever person got 4chan, famous for its attacks on other sites, to DDoS itself.

I guess if there is a conclusion to be drawn here, its that understanding of the Internet and of hacking can become instant social power these days. And that the Internet is constructed in such a way as to leave plenty of room for all kinds of stuff to wiggle between the layers and create chaos. I wonder what will happen next.

So I suppose the lesson is, security risks aren’t just foreign governments anymore.  I knew nothing about computers and I was able to access a mainframe machine with a few clicks; a few more and I could have disabled the system.  I really liked how this was addressed in the reading, that you are trying to shield yourself from a wide variety of security risks.  I also liked how they quickly deconstructed pretty much every OS available today; they’re all fancy and such, but when it comes down to it, there’s still a text file somewhere (encrypted or not, encryptions can be broken) that has your passwords.  And remember how easy it was to create a home network?  Yeah.  And you know how you’ve got that built-in social networking protocol that shares files and printers too?  Yup.  All major security risks.  And that’s why I don’t keep government secrets on my computer (also, they won’t trust me with them.  Something about Canadian descent they don’t like).

One section I found particularly interesting was the description of how passwords work and how they are attacked. It makes sense that there is a file somewhere on a server that lists the passwords of the system it runs, but I had never thought about it before. It’s obvious really; if you have a password it has to be checked, which means it must be checked against something. Still, that seems about as secure as keeping a copy of the key to a safe inside the safe. The thief still has to get in there in the first place. The method that caught my attention was the thought-experiment example of setting up ten windows that watch the input screen and then having your program run all the possible final digits before the user makes his final keystroke.

In this example lies the major difference between computer hacking and physical thievery: the attacker isn’t just trying to get into a computer, but is using a computer to do it, which means s/he can use methods that take advantage of computers being really, really fast. This is also the case with denial-of-service: you flood another computer either by being faster than it or by using a network of slower computers that, once put together, are faster.

As for the TCP/IP reading, what I found most interesting was how the author’s went about presenting their code. The task of presenting 15,000 line of C in a readable fashion is mind boggling, but they seem to have set up a very fine system for it. The design of using different fonts and typefaces to distinguish different parts of the code makes it much easier to read (at least in the example we looked at). I particularly liked the indented smaller font for historic details. It was a much sleeker way to incorporate the information than footnotes or appendixes would have been; it made the information easily accessible but unobtrusive.

The layout of how they go about explaining the various chapters of the book is really cool; instead of just starting at the top, they follow the entire architecture from the ground up; it makes sense, It’s just that I almost always go through my programs in chronological order.

As for the other book, Firewalls and Internet security, I found the most interesting part to be the introduction. The various maxims that they wrote out were very clear, and made a lot of sense as far as security goes; the metaphor of a castle wasn’t necessarily perfect, but was very interesting nonetheless. The authors approach security with the understanding that this is one of the most fundamental aspects of any infrastructure, and that it has indeed been with us for millenia. A common theme of the maxims that I noticed also followed a common theme with programming in general: A program, or in this case, a security regimen, should exactly fit the needs of the users, no more, no less. With security, as with programming, there is a balance that has to be met; the problems and cost of getting it wrong on one hand, the difficulty and incomprehensibility of something being too perfect on the other, not to mention speed reductions. All of this is something I’m going to take away with me as I get ready for my class at Williams next term on building a p2p network.

The reading this week is from two books on networking. The first is TCP/IP Illustrated, Volume 2 by Gary R. Wright and W. Richard Stevens (known as “the Stevens book”). Volume 1 explains TCP/IP (and you should read it); volume 2 is the annotated source code of the reference implementation. Read the Preface pp. xix-xxii, Introduction pp. 1-10, 26-30 and check out the inside front and back covers.

The second reading is from Firewalls and Internet Security by William R. Cheswick, et al. Read the Introduction pp. 3-18, chapter 5 “Classes of Attacks” pp. 95-118 and chapter 16 “An Evening with Berferd” pp. 287-299.

So what does Tufte have to do with game design?

Just about everything. Think of it this way – a game is, at base, nothing more than a flatland display of some quantitative information that updates in real time. Sure, it’s not a chart or a graph, but it’s an informational display all the same. Thus, Tufte’s maxims of good data visualization can be directly applied to games.

Consider graphical excellence. According to Tufte, this is displaying the data such that significant points are immediately apparent. Nowhere is this more critical than in games. Consider the following two displays:

Where's the game, guys?

This is Shadowcaster. As you can see, it does an incredibly poor job of emphasizing the important parts of the game – even with this modified display, the game world itself takes up around 9/16 of the screen. In the default display (which I was unable to find a screenshot of), it takes up more like 1/9 of the screen. It’s a sign of poor game design if your player gets mauled by monsters while he’s busy admiring his completely superflous character portrait, or hunting for some kind of meaning in blank inventory slots that won’t get used until later in the game.

Behold, Fallout.

This is Fallout 3, a modern game in the same subgenre, and here we can see adherence to Tufte’s laws of visual excellence – observe that the game world takes up the majority of the screen, with significant objects therein highlighted for the user’s convenience. Also, note that only the most critical gauges are displayed, in contrast to Shadowcaster. The game even makes good use of color – indicating data immediately relevant to the player’s current task (in this case the remaining health of the hated Super Mutant Behemoth) in red, in contrast the green of the rest of the display.

In short, it is essential that as game designers, we employ all the methods at our disposal to focus the player’s limited attention on significant events in the game world, and to leave as much minutiae as possible in the background. I don’t think Tufte would have it any other way.