OK, I checked in the original article. Yeah, I can believe 16 minutes at a time for the wireless network. On the wired network, I'm sure it's much longer.
1) security of the end users machine. Most of us would shudder at the though of connecting a desktop windows box directly to the internet. Since the average student is only online for 16 minutes at a time, there's enough of a moving target to make this easily as secure as 85% of dialup usage.
WTF? I don't know where that 16 minutes at a time comes from, but it certainly doesn't apply to Dartmouth. The average student at Dartmouth is online all the time that they're in front of there computer, and if they have a desktop computer, all the time that they're not, too. Think hours at a time. But this isn't really an issue that Dartmouth needs to deal with. All of the computers they sell to students have antivirus software, and I would presume are set up to be secure (since I don't use a Dartmouth supplied computer, I can't say for sure). But really, it's not their problem if a student's computer is cracked, and there's no difference between the wireless network and the wired in this example.
2) privacy of the data. There is none. Neither is there once your packets leave your wired ISP. Deal with it, or use GPG.
This is very true. Dartmouth is working to fix this with a new PKI infrastructure they're developing.
3) abuse of the network. Drive-by spammers, kiddie-porn downloaders, and so on. MAC addresses can be snooped and reused. Possibly the triangulation tools they were talking about can help you prove that it wasn't you downloading live goat porn in the lecture hall in the middle of Prof. X's lecture, even if it was going to your MAC address
This is a problem, but it's not that serious, and was present even with the wired network.
What security issues exactly are you referring to? The one main one I can think of is people stealing our bandwidth. Well, guess what: the whole town of Hanover is Dartmouth and people that provide services for Dartmouth professors, students, and administration. Oh, and a couple of companies founded by former Dartmouth students. There's really no other industry in Hanover to employ people, so there's not enough people out there to steal a significant amount of bandwidth. In a large city, the story would be different.
All other issues of security on the network existed before we moved to wireless. You could walk up to any frat, dorm, or other building, find a free ethernet jack, and plug in, and no one would be the wiser. Because of this, systems have never relied on security based on whether or not you're on the network. To do anything serious you'd have to crack the Kerberos authentication that most things are secured with.
Of course, we still currently have all email in plaintext, and the encryption built into the 802.11 protocol is laughable. But this is an issue that existed with the ethernet network, which had no encryption at all. There are several research projects in the CS department, at Kiewitt (Dartmouth's IT department), and in other places at Dartmouth to improve this situation, through a strong public key infrastructure, among other things.
So yes, security is definitely being considered. Right now, it's no worse than it was beforehand, and a hell of a lot more convenient for everyone involved.
Actually, there are a decent number of dylan programmers; as many as any relatively obscure language. Look at Gwydian Dylan for an open source implementation or Functional Objects for two implementations. The key here was that they got third parties to jointly develop implementations. Although theirs was killed, Dylan lived on. Just goes to show the value of standardization.
BTW, I'm a Dylan programmer, and I know several others. In fact, until recently, my college (Dartmouth) used Dylan for it's second CS class. The reason that they stopped was that they were using the older, prefix syntax, which was only supported by one aging implementation that really needed to be killed. They decided it would be easier to switch to scheme with TinyCLOS than infix Dylan.
The OpenCores project could be useful for this. It doesn't have much PC compatible hardware, but lots of embedded stuff. It's not currently at a state where it would be a viable replacement for proprietary hardware, but if you want a place to focus your effort, I'd suggest you check it out.
Slashdot Mirror
OK, I checked in the original article. Yeah, I can believe 16 minutes at a time for the wireless network. On the wired network, I'm sure it's much longer.
All other issues of security on the network existed before we moved to wireless. You could walk up to any frat, dorm, or other building, find a free ethernet jack, and plug in, and no one would be the wiser. Because of this, systems have never relied on security based on whether or not you're on the network. To do anything serious you'd have to crack the Kerberos authentication that most things are secured with.
Of course, we still currently have all email in plaintext, and the encryption built into the 802.11 protocol is laughable. But this is an issue that existed with the ethernet network, which had no encryption at all. There are several research projects in the CS department, at Kiewitt (Dartmouth's IT department), and in other places at Dartmouth to improve this situation, through a strong public key infrastructure, among other things.
So yes, security is definitely being considered. Right now, it's no worse than it was beforehand, and a hell of a lot more convenient for everyone involved.
Actually, there are a decent number of dylan programmers; as many as any relatively obscure language. Look at Gwydian Dylan for an open source implementation or Functional Objects for two implementations. The key here was that they got third parties to jointly develop implementations. Although theirs was killed, Dylan lived on. Just goes to show the value of standardization. BTW, I'm a Dylan programmer, and I know several others. In fact, until recently, my college (Dartmouth) used Dylan for it's second CS class. The reason that they stopped was that they were using the older, prefix syntax, which was only supported by one aging implementation that really needed to be killed. They decided it would be easier to switch to scheme with TinyCLOS than infix Dylan.
The OpenCores project could be useful for this. It doesn't have much PC compatible hardware, but lots of embedded stuff. It's not currently at a state where it would be a viable replacement for proprietary hardware, but if you want a place to focus your effort, I'd suggest you check it out.