Oren’s Weblog

Apparently Nicholas Carr has now made a book out of his HBR article “IT Doesn’t Matter” that caused such a fuss last year.

InfoWorld’s Chad Dickerson has a nice take on it here.

Beneath all the “IT doesn’t matter” hype, there’s the notion that IT is already a utility and you just plug things in and they work — not true. In my mind, the ubiquity of IT shouldn’t be confused with overall IT stability any more than the ubiquity of banking systems should be confused with making money. In both cases, good management matters more than anything.

Jack McCredie from UC Berkeley wrote a good response to the original article on why IT certainly does matter in higher education.

I argue that academic institutions that are smart and nimble enough to take advantage of advances in information technology will be better able than their peers to compete for great students, faculty, and staff. Successfully incorporating IT into their operational and educational fabric will probably not enable any institution to corner the market on National Merit Scholarship winners or National Science Foundation grants; however, the advantages will be real, and they will matter in the day-to day culture that sets one institution apart from another.

The usually well-spoken Cory Doctorow has posted an entry in Boing Boing relaying a report from Jason Schulz decrying Penn State’s policy of not allowing students to run servers on the University network.

While it’s very easy to cry foul on the big, bad, University for limiting student freedom, reality is, as usual, far more complex and nuanced.

I can’t speak for Penn State, but I do know about the deliberations we’ve had over the years on the same topics here at the University of Washington.

Running a network at a large research institution is not an activity for the faint of heart – the demands are huge and growing exponentially, the policies governing the network are never clear, and the budget is always too small.

While we like to think of students using computing and networking at universities in terms of absolutes like academic freedom, freedom of speech, and free inquiry and learning, in reality providing network services for students comes down to a series of cost/benefit/risk tradeoffs.

The cost of providing high speed network services to a modern research university is not inconsiderable. For instance, Indiana University shows its total networking costs for the 2002-2003 year at the Bloomington campus to be right around $7.5 million (reports available here). So let’s not labor under the illusion that providing bandwidth to students is free (or even cheap). In addition to the costs of providing network services, there is also the cost of providing support for those services – analyzing problems with networks is complex and getting more so in the age of firewalls, NAT, and other security-related appliances that interfere with the end-to-end nature of the network.

The set of risks to an institution posed by abuse and misuse of the network should not be underestimated. There are security risks to the institution brought about by poorly administered machines on the network (as I write this we are in the process of shutting off a couple thousand campus IDs that may have had passwords sniffed as a result of several compromised *nix boxes having trojan ssh servers installed), legal risks posed by people sharing data that they don’t have rights to (not just music and movies, but photos, licensed research materials, and the like), and the risks to the institution’s reputation with its funders, alumni, and state, federal, and private agencies, if the university is perceived as doing a poor job of running its network services. In another context my colleague Terry Gray has pointed out that we are rapidly evolving to a legal environment, in the age of regulations like HIPPA, FERPA, and the like, where much of our technology will end up being determined by managing the risk to the institution – sigh.

I certainly agree with Cory and Jason that the benefits from students having widespread access to high speed networking are huge – students can try things out, learn how to interact with networks that they will only be able to dream about in most workplace settings, and dream up new and innovative things that us workaday folks would never have the time nor imagination to come up with.

So from the point of view of those of us who provide networking and computing services to universities, the questions are always how to provide for the most benefit while minimizing the risk and doing it all at a reasonable cost.

Here at the UW we faced these issues in the student realm about five or six years back when the majority of our dorms got wired with ethernet. We spent a few quarters dealing with the increased issues of student-run ftp servers offering up all sorts of things all over the web (this was before the major advent of p2p file sharing), and we were trying to devise policies that minimized the risk to the institution and the cost of support, but did not involve us computing types in actually having to look at and make judgements about the validity of specific content.

We came up with a policy that allows students to have servers in the residence halls that are visible on the campus network, but not to have servers that are visible to the global Internet. That policy allows students to do plenty of learning and experimenting with new technologies, but limits the exposure and amount of support we have to give to the relatively small number of students that live on campus here (we have about 4,000 students living on campus, out of a total student body of around 39,000).

Students who are doing research projects in departments (like the Google and Yahoo examples quoted in Cory’s post) typically have machines hosted in the departments and have free access to the whole variety of high-speed networks provided to the University – see http://www.cs.washington.edu/research/systems.intro.html for some examples.

Then a couple of years ago we had to contend with the rise of p2p file trading – at that point we realized that something aroud 40% of the total off-campus bandwidth available to the University was being eaten up by the dorms, and that percentage was growing precipitously. Obviously we couldn’t let it get to a point where university researchers, faculty members, and clinicians in our medical centers couldn’t get the bandwidth they need for their work because students were using Kazaa (not to mention students doing legitimate research and academic work).

So we sat down in discussions with the Housing administrators and asked them if they were interested in paying to increase the amount of overall bandwidth for the University to accomodate this traffic. Logically enough, they told us that their goals are to keep the overall price of University housing as low as possible and they didn’t want to have to increase prices to pay for students to share music and movies.

At that point we brought in technology to limit the amount of bandwidth available overall to the dorms and to further limit the amount of bandwidth within that total cap that is available to the most popular p2p applications.

While those limits were not initially popular with students, I believe that most of them have resolved their issues with the caps – either by living within the caps or by finding workaround – at least the volume and frequency of complaints has certainly diminished.

So we continue to try to provide our students with the best networking we can, while living within the real-world constraints we all have to put up with. Make sense?

This posting of Cory’s has been picked up widely, and I for one think it does a terrible disservice to all of us in the higher ed IT support community.

By now lots of people have written about the OS X Help Viewer vulnerability, which allows remote arbitrary code execution from visiting a bad link in a browser.

My colleague Josh Larios writes the following on how to protect yourself:

This one is serious. Arbitrary code execution with nothing required of the user but that they visit a malicious web page. It affects all browsers, not just Safari. It seems to only affect OS X 10.3. There’s a fairly scary proof of concept floating around which opens a terminal window and executes a command. It should be obvious that that’s a Bad Thing.

Dave Clark is one of the grand old men of the Internet – he was the first chair of the Internet Activities Board (Vint Cerf was the second), he was the Chief Protocol Architect from ’81-’89, and his accomplishments are wide ranging.

Terry Gray turned me on to this video of a terrific talk Dave gave at a recent Internet2 meeting (warning – it’s a 488 MB QuickTime file) about the future of the Internet.

Dave’s thesis is that the future of the Internet will be defined more by legal and social needs than by technical design, as inelegant as technologists and engineers may find that. He characterizes the discussions around social and legal drivers by the “tussle” that occurs between various points of view on any issue.

He’s got a 2002 paper on the topic which, while nowhere near as entertaining or broad in scope as the talk, is a lot easier to download:

Engineers attempt to solve problems by designing mechanisms with predictable consequences. Successful engineering yields bridges that predictably don’t fall down, planes that predictably don’t fall out of the sky, and calculators that give the “right” answer. The essence of engineering is the development and codification of models, techniques and tools that deliver predictable, desirable behavior. The technical development of the Internet has followed this path.

The challenge facing Internet research and engineering is
to recognize and leverage this reality – at minimum to ac-
commodate it; if possible, to use it to strengthen the techni-
cal architecture. In other words, the technical architecture
must accommodate the tussles of society, while continuing
to achieve its traditional goals of scalability, reliability, and
evolvability. This expansion of the Internet’s architectural
goals is a difficult, but central technical problem.

My colleague James Morris points out an article in Microsoft’s Technet site by Jesper M. Johansson, Security Program Manager at Microsoft, entitled Help: I Got Hacked. Now What Do I Do?.

• You can’t clean a compromised system by patching it. Patching only removes the vulnerability. Upon getting into your system, the attacker probably ensured that there were several other ways to get back in.
• You can’t clean a compromised system by removing the back doors. You can never guarantee that you found all the back doors the attacker put in. The fact that you can’t find any more may only mean you don’t know where to look, or that the system is so compromised that what you are seeing is not actually what is there.

it concludes:

The only way to clean a compromised system is to flatten and rebuild. That’s right. If you have a system that has been completely compromised, the only thing you can do is to flatten the system (reformat the system disk) and rebuild it from scratch (reinstall Windows and your applications). Alternatively, you could of course work on your resume instead, but I don’t want to see you doing that.

This list makes patching look not so bad, yes? We may hate patches, but the alternative is decidedly worse.

Sobering reality.

There’s been a lot of brouhaha over the new licensing terms on Movable Type 3.0. Movable Type is great blogging software, and it’s what I use to host this blog. You can read all about the issues with the licensing at Brad Choate’s site.

Mena Trott, one of the cofounders has asked people how they’re using MT, to see whether the new licensing terms would actually cause real hardship. That’s a real gutsy thing for a software author to do, and I applaud Mena and Ben, and I fully support their quest to make a living from the software they’ve built with passion and care.

For me, one author writing one weblog on my installation of MT, the new terms make no difference.

If we were going to use it as a business tool for UW Computing & Communications, we’d have no problem paying for the software under the new license terms.

I hope Mena and Ben make a bundle and keep growing the software into a ripe old age.

Over the last week or so my six-month old 15-inch Powerbook (the 1.25 Ghz model) started acting strangely – it would sometimes go to sleep unexpectedly, and sometimes have a hard time waking from sleep, and it was also not recognizing what should have been known wireless networks.

On Saturday, right after I installed the latest SlimServer software, it went to sleep and wouldn’t wake up. I removed the battery, unplugged the machine and waited till it ceased thinking it was asleep, but it wouldn’t reboot. I tried resetting the power management unit, but no dice.

Luckily, I have Applecare on the Powerbook, so a call to Apple was in order. After telling them what I had tried so far, they decided that there was no alternative to shipping it back to Apple. So they’re sending out a box and off it will go today – they said to expect a five-day turnaround. Sigh – living without my Powerbook for a week will not be easy. Luckily, I still have my trusty Toshiba Portege 2000 to see me through my mobile needs while I wait.

There have been widespread reports of quality problems with this particular model of Powerbook – but the reports I’ve seen have been either about warped lids (which my machine also exhibits), or display problems – I haven’t seen any mention of the problem I experienced with this model.

It made me think of something Terry Gray said while we were chatting about Apple back in January – that despite Apple’s reputation for hardware design and manufacturing, in his experience their hardware hasn’t been all that robust, and what they really do best is software, and that he wished they’d license OS X for Intel commodity hardware. Now that’s an opinion that goes against the common wisdom about Apple, but I’m beginning to wonder if he doesn’t have a good point.