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.
