A brown hat with the text

Tip of the Hat

21 November 2019

Baking Privacy Into Your Library: The What, How, and Why of Privacy by Design


Welcome to this week’s Tip of the Hat!

This week’s topic comes to you thanks to the endless hours spent last week cleaning up inactive online accounts as part of our #dataspringcleaning efforts at LDH. It’s frustrating as a user not to have the ability to choose how applications and third parties collect and process your data. Not having the ability to delete your account is one example – some systems were not built to delete data. You all have run across other examples, such as the lack of opting out of having certain personal data collected, processed, or shared with other third parties. To an extent, library workers and vendors can determine how much control patrons have over how applications and services collect and process personal data. However, these controls are put into place after the fact, leaving patrons in a lurch with limited privacy options. How can library workers and vendors avoid this lurch?

Enter Privacy by Design (PbD). First created by Ann Cavoukian, then refined by various international organizations, PbD advocates making privacy a priority throughout the lifecycle of a service or application, including the planning and implementation stages. PbD has made a major impact in the privacy and systems development worlds, as well as the legal realm – GDPR is the latest regulation where PbD has made an appearance.

There are seven foundational principles of PbD:
  1. Proactive not reactive; preventative not remedial
  2. Privacy as the default setting
  3. Privacy embedded into design
  4. Full functionality – positive-sum, not zero-sum
  5. End-to-end security – full lifecycle protection
  6. Visibility and transparency – keep it open
  7. Respect for user privacy – keep it user-centric
What would PbD look like for library workers and vendors? An example is turning off any features that might share user activity to others by default. Users who want to share their activity would have the option to turn on the feature, giving the application their consent in doing so. Another example comes from our tale of woe at the beginning of the newsletter – building a system so that a user can delete their account or personal data without consequence to the system’s integrity. It is much easier to create a system that can handle such deletions than to try to retroactively get a legacy system to learn a new trick!

Both examples highlight the user’s ability to control what data is collected, stored, and shared. Notice that privacy by default does not mean not collecting or processing data at all, but instead takes the position of letting users decide what level of privacy they are most comfortable with. On another level, PbD’s integrated approach to privacy in the development lifecycle guides all those involved in the development and planning processes in assessing how systems can protect user privacy and meet business needs at the same time. Discussing data collection and processing, privacy features, and how to address potential user concerns early in the development process can save both time and headaches when the system launches to users.

Below are a few resources to get you started with PbD:
[H/T to Chad Nelson for the inspiration for this week's newsletter title!]
Have a question or topic that you want us to write about? Email us at newsletter@ldhconsultingservices.com!
MailPoet