Tag Archives: ils

Apple, the FBI, and Libraries

I’m sure most people who might read this blog are at least familiar that there is currently a battle occurring between Apple and the FBI over access to information on a phone that had been used by the San Bernardino terrorist. The details of that case are fascinating and nuanced, and can be summarized very roughly as:

The FBI has obtained a court order that compels Apple to create a new version of iOS that is different from the existing version that lives on the phone in question in three ways: one, that the new version will bypass the time-delay between password attempts that is standard for iOS; two, that the new version will be able to enter password attempts in a programmatic fashion instead of through finger presses on the screen; and three, that the new version of iOS will disable the security setting that may be active that erases the phone unrecoverably if 10 password attempts are incorrect. The reason that the FBI needs this to access the information that is stored on the phone is that iOS uses encryption to secure the information on the phone when it is, in the parlance of computer security types, “at rest.” The FBI could make a bit-for-bit copy of the software that is on the phone, and examine it until the heat death of the universe, and not be able to decrypt the information into a readable form.

While the court order and the responses on both sides are not directly about encryption, the reason that this is a question at all is encryption…if the FBI could dump the contents and read them, there would be no need for them to access the phone at all. Indeed, the information from the phone that they do have, given to them by Apple, is from a 6-week-old iCloud backup of the device that isn’t encrypted (currently, iCloud backups are NOT encrypted, or rather, they are encrypted but with a key that Apple has).

Why is this relevant to libraries? I think it’s past time that we start paying very close attention to the details of our data in ways that we have, at best, hand-waved as a vendor responsibility in the past. There have been amazing strides lately in libraryland in regards to the security of our data connections via SSL (LetsEncrypt) as well as a resurgence in anonymization and privacy tools for our patrons (Tor and the like, thank you very much Library Freedom Project).

Data about our patrons and their interactions that isn’t encrypted at rest in either the local database or the vendor database hosted on their servers (and our electronic resource access, and our proxy logins, and, and, and…) is data that is subject to subpoena and could be accessed in ways that we would not want. It is the job of the librarian to protect the data about the information seeking process of their patrons. And while it’s been talked about before in library circles (Peter Murray’s 2011 article is a good example of past discussions) this court case brings into focus the lengths that some aspects of the law enforcement community will go to in order to have the power to collect data about individuals.

For a great article on the insanity associated with the government’s position on this, please take a moment and read James Allworth’s The US has gone F&*%ing Mad. Also take a look at the wonderful article by Barbara Fister from Inside Higher Ed, wherein she boils the case down and does some deft analysis of the situation (sidenote: I’m a massive fan of Barbara’s writing, if you do not regularly read her stuff, fix that).

It’s fairly clear, I think, that the FBI is using this case to seek to set a precedent that would allow for future access to information on iOS devices. The case was chosen specifically to have the right public relations spin for them, it’s a thing that is technically possible (unlike a request to “break the encryption” which may actually not be technically possible), and they have asked for a tool to be created that is easy generalizable to other iOS devices. I back Apple on this, and believe that strong security measures (including but not limited to strong encryption) make us safer.

And I would feel lots, lots better about the state of data in libraries if I knew we were using strong encryption that protects our data. I would love to see an architecture for a truly secure (from a data standpoint) ILS, because I’m pretty certain that none of the ones in use right now are even close. In the same way that I’m certain that Apple is working on producing a version of iOS that they cannot access at all….we need to architect and insist on the implementation of data storage that even we can’t get directly into. If patrons want us to keep their lending history (and we have some evidence that opting in to such a system is something that patrons do want), then let’s insist that our ILS treat that data like toxic waste: behind closed and locked vaults that neither we nor the vendor can access.

Plowing ahead

I can’t believe that it’s been 2 weeks since we announced that we were going to be transitioning to the OCLC Web Scale Management ILS, and that I haven’t blogged in the meantime. Although to be clear, the second is a direct result of the first.

We have been working like mad to make this admittedly insane timeline work. I’m pretty sure that my ILS Manager/Queen of All Data Andrea worked 100 hours that first week, moving data around and massaging it into what OCLC wanted from us for Web Scale. As the first live site, we volunteered to take upon ourselves a huge amount of the data manipulation, so Andrea has been moving MARC out of Virtua, into Access to manipulate, and then finally through an XSD to provide OCLC with the final mapped XML for all the fiddly-bits of data. We’re also dumping huge amounts of MARC directly, but for non-bib records (holdings, items, patrons, etc) we’re doing a ton of conversion.

This isn’t to say this is the way that everyone will do it…but with our somewhat aggressive schedule, we were determined to give them whatever made it easiest to make WMS happen.

I’d like to publicly thank everyone at MPOW who have really put themselves out on a big limb to help with this implementation. We’ve got three major working groups doing different parts of this massive job, and all of them are digging in and getting stuff done. I’m so, so proud of the team that I work with at UTC…serious, I couldn’t have hand-picked a better group of librarians. They freaking rock.

We’re still on track for an August 20th launch, and we’ll be rolling WorldCat Local to our patrons before the full go-live….so we’ve got just short of 3 weeks to finish this thing off. Between now and then we’ve got to finish the little troublesome data sets, get an updated patron file ready, start a marketing blitz on campus for our patrons, get a redesigned index page up for the website that highlights WorldCat Local, and kick the hell out of some really, really shiny new tires.

OCLC Web Scale Management

I am very pleased to finally be able to announce that the Library at the University of Tennessee at Chattanooga is scheduled to be the first live implementation of a product that has been talked about for years: a web-based, collaborative, modern library system that does away with silos of data. We are implementing the OCLC Web Scale Management library system even as I type, and will be going live with the system for circulation on August 20, 2010, and with circulation, cataloging, and acquisitions on August 30, 2010. A wiki page documenting the process, working groups, and more is available, and will continue to be updated as the process continues.

I could talk for a long time about how excited I am about the possibilities of this system…and probably will for the next few months at least. I’ve been pursuing Andrew Pace about this product for what feels like years now, and after seeing it and understanding what may come as a result of this…well, I can’t wait.

This is a major shift in the library world, and it’s one where I think the repercussions will take years to really be felt. The simple time-saving that will be immediately felt for libraries in their processes are enormous…the workflow necessary to get something from order to shelf is so straightforward and fast that I feel strongly that we’ll save several person-years of staff time in short order. In addition, there is a shared-plugin architecture for the staff-side that combines with the open API calls that give incredible access for mashups of data that directly interact with the system. One example that I’ve seen is a plugin that combines the New York Times bestseller API with the acquisitions module in Web Scale to allow for single-click ordering from a list of bestsellers that is a live call from the NYT.

Going the other direction, the architecture allows you to pull your own data out and impose it on other pages. An example of this would be a Firefox plugin that shows you realtime budget information while you shop on Amazon.com…complete with recalculation as you add things to your Cart.

This isn’t to say that there aren’t a ton of questions still. We’re the earliest of adopters on the first product of its kind…to say that I am a bit nervous would be an understatement. But the potential and promise of Web Scale is something that make it worth it.

We are literally implementing Web Scale Management in 30 days. To my knowledge, I’ve never heard of another ILS migration even approaching this level of speed…so if I’m a little out-of-touch for the next month, you won’t be terribly surprised.