Month: June 2019

Posted on

All Things Privacy – ALA Annual 2019 Edition

Welcome to this week’s Tip of the Hat! This week is the American Library Association Annual Conference in DC, and LDH is packed up and ready to talk all things privacy to thousands of library folks from across the country. The Executive Assistant will keep things in order while we exhibit, but she is not letting the other half of LDH go it alone at #alaac19. Who is this new addition to LDH? Come by our booth (#844) at Annual to find out more!

If you are one of the lucky folks who is attending #alaac19, LDH would like to help you have a great conference while keeping some of your privacy intact in the process. Here are some ways to enjoy your conference and protect your privacy at the same time:

At the airport – if you are flying to DC, your airline might be using facial recognition during the boarding process. In most cases, you can opt out. Techcrunch wrote about the process and you can learn more about the opt-out process there.

Connecting to public, hotel, and conference wifi – Use a VPN anytime you are connecting to a public wifi network or other network that is not your home or your work network. Your place of work might already have a VPN available for use for when you are working outside the office; however, keep in mind that work can also see any non-work traffic you might engage in while connected. If you don’t have work VPN or want to have a VPN separate from work, there are several options you can choose from. LDH uses Private Internet Access, which offers good VPN service at a reasonable cost, and works across multiple platforms (Windows, iOS, Android). The one thing to remember, though, is to never use a free VPN service. If the product is “free” the actual cost to use the product is your own personal data.

On the Exhibit Floor – You might notice that the QR code or barcode under your name on your badge. Exhibitors sometimes ask you if they can scan your badge, particularly if you want nice swag! What exactly is in that QR code? When I scanned my badge from Midwinter using an Android barcode scanner app, this is the output: “csi313|1237819|Becky|Yoose|”. My name is there, but also note the two strings of numbers before it. While indecipherable to attendees, those strings could eventually lead to the vendor getting your contact information. If you wouldn’t give your physical business card to a vendor, you might want to decline the offer to have your badge scanned by the same vendor. Better yet, ask the vendor what they do with the information that they get off of your scanned badge.

Outside the conference – take off your badge. This is for both security and privacy reasons. DC is full of tourists, but they do not need to know your name while you’re walking through the streets to your next meeting!

At the conference – there are several privacy-related events happening at #alaac19! The Office for Intellectual Freedom created a list of programs and meetings of all things privacy-related programming, including sessions on Privacy by Design and minors privacy rights. Between sessions, check out the Glass Room Experience in the exhibit hall at booth #3446! The booth will be featuring the community edition of the original Glass Room Experience. From the organizer of the booth – “This edition was developed as a result of high demand from visitors of larger Glass Rooms in London and New York, who also wanted to set up similar exhibitions in their cities. This smaller, portable version comes in a lightweight and adaptable format that can be set up in a variety of different spaces from libraries and schools to conferences and metro stations.”

Last but not least, stop by booth #844 and say hi to LDH! We will be sharing the booth with Equinox Open Library Initiative. If you want to learn more about how open source technology can help empower your library, the folks over at Equinox OLI would be more than happy to talk to you at the booth.

If you are heading to DC this week, safe travels and we hope to see you at booth #844!

Posted on

To Renew Or Not To Renew

Welcome to this week’s Tip of the Hat! We at LDH are furiously getting ready for ALA Annual next week, and the Executive Assistant is bummed that she was not able to register for the conference. It appears that the only cats that are allowed at Annual are Baker and Taylor. Worry not, for the Executive Assistant has lined up someone to go in her place. You will get a chance to meet this new team member if you are heading to Annual. Stay tuned…

In the meantime, it’s Monday, and Mondays are the best days to talk contract renewals, right?

(Right?)

Last week Samantha Lee wrote about the upcoming changes to Lynda.com’s authentication process for library patrons, which would require patrons to either create or link a LinkedIn account to use their library’s Lynda.com subscription. Lee details the various issues surrounding patron privacy with this upcoming change:

LyndaLibrary had access to library card numbers for verification purposes. With the proposed change to require patrons to get LinkedIn accounts to access the Lynda resources, LinkedIn Learning would have access to more personally identifiable information than they would have as LyndaLibrary. To get a LinkedIn account, patrons would need to provide an email address and their first and last names. This is more PII than other library e-content vendors would require (OverDrive requires library card numbers only, Hoopla requires a library card and email). After a user creates an account, they are prompted to then add employment history and import their email contacts – under the presumption to help users expand their professional network. So LinkedIn would not only have patron information, but also information for others who did not agree to use its platform. [emphasis added]

In the post, Lee pointed out that several libraries have already decided not to renew their Lynda subscriptions. In the comments section, two commenters related their less-than-positive experiences in asking their vendor representative about the proposed changes, as well one commenter a vendor representative, explaining why the changes were being made.

This recent change highlights the long-standing tension between libraries and vendors regarding patron data. As Lee mentioned, other vendors do use some patron data to verify that the patron is with that particular library and can use the service. This tension is complicated by a number of factors, from the administrative (what data is being collected and why) to the technical (what data is needed for the service to function). Cloud-based applications add another layer of complicating factors, particularly if third-party contractors (sub-contractors) are involved in providing the infrastructure or other services for the application, which then increases the number of potential people that have access to patron data.

Some libraries use the contract negotiations and/or renewal phases to include contract clauses holding vendors to privacy and confidentiality policies set by the library, along with other privacy and security requirements surrounding patron data. Other times vendors work with libraries to create privacy-driven development and practices, closely aligning their applications to the standards of privacy laid out by libraries. And then there are times when vendors are proactive in creating a service or application with patron privacy in mind!

The Lynda.com change seems to be following the usual conflict pattern if you read through the comments – libraries pushing vendors for changes, vendors pushing libraries about why the changes are necessary. Sometimes, though, one party leaves the negotiations in hopes to gain an advantage over the other party. This is not without risk. Considering that many library patrons use Lynda.com for professional development and learn much-valued technical skills, some libraries might hesitate leaving the Lynda.com contract on the table. Nonetheless, some libraries are taking that risk in hopes that if there is a critical mass of unsigned contract renewals, then the vendor would have to respond to their requests. As Lee states, “If LinkedIn Learning cannot take our profession’s concerns seriously… then we can and will take our business elsewhere. Maybe then they will be willing to adopt the changes we require to protect patron privacy.” There is already some momentum for this strategy as mentioned by Lee and the commenters, and perhaps we might observe a critical mass sooner than later.

Posted on

You Say Security, I Say Privacy…

Welcome to this week’s Tip of the Hat!

You might have seen the words “security” and “privacy” used interchangeably in articles, blog posts, and other areas of discussion surrounding protecting sensitive data. Sometimes that interchange of words further complicates already complex matters. A recent article by Steve Touw explores the confusion surrounding encryption and redaction methods in the CCPA. Touw breaks down encryption and redaction to their basic components which shows that each method ultimately lives in two different worlds: encryption in the security world, and redaction in the realm of privacy.

But aren’t privacy and security essentially the same thing, which is the means of protecting an asset (in our case, data)? While both arguably have the same goal in protecting a particular asset, privacy and security are different in the way in which they approach risk assessment and evaluation. In the scope of information management:

Security pertains to actions that protect organizational assets, including both personal and non-personal data.

Privacy pertains to the handling, controlling, sharing, and disposal of personal data.

Security and privacy do share key concepts and concerns, including appropriate use, confidentiality, and access to organizational assets (including personal data). Nonetheless, implementing security practices doesn’t necessarily guarantee privacy; a quote that makes the rounds in privacy professional groups is “You can have security without privacy, but you cannot have privacy without security.”

An example of the above quote comes from when you log into a system or application. Let’s use staff access to the integrated library system for this example. A login allows you to control which staff can access the ILS. Assigning individual logins to staff members and ensuring that only those logins can access the staff functions in the ILS is a security measure. This security measure protects patron data from being inappropriately accessed by other patrons, or others looking for that data. On that point of using security to protect privacy, so far, so good.

Once we get past the login, though, we come to a potential privacy issue. You have staff logins, which prevent unauthorized access to patron data by the public, but what about unauthorized access to patron data by your own staff? Not every staff member needs to have access to patron data in order to perform their daily duties. By leaving staff logins to have free reign over what they can access in the ILS database, you are at risk of violating patron privacy even though you have security measures in place to limit system access to staff members. To mitigate this risk, another security measure can be used – assigning who can access what through role or group level access controls. Most ILSes have a basic level of role-based access controls where systems administrators can assign the lowest level of access needed for each role, and applying these roles consistently will limit the instances of unauthorized access to data by staff.

All the security measures in the world, nonetheless, will not mitigate the risk of privacy harm to your patrons if your ILS is collecting highly sensitive data in the first place! These security measures don’t prevent you from collecting this type of data. This is where privacy policies and determining what data needs to be collected to meet operational needs come into play. If you don’t collect the data, the data cannot be breached or leaked.

It’s clear from this example that both privacy and security have parts to play in protecting patron privacy. Understanding these parts – where they overlap, and where they diverge – will help you through building and maintaining a robust set of data privacy and security practices throughout your organization.