Zoia Horn’s Library: protecting your users’ privacy with Tinfoil

In February I presented a paper at the VALA 2016 conference. The basic argument of my paper was that the choice between patron privacy (by deleting loan history) and useful data insights (by keeping full loans history) is a false one. We neither need to choose one above the other, nor come to some false ‘compromise’. Rather, we can have both. The answer to the conundrum is to understand that current library software was built on a paradigm that no longer holds true, using technology that is no longer relevant.

Library Management Systems¹ aren’t built for library users² - they’re built for library staff. This is the fundamental problem with the systems we use when it comes to user privacy. We’ve come up with all sorts of post-hoc justifications for why we need to know what people are reading and have read, but ultimately the reason is that librarians have tended to prioritise functions that make our lives easier rather than those that make library users’ lives easier. This was the general theme of Tony Zanders’ slightly controversial paper at the same conference. Whilst Zanders was talking about ‘discovery’, the same explanation applies to why librarians talk good talk about user privacy but continue to use (and build) software that provides no protection from snooping librarians, contractors or Police.

Rather than just whinge about it, I thought it might be useful to imagine what a ‘privacy first’ library circulation system might look like. I concluded that the key is to think not about what needs to be known, but rather who needs to know - and when. So for example, librarians often (rightly) say that library users often want to know whether they have borrowed an item previously, or the title of that great book they returned last week. Turns out humans have bad memories. But in this case there is no need for the librarian to know the title. It’s the library user who has the need to know. They’re asking the librarian because they haven’t been given a simple way to access this information on their own.

The paper I presented at VALA is a theoretical framework laying out some principles for how one might go about building a system that puts privacy first. As I poked around trying to understand what the technical possibilities were, I discovered Mylar - a client-side encryption system that enables free text searching over encrypted data. It’s built on the JavaScript framework Meteor, which I’ve mentioned previously. This discovery was actually what pushed me towards learning JavaScript and Meteor, but it turns out that the documentation on using Mylar is ...sparse. Certainly, for a JavaScript beginner it was difficult to understand how to make it work.

So, in February I merely had a framework. Five months later I finally have a live demo system and some demo code on GitHub. The demo isn’t the flashiest of sites, but I’m a librarian, not a professional web developer. It’s also not an attempt to build a new LMS/ILS. There are plenty of developers building fully featured and complex library circulation systems for a living. What I’ve built is a simple system that demonstrates some possible functionality and architecture that I’d love to see incorporated into library software systems.

You can read more about the theory in the VALA paper. I’ve also written an overview of what you’re actually looking at on the demo site.

This project has been really interesting, and led me to think more about all the assumptions built in to library circulation software. The part I struggled with the most was working out how patron notifications would work when item information is encrypted in the client. The ‘solution’ I came up with isn’t very elegant - which is partially because of my limited programming skills, partially because it’s a web-based demo and not a whole system, and partially because I wanted to demo something without destroying everything about how library circulation software is currently designed. Ultimately, the best real-world solution is obvious - notify patrons via a mobile app using push notifications. That would work well because the app can decrypt the item information when the server pushes and alert based on the due date. Yet mobile apps for library circulation systems, where they exist at all, still tend to resemble a sort of locally-installed OPAC terminal rather than being used to reimagine how libraries are run, and to empower library users.

I’m hoping Tinfoil will influence how librarians think about, and assess, library software, how software developers build library software, and ultimately how libraries - particularly public libraries - are run.