February 17, 2005
Members present: Tracy Futhey, John Board, Ken Hirsch, Robert Wolpert, Melissa Mills, Chris Cramer, Kyle Johnson, Christopher Gelpi, George Oberlander, Daron Gunn, Michael Gettes, David Jamieson-Drake, Lynne O'Brien, Shailesh Chandrasekharan, Owen Astrachan
Guests present: Cheryl Crupi, OIT; Sarah Roberts, OIT; Bob Currier, OIT
Start Time: 4:00 p.m.
I. Review of minutes and announcements
Mellisa says she has a new position.
Tracy adds that there are two points of clarification: Mike's role is strictly an interim position. You've heard us talk before in ITAC about collaboration: that effort will continue.
John Board clarifies, people shouldn't interpret this as an indication that Arts & Sciences is not out of the business of computing at this time.
II. Content Management System update - Cheryl Crupi, Billy Herndon, Michael Gettes
Cheryl Crupi says in December Duke purchased the license to an enterprise tool, ContentXML, to provide a content management system for Web sites throughout Duke.
John Board says this is a change, because we were leaning towards another product.
Cheryl says they were working with another vendor, but this fall it became clear that it wasn't going to be ready in time, so we realized it was time to look at other alternatives. We looked for an interim system, but there really aren't any products out there that do this now. One key technical criterion we were looking for in a content management system is how easy it is to get stuff out, and in ContentXML it is very easy. In the meantime, the functionality is very powerful and we think it will be an excellent investment for Duke.
The team working on this knows the tech solution is only part of success; bringing community engagement is also very important. Some of our plans involve community engagement and convening a series of Duke-wide teams to focus on the tech solutions, feedback, making sure the rollout is smooth, etc. In terms of services and resources, my team has been talking to people to determine what they think they are going to need once the project is done. We know there are folks that don't have dedicated Web shops to do their website, and others with Web shops whose staff will need to be trained. We're going to build generic templates that people can use and are putting together an image base. We're looking at Web-stats and hosting as well. In terms of Web services, we can give people OWS or vendor referrals. Our goal is to try and make this tool as valuable to as many people as possible.
In terms of a timeline, the production environment is up and we're working on our first project, the Duke News & Communications site, which should be up in April. The next project will be Student Affairs, which should go up this summer. In addition, we're working on creating templates.
George Oberlander asks do you have any schedules of costs?
Cheryl says they are working on that now. They're working with key vendors, and the school has some leverage to get favorable terms.
Robert Wolpert asks can smaller outfits stick their toes in? Does it make sense for a page or parts of pages to go through the CMS, or do you have to redo the entire site?
Cheryl says you don't have to update your entire site; many people I've talked to are looking for small projects to use it with rather than biting off something really big.
Shailesh Chandrasekharan asks what is the currently policy for controlling content for department Web pages and the Duke Web pages?
Tracy says there isn't one single site or location that controls the content; we did have a group led by Ken Hirsch last year working on Web policies; the policies they have come up with are now a formal policy and are in the process of being made public.
Shailesh says we have a department Webmaster, and this person should be informed of your new tools.
Cheryl says yes, and the Web policies can be found on the OWS website at http://www.oit.duke.edu/ows/duke_web_services.html
David Jamieson-Drake says Deen Freelon, for example, teaches web classes, would be a good resource to instruct people how to use the CMS.
III. Results from Freshman Survey - David Jamieson-Drake
Chris Cramer says this is the third semester we’ve done bandwidth ticketing, and I think it’s been fairly successful. Two years ago we had problem in ResNet. There was a lot more demand on ResNet than it provided capability for, so performance in general was terrible. Rather than limiting students up front, we said, lets take this as a chance to educate. Students are given a fairly large cap: if any student uses 5 Gbs of bandwidth in a given day, they’d receive a traffic ticket. If a student receives 5 tickets in a given semester, their uploading bandwidth would be limit rated to 64 Kb. Inbound is not restricted at all.
One of the decisions was that if a student came back and says they had an educational reason for serving up all this data, we would allow this. Two students initially claimed this, but it turned out they just misunderstood the different between upload and download.
Bob Currier says last semester had 88 ticket days (the number of days we actually issue tickets). There was a total of 790 tickets, fairly evenly divided between campuses, resulting in an average of 8.9 tickets issued per day. We’ve had 18 ticket days in the current semester and total of 187 tickets, with an average of 10.4 tickets per day. This is consistent with previous semesters, as tickets/day tend to be higher earlier in the term.
John asks if we have data on recidivism.
Chris Cramer says we maintain relatively little historical information.
Bob says as an unofficial, he believes several students have gotten 5 tickets in the past semester.
Daron asks if these are students who are knowingly transferring large amounts of data, or have their computers been hacked?
Chris says they do get some responses from students saying they don’t know how it happened, and we point them toward the Help Desk.
John Board says he takes those numbers as alarming, that we have that many students already this semester that were throttled, and are therefore ignoring our policy, so we are going to have to revisit this.
Tracy Futhey says the important thing will be to revisit this with the student body leadership, because they called for this, partly as an issue of equity of shared resources, and partly as an education campaign.
Robert Wolpert says we set the 5-ticket limit on an ad hoc basis. Would it be different if we set the ticket limit differently?
Chris Cramer says Bob, Dan, and I talked about this earlier, and the way we’re storing data we don’t know right now. We could as a project start keeping that information. There is an interesting question as to if one student or multiple students are repeat offenders.
Shailesh Chandrasekharan says from what I understand this is only for the students?
John Board says yes.
Chris Gelpi says, if we can limit their bandwidth, does it really matter that much?
Tracy Futhey says it has resolved the performance issue, but there is still the educational issue about appropriate use.
John Board says when this first came out one student tried to be clever and circumvent the process by setting up multiple ports. Do we still have problems with students trying to get around this?
Dan says there was one instance when a student tried to change their Mac address, but that was about it.
Michael Gettes asks if there is a cost to what we’re doing now that we should pay attention to?
Chris Cramer says there are some Help Desk costs in disabling peer-to-peer and dealing with hacked machines, which we’d have to deal with anyway.
IV. Why is authentication so hard? - Michael Gettes
Michael Gettes says looking at the current authentication landscape at Duke, security is hard, good security is harder, and most applications shouldn't handle authentication. There is a lot of range of motion at Duke with respect to authentication: LDAP, Novell, Window/Kerberos, Challenge Response, PKI/X.509, WebAuth (Duke specific), Shibboleeth, Passwords, Biometrics and Cards (DukeCard).
There are a range of problems with authentication: sniffing, post-authentication hijacking, online password guessing, offline dictionary attacks, man in the middle attacks, replay, downgraded mechanisms, crypto attacks (brute force, known plain text, etc.), and biometrics (once these have been compromised, you're done!).
Unfortunately there are a lot of systems out there that store information centrally.
Single sign-on: everybody wants it, it's the right thing to do, but does one single sign on meet the policy requirement of all applications? If authentication becomes too easy, will people respect it? I belief in multiple sign-ons, but judiciously, so when do you need it?
At Duke, the IT security officer is our friend. When evaluating what is the right tool for the job, each application needs consideration. Getting authentication right is important, because one application that does it wrong could impact all the other applications. Vendors tend not to understand these issues: they tend to implement things badly. Lastly, the IT security officer should be involved to help discern the risk of each application and match the risk to data integrity, application exposure, population, etc.
There are other factors, a lot going on between higher education and the U.S. government, the notion of levels of assurance (a way of classifying the confidence of the ID proofing), policy interoperability, and identity management.
Robert Wolpert asks if one of us is trying to get authentication for our own departments, do we try to use Web Auth?
Michael says that is a question of where we draw the line, when does Chris Cramer get involved.
V.Winning Movies from the 2005 Froshlife Competition - Sarah Roberts
Sarah says this year we've just finished our 3 rd iteration of the Froshlife iMovie Project. It's been a collaboration on the programmatic side between OIT and Student Affairs with technical equipment assistance from Apple and the Duke Computer Store. It targets first-year students on East Campus to get their hands on technology they may not have otherwise, namely digital video to make short movies.
We just had the production period, two weeks in which the students work on making their movies. We get into the hundreds in terms of participation. We give the students loaner equipment, so we provide them with everything they'll need to have a successful project, we give them documentation on how to use the equipment and form a compelling film. It's a hands-off approach, but that seems to lead to the most creativity.
Robert Wolpert asks how many cameras do you contribute?
Sarah says we get enough equipment so to provision each residence hall; there are thirteen. This year we had nine entries, down last year from eleven, but we see an increase in the technical skill and the time and amount of thinking they've been putting into it.
(Sarah shows the winning movie, from Jarvis)
All of the movies from this year's project can be viewed at http://www.duke.edu/froshlife/
Tracy adds that the GA movie is going to be featured on the Admissions website.
VI. Other Business
None.
End Time: 5:30 p.m.