Category: computer

The presenters from the Jericho Forum at DEFCON 14 this year did an acceptable job of highlighting the principle that border firewalls are much less beneficial that they used to be for security purposes. WiFi, VPNs, MANETs etc. provide constantly changing IT environments which are not realistically plausible for IT to completely control. Our new challenge is to accept that hostile things may exist on the network, and we must solidify the security of individual services despite high-priced blue-colored networking hardware connecting it all. Their DEFCON session was unfortunately unclear on the specifics of how one accomplishes this, but I nevertheless agree with many of their core principles.

This Decades Security Challege (good .pdf slides)
De-perimeterization is the way to go for network security
De-perimeterization: Jericho Forum misses the mark

Each time I go to DEFCON, sniff a network or see an ad for an infosec product, I’m harshly reawakened to the general publics detachment for security concerns. When using a virus scanner, firewall and pop-up blocker, most users seem comforted enough to go about daily business with a satisfactory feeling of a “secure” experience.

A large gap with this frame of thought is of what we’re trying to secure. The most valuable thing on your computer—the stuff you want to secure if nothing else–is your personal data/information, NOT the machine itself. Most white-collar folk, in a worst-case scenario, could cough up the bones to cope with a stolen or broken machine, or re-install the OS after a bad virus attack. The data on that machine, however, may be priceless memories, confidential trade-secrets, or other information which you’d highly prefer to remain private and well backed up. As a resident of Arizona–the new U.S. capital for identity theft (per-capita)–we must recognize that the Bad Guys on the tubes do not have the primary intent to annoy us. They’re trying to make money. Compromising your system is merely a means for collecting sellable usage habits, relaying \/i@gr@ ads, stealing/selling your identity etc. We simply need to recognize that we protect system assets largely to protect our information.

In that vein, one of the largest commonplace no-nos is sending sensitive information over ordinary email. We’ve all done it, and most will continue. Emails can pass through systems that are maintained by people you don’t know and most certainly don’t trust, so don’t be a bonehead: encrypt your email, especially if it’s sensitive material. (If your email client is a horrible bitch-goddess that makes encryption a pain to deal with, please poke the vendor with a sharp stick until they make it trivial.) Mail.app and Keychain Access.app (OS X) make it ridiculously simply to manage and use X.509 public/private keys, which you can obtain for free from Thawte. If you use Mail.app, you’re out of excuses.

Should your machine be stolen, sold, repaired, or otherwise leave your possession, how do you know your not handing over the keys to the kingdom to a complete stranger? You can wipe the drive, but that isn’t convenient if the machine will be returned to you. A simply way is to use TrueCrypt for Windows, encrypted .dmg files for OS X, or encrypt your entire freaking home directory with FileVault. (OS X).

OS X users have no excuse but to encrypt everything. Linux and Windows users may have difficulties, but easy wins are still possible. Encrypt your email. Encrypt your backups. Encrypt your calendar. Encrypt your address book. Encrypt your financials. Encrypt your music. Encrypt your photos. Encrypt your life.

Encrypt everything.

I’ve written this same basic argument for small teams three or four times now, so to comply with the Don’t Repeat Yourself (DRY) principle I though I’d post it. In short, this argument repeats Brooks’ Mythical Man-Month concept 🙂 , and asserts that you must restructure the communications dynamics of a team when it changes in size, regardless of whether or not your project is late.

To paraphrase one of the points made in Frederick Brooks’ The Mythical Man Month, complexity in a system scales with the number of interfaces. Applied to a team communications system of N people, the worst-case number of total communications channels is when everybody talks to everybody else. This can be expressed by N(N-1)/2. In other words, a given person in the team (the Nth person) is communicating with everyone else (N-1 people).

A problem with large horizontal teams is that as N increases, the communications overhead of being able to operate potentially increases exponentially. As a member of a 5 person team, for example, communicating with 4 others is not a big deal. You are able to mentally understand what other people are doing and how others communicate with each other (in all 10 different relationships). If this team grows to 15 people, however, communicating is not as simple. In the worst case, not only do you have to communicate with 14 other peers, there are now 105 relationships between people you may have to be aware of to stay “in the loop”. The worst part may be that the majority of the information going across those channels may be directly irrelevant to you job, but since it’s relevant to the team as a whole, you spend the time and mental cycles to process it.

Now, this is all worst-case abstract theory, but it does highlight the scaling problems of communication in teams of changing size. As your team changes, you need to reevaluate the way it works to keep operating overhead due to excess or insufficient communication down to a minimum.

Consider the following Java code..

public class Counter {

	private final static boolean DEBUG_ON = false;

	protected int mCount = 0;

	public int getCount() {
		return mCount;
	}

	public void increment() {
		if(DEBUG_ON) {
			System.out.println(“about to increment! count=” + getCount());
		}
		mCount++;
	}
}

}

Some people use “debug” or “test” flags because they can provide a fast way of troubleshooting situations that would otherwise be inconvenient to debug. If increment() was recursive, for example, it may be convenient to simply keep an eye on stdout rather than set breakpoints and have to step through it. (Note: see an earlier post on conditional breakpoints to avoid this entirely.)

While the extra DEBUG_ON code is fairly harmless and benign, it’s nevertheless unnecessary code that could potentially break a production system, and even when/if you do remember to comment it out, it distracts the reader from the meaningful, real code you’re trying to express.

An alternative solution? Simple. Subclass it. Try this instead..

public class Counter {

	protected int mCount = 0;

	public int getCount() {
		return mCount;
	}

	public void increment() {
		System.out.println(“about to increment! count=” + getCount());
		mCount++;
	}

}

public class TestCounter extends Counter{

	public void increment() {
		System.out.println(“about to increment! count=” + getCount());
		super.increment();
	}
}

Now you can leave your print statements intact, and just use TestCounter as a drop-in replacement for Counter in your unit tests. Alternatively, you could use one of many design patterns to aggregate or compose the Counter rather than extend it, or use dynamic proxies or aspects if you’re looking to intercept calls that exist in a horizontal manner.

I recently restarted reading Quantum Psychology by Robert Anton Wilson. (Not the easiest read. If you put it down for to long you may have to start over.) The most practical thing I’ve gotten from it thus far is the usefulness of E-Prime. You may already use it and not realize it.

To attempt to summarize E-Prime with a single example, consider the following two statements..

1. Alice’s code is broken.
2. When I ran the unit tests this morning, all the code last checked in by Alice (according to the logs) failed to pass. Thus, I think her code is broken.

While the first statement is concise, I’d much rather prefer the second because it conveys information about the observer in addition to the observation.

• The means of measuring brokenness are specified (“the unit tests”). The reader otherwise does not know how the conclusion of brokenness is being determined. Without this information, how is Alice supposed to go about reproducing the issue?
• A timeframe of failure is specified (“this morning”). Alice may have made the same observation and made fixes shortly after the unit tests were run. The code may have indeed been broken, but only appeared so at the time it was measured.
• The observations is attributed to the observer (“[w]hen I ran”, “I think”), rather than claiming the an intrinsic state of brokenness about the code.
• The scope of the brokenness is described (“all the code last checked in by Alice”). All of Alice’s code probably isn’t broken.
• It is acknoledges that the observation is limited by the means of measurement (“Thus, I think..”). When judged by another means, the code may appear fine.

In short, E-Prime acknoledges that our capabilities or understanding seem to be limited by our instruments of perception (be them eyes, ears, unit tests or ampmeters). Take a looksy at some other examples.

Conditional Breakpoints

Have you ever wanted to suspend execution only under a certain circumstance while debugging, such as every hundredth loop iteration? You can. Set your breakpoint, right-click it, select “Properties”, check “Enable Condition” and enter a condition in normal Java code that will be evaluated every time the breakpoint is hit to determine whether or not to suspend the JVM.

Remote Debugging

Sometimes things work on everybody’s box.. except Bob’s. You’ve watched him produce the issue and have tried to reproduce it on your development machine, but it just ain’t happenin’ for anybody but him. It’s time for a remote debugging session. Start up the JVM on Bob’s box like so..

java -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,suspend=n,server=y
-jar YourApplication.jar

Within Eclipse IDE on your development machine, select Run -> Debug… and create a new “Remote Java Application” configuration. Select the project that contains the source code, enter Bob’s boxes hostname (or IP address) and the port his JVM is listening on (8000 in this case). Click the “Debug” button to close the dialog and your “Debug” view should now show a new session, connected to Bob’s JVM, and the threads of your application just as if you were debugging it locally. You can set breakpoints and use all the other features described in this article, or impress your mom by starting another instance of your application locally and step through both Bob’s and your own JVM instance simultaneously, side-by-side!

Dynamic Variable & Code Replacement

If you’re debugging a tricky piece of SQL in a servlet that isn’t working right, it’s tempting to abide by the typical write, compile, deploy, run, debug, repeat cycle every time you need to tweak the String. This is tedious and time consuming. Instead, set a breakpoint someplace after the String is defined but before it is used. When you hit it, right-click the variable in the “Variables” view and select “Change Value…”. You can figure it out from there. (Note: This doesn’t seem to work for “final” variables, and so-so with statically declared things.)

If you modify and save a class while you have a debugging connection established, Eclipse will try its best to update the code on the remote JVM without having to restart it. This doesn’t always work (especially if there are stack frames using the changed code), but you’ll be notified if the remote JVM could not be updated. This is especially useful when testing a complex algorithm in a situation that is a pain in the arse to set up.

Custom Code Templates

Typing “fore[autocomplete]” in a block in Java code will add a “foreach” code template that you can fill in using the TAB key. These are customizable, and you can even add your own. For example, I prefix all generated local variable and Iterator declarations with the “final” keyword, and have added my own custom templates for inserting my most frequently used Java 5 annotations. Go to Window -> Preferences… -> Java -> Editor -> Template and have some fun.

Refactoring Actions

All of the refactoring features of Ecilpse IDE are worth learning. I can’t think of one that isn’t. Once you have a method defined and used, there isn’t much reason to manually modify the declaration. “Move”, “Change Method Signature…”, “Pull Up…”, “Push Down…” etc. give you basic, commonly used tools, and actions such as “Extract Interface…”, “User Supertype Where Possible…” etc. provide support for larger jobs. Understanding what all these do helps relieve some of the pain felt when refactoring heavily used, public APIs, and helps keep you focused on the bigger picture by taking care of the details.

I’ve come to loath ant.

XML is great for a lot of things, but is simply painful for expressing control flow. Now don’t get me wrong, it’s still easier to work with than make; you can use any XML editor or a web-browser to validate the well-formedness of an ant build file. It’s just that programmatic thought isn’t elegantly represented by a tree structure full of angle brackets. Trees are simplifications computer scientists use to fit information into limited structures that can be easily parsed and manipulated, however, as a user of the system I don’t give a flying flock that it uses a standard SAX parser. I do care about defining basic control-flow operations in a natural way, and not having to create artificial work-arounds to cater to the structure of the tree. Elegance, however, is the least of ants problems. It lacks a fundamental development capability that is missing from other build systems such as make and jam, and even long-established shells such as bash: debuggability.

Here’s the deal, plain and simple: if you’re writing a development tool, you must provide some mechanism for easy debugging. “Hello, world!” does not require troubleshooting. Every other real-world “script” does. If you’re automating a build process for a large application, it will have bugs, and when you do get them squashed the system will soon be inadequate and require modification. Now, when I say “debuggability”, I’m not talking about scattered echo/print elements throughout the code or color-coded syntax. I’m talking about stepping through the script line by line and examining the inputs and outputs of every step in the process, just like you would with any C++ or Java program,

The last item in today’s rant is support for basic data structures. Variable passing is pukingly awkard in ant, and calling other targets sometimes requires firing up another ant process. Umm.. riiiiight. “If today is Saturday turn debugging support on, run all known unit tests and send a status report to all team members” is not an unrealistic use of these systems. Debugging this should not be such a chore.