Lightbeams and Stickers and Summer, Oh My!

Welcome to this week’s Tip of the Hat and to the unofficial start of summer. This week’s newsletter comes to you in two parts as you get back into the work routine after the holiday weekend.

Trackers, trackers everywhere

Many of you probably have at least some protection against web site trackers in your browser of choice, but do you know the true extent of user tracking on the web – perhaps even the website for your library or business? The Firefox Lightbeam add-on provides a comprehensive overview of the various trackers on a website that you’d otherwise miss if you try to compile this information on your own. The overview not only captures trackers from the web site but also third-party trackers. Once you have installed the add-on, disable your tracker blockers and browse the web, and Lightbeam will visualize how you are being tracked throughout your entire web browsing session. Give this tool a try if you want to get a sense of the extent of tracking of library patrons visiting multiple sites across different owners (for example, a patron going from a library home page to search for an ebook, landing on a results page in the discovery layer, and then going to the ebook vendor’s site). H/T to SwiftOnSecurity for tweeting about the extension!

Stickers, stickers everywhere

The Executive Assistant has been busy as LDH prepares for our trip to ALA Annual in DC, but she’s found some time to give us a sneak peek of what will be available at our table…

A brown hat sticker placed on top of a black cat looking at the camera.
For those who will be at the Exhibit Hall Grand Opening on Friday, June 21st, we will have laptop stickers! Below are the two designs that will be available: a hat sticker and a hexagon sticker.

 Two stickers: one hexagon sticker with a brown hat, and the other a brown hat.

Subscribers to this newsletter don’t have to wait until Annual to get their stickers – reply to this email and we will mail a few stickers your way. Stick them to your laptop, your door, your water bottle, or any other place where you want to tell folks that you care about library privacy and to “Follow The Hat.” Many thanks to Scott Carlson for creating the sticker design.

Humans, Tech, and Ethical Design: A Summit Reflection

Welcome to this week’s Tip of the Hat!

Last Saturday LDH attended the All Tech Is Human Summit with 150+ other technologists, designers, ethics professionals, academics, and others in discussing issues surrounding technology and social issues. There were many good conversations, some of which we’re passing along to you all as you consider how your organization could approach these issues.

The summit takes inspiration from the Ethics OS Toolkit which identifies eight risk zones in designing technology:

  1. Truth, Disinformation, Propaganda
  2. Addiction & the Dopamine Economy
  3. Economic & Asset Inequalities
  4. Machine Ethics & Algorithmic Biases
  5. Surveillance State
  6. Data Control & Monetization
  7. Implicit Trust & User Understanding
  8. Hateful & Criminal Actors

Each risk zone has the potential to create social harm, and the Toolkit helps planners, designers, and others in the development process to mitigate those risks. One of the ways you can mitigate risk in many of the areas in the design process (like the Data Control and Surveillance zones) is incorporating privacy into the design and development processes. Privacy by Design is an example of integrating privacy throughout the entire process, instead of waiting to do it at the end. Much like technical debt, incorporating privacy and other risk mitigation strategies throughout the design and development process will lessen the need for intensive resource investment on short notice when something goes wrong.

Another way to approach ethical design comes from George Aye, co-founder of the Greater Good Studio. In his lightning talk, George identified three qualities of good design:

  • Good design honors reality
  • Good design creates ownership
  • Good design builds power

Viewed through a privacy lens (or, in the case of LDH, with our data privacy hat on), these qualities can also help approach designers and planners in addressing the realities surrounding data privacy:

  • Honoring reality – how can the product or service meet the demonstrated/declared needs of the organization while honoring the many different expectations of privacy among library patrons? Which patron privacy expectations should be elevated, and what is the process to determine that prioritization? What societal factors should be taken into account when doing privacy risk assessments?
  • Creating ownership – how can the product or service give patrons a sense that they have ownership over their data and privacy? How can organizations cultivate that sense of ownership through various means, including policies surrounding the product? For vendors, what would it take to cultivate a similar relationship between library customers and the products they buy or license?
  • Building power – building off of the ownership questions, what should the product or service do in order to provide agency to patrons surrounding data collection and sharing when using the product or service? What data rights must be present to allow patrons control over their interactions with the product or process? Libraries – how can patrons have a voice in the design process, including those more impacted by the risk of privacy harm? Vendors – how can customers have a voice in the design process? All – how will you ensure that the process will not just be a “mark the checkbox” but instead an intentional act to include and honor those voices in the design process?

There’s a lot to think about in those questions above, but the questions illustrate the importance of addressing those questions while still in the design process. It’s hard to build privacy into a product or services once the product is already out there collecting and sharing high-risk data. Addressing the hard ethical and privacy questions during the design process not only avoids the pitfalls of technical debt and high-risk practices, but also provides the valuable opportunity to build valuable relationships between libraries, patrons, and vendors.

AI, Read The Privacy Policy For Me

Welcome to this week’s Tip of the Hat! Last week we took a deep dive into ALA’s privacy policy to figure out where our information was going if we agreed to receive information from exhibitors while registering for the Annual Conference.

[Which, ICYMI, LDH will be exhibiting at Annual! Let us know if you want to meet up and talk about all things privacy and libraries!]

As we encountered last week, privacy policies are not the most exciting documents to read. In fact, you can test out this theory by checking out the impressive list of electronic resource vendor privacy policies generated by the folks at York University (the code is available on GitHub). Try picking out a couple of privacy policies and read them from start to finish now. We’ll be here waiting for you.

…..

……. all done?

Chances are, you probably found yourself skimming the policies if you made it all the way to the bottom. If so, you’re not alone – studies have shown that the majority of folks do not read these policies, which could lead to surprises and confusion when your data is collected, shared, or breached. The fact is that it takes a long time to get through long, detailed documents – a recent study showed that many privacy policies require a high reading level and up to around a half hour to read. What’s a busy person to do?

One way some folks are addressing this is to let the machines do the reading for you. The last few years have seen several tools that use AI and machine learning (ML) to analyze privacy policies, selecting the very important parts that users should know. For example, the Usable Privacy Policy Project, an NSF funded project, used a collection of 115 privacy policies annotated by law students to train machine classifiers to annotate over 7000 privacy policies. Another group of researchers used the same 115 annotated privacy policies for ML training, creating two different tools for AI-generated analysis of policies. The first is Polisis, which creates a Sankey diagram based off of the AI’s analysis of the policy, while the second is Pribot, a chatbot that allows users to explore and ask questions about specific privacy policies.

Each AI privacy analysis tool takes a different approach in displaying the results to the end users. Let’s use OverDrive’s privacy policy as our test policy. [1] The Usable Privacy site uses different colored fonts to indicate which parts of the policy belong to 10 different categories. The site also directs us to another policy analysis of OverDrive’s Privacy Policy for Children. Users can click on a category to only show the colored sections of the policy, or to exclude it.

A screenshot of Usable Privacy's analysis of the OverDrive privacy policy.

For Polisis’ analysis of OverDrive’s policy, the site takes the same ten categories and creates separate visualizations for most of them. Users can click on a stream to highlight it in the diagram – for example, showing what information is shared and for what reason.

A screenshot of Polisis' analysis of OverDrive's privacy policy.

We are still a ways away before widespread adoption of AI-annotated privacy policies; however, the possibilities are promising. With GDPR, CCPA, and other upcoming privacy regulations, AI and ML could help end users in keeping up with all the changes in policies, as well as dig through mountains of text in a fraction of the time it would have taken to manually read all of the text. It will still take a considerable human role in training the AI and supervising the ML to ensure proper analysis, though, as well as human labor in creating effective and accessible interfaces. Perhaps one day there could be an API service that can have AI analyze the privacy policies listed on the York University page.

[1] Both sites are analyzing older versions of OverDrive’s privacy policy. The most up to date privacy policy is at https://company.cdn.overdrive.com/policies/privacy-policy.htm.

Monday Mystery: Conference Information Sharing

Welcome to this week’s Tip of the Hat! It seems that spring has just arrived for many of us in the US; however, the calendar tells us that we are only weeks away from the ALA Annual Conference in Washington DC in June. Our Executive Assistant was going through the PDF registration form the other day and noticed the following question:

A text box with the following text: "Attendees may receive exciting advance information from exhibitors like invitations, contests and other hot news. COUNT ME IN!" Yes/No checkboxes are next to the last sentence.

The above question on the registration form asks if the person (or in this case, cat) wants to receive information from conference exhibitors. The Executive Assistant paused. What does checking the “Yes” box all entail? Since we’re in the data privacy business, this is a perfect Monday Mystery for us to investigate.

After a quick search of the conference website, we land on ALA’s Privacy Policy at http://www.ala.org/privacypolicy. If you haven’t spent time with a privacy policy, it can seem daunting or downright boring. Let’s walk through this policy to find out what happens when we check the “Yes” box.

The “Information Collection & Use” section lays out what information is collected and when. They define “personal data” as information that can be used to identify someone: name, email, address, etc. The section breaks down some common actions and situations when ALA collects data, including event registration. We already guessed that ALA was collecting our information for event registration purposes, but we need to dig deeper into the policy to answer our question.

We then find a section labeled “Information Sharing” in which we might find our answer! The section lists who ALA shares information with in detail, including the type of data and circumstances that the data is shared. “Services Providers” seems promising – that is until we get into the details. The data listed that is shared to service providers is mostly technical data – location data, log files, and cookies – and has nothing regarding giving information to receive updates from exhibitors. Back to square one.

Moving down the policy, we arrive at the “Your Rights and Choices Regarding Your Information” section, which lists the following right:

Object to processing – You have the right to object to your Personal Data used in the following manners: (a) processing based on legitimate interests or the performance of a task in the public interest/exercise of official authority (including profiling); (b) direct marketing (including profiling); and (c) processing for purposes of scientific/historical research and statistics;”

Okay, we have the right to ask ALA not to use our personal data for marketing purposes. That’s a very important right to have, though that doesn’t exactly solve the mystery of what happens when we click on the “Yes” box.

This, readers, is where we are going to cheat in this investigation. It’s time to put our exhibitor hat on!

Exhibitors at major conferences are usually offered some form of registrant/member list as a means to promote their business before the conference. ALA does the same with Annual, and exhibitors can rent attendee lists. From https://2019.alaannual.org/list-rental, exhibitors have the option to “[t]arget buyers by industry segment, demographic profile or geographic area.” So, just not names and emails are shared!

On the exhibitor side, having that information would allow for targeted marketing – instead of blasting the entire attendee list, exhibitors can reach out to those most likely to be receptive to their service or product. On the attendee side, some want to have this type of targeted marketing to plan their time at the conference efficiently, or to do homework before hitting the exhibit hall. For other attendees, though, it means more emails that they’ll just delete or unsubscribe. And then there’s the question about what happens to that attendee data after the conference…

In the end, we still have a bit of a mystery on our hands. The only reason we got this far in our little Monday Mystery investigation is that LDH has been bombarded with emails trying to sell us attendee lists which tipped us off to start looking at the exhibitor section of the conference site. Your average conference attendee wouldn’t have that information and would be left scratching their heads due to the lack of information at the point of registration about what information is shared on these attendee lists. While we don’t have a clear answer to end today’s investigation, we hope that this gives our readers a little reminder to do some research the next time they are asked a similar question on a registration form.

Speaking of ALA Annual, LDH Consulting Services is excited to announce that we will be exhibiting in DC in booth 844! Many thanks to Equinox Open Library Initiative for making exhibiting at ALA Annual possible for LDH. Give us a ping if you will be at Annual and would like to talk more about LDH can do for your organization.

#ChoosePrivacy 2019: Privacy and Equity

Welcome to this week’s Tip of the Hat! This week marks the start of Choose Privacy Week, hosted by the ALA Office of Intellectual Freedom. We briefly covered CPW in our National Library Week newsletter, but we couldn’t pass up the chance to join in the festivities of a week dedicated to library privacy.An image of two arms coming together in front of a padlock, with the text "Inclusive Privacy, Closing the Gap" below it. To the right of the image is the text "May 1-7 Choose Privacy Week #chooseprivacy".

This year’s Choose Privacy Week is focusing on how privacy in libraries is vital for those who are otherwise targeted for surveillance and data-based discrimination elsewhere in the US. Library workers stress privacy as a core tenet of Intellectual Freedom; however, this focus can be very narrow with regard to protecting a subset of patron information from specific unauthorized uses and access, e.g. a government entity accessing a patron’s circulation records. This narrow interpretation of the role privacy plays in the library does not take into account the evolution of the role of data in libraries and in society. Data has taken its place as a critical tool in ensuring funding and continued operations. We see this evolution with the increasing prevalence of customer relations management systems, learning analytics, and identity-based services (such as RA21) in the library environment.

With the rise of data-as-valuable-asset, comes the dark side, or taking a cue from Bruce Schneier, the toxicity of data. Data has been used to target marginalized populations via surveillance and other means. How can data harm vulnerable populations? Taking a look around the Seattle area, here are two recent cases in which data collection inflicted real-world harm on people:

Another resource highlighting past and potential harms is http://neveragain.tech/. This pledge site started when the current US president proposed a registry of Muslims in the US. The page highlights some of the ways that technology was used against marginalized populations throughout recent times, as well as the harms that come with data collection.

Reframing the conversation about why privacy is important in libraries requires rethinking the field’s approaches surrounding privacy practices and policies. Privacy with regard to pursuing intellectual interests needs to take into account the social factors that come into play when someone from a vulnerable population uses the library. Many libraries market themselves as a “third place” or a place where the community can gather together for a variety of reasons, be it studying, meetings, programs, or even a safer space to spend free time outside of the home, work, or school. While data is useful in relation to building and maintaining operations that best benefit all patrons in the library’s third place role, care needs to be taken to ensure that the same data is not used to harm patrons as demonstrated in the cases above.

If you are looking for how to approach your privacy practices with an equity lens, you will hear from a variety of backgrounds and viewpoints during this year’s CPW. Maybe you’ll find something that you haven’t considered in relation to your privacy practices, or find an opportunity to be proactive in building trust with patrons. In either case, we’re looking forward to finding out more about how libraries can align privacy with equity during Choose Privacy Week!

[REDACTED] – Redacting PII From Digital Collections

Welcome to this week’s Tip of the Hat! The Executive Assistant is back, and you know what that means…

A sitting black cat looking up at the camera, meowing loudly.
We’re back in business, newsletter-wise!

This week’s topic comes from a recent post to the Code4Lib mailing list. A library is planning to scan a batch of archival documents to PDF format, and are looking for ways to automate the process of identifying personally identifiable information [PII] in the documents and redacting said PII. The person mentioned that the documents might contain Social Security Numbers or credit card numbers.

Many libraries and archives have resources – digital and physical – that contain some form of PII in the source. While physical resources can be restricted to specific physical locations (unless someone copies the source via copier, pencil and paper, camera, etc.), digital resources that are available through a digital repository can increase the risk of privacy harm if that digital resource contains unredacted PII.

When libraries and archives are incorporating personal collections, research data sets, or other resources that may contain PII, here are some considerations to keep in mind to help through the process of mitigating the risk of data breaches and other privacy harms:

Who is included or mentioned in the resource – Some archival collections contain PII surrounding the individual who donated their materials. When dealing with institutional/educational records or research data sets, however, you might be dealing with different types of PII regulations and policies depending on who is included in the resource and what type of PII is present.

What PII is in the resource – When most folks think about PII, they think about information about a person: name, Social Security number, financial information, addresses, and so on. What tends to be overlooked is PII that is information about an activity surrounding a person that could identify that person. Think library checkout histories, web search histories, and purchase history. You will need to decide what types of PII needs redacting, but keep both facets of PII in mind when deciding.

What is the redaction workflow – This gets into the question from the mailing list. The workflow of redacting PII depends on several factors, including what PII needs to be redacted, the number of resources needing to be redacted, and what format the resource is in. Integrating redaction into a digitization or intake workflow reduces the time spent retroactively redacting PII by staff. Here I’d like to offer a word of caution – while automating workflows for efficiency can be positive, sub-optimizing a part of a workflow can lead to a less efficient overall workflow as well as have negative effects on work quality or resources.

What tools and resources are available – While looking at the overall workflow for redacting PII, the available resources and knowledge available to you as an organization to build and maintain a redaction workflow will greatly shape said workflow, or even the ability to redact PII in a systematic manner. There are many commercial tools that automate data classification and redaction workflows, and there are options to “roll your own” identification and redaction tool using various programming languages and regular expressions. If you work at a library or archive that is part of a bigger institution, there might be tools or resources already available through central IT or through departments that oversee compliance or information security and privacy. Don’t be afraid to reach out to these folks!

If you’re wondering where to begin or what other organizations approach redaction, here are a few resources, here are some resources to start with:

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!]

Into the Breach!

Welcome to this week’s Tip of the Hat!

Last week brought word of two data leaks from two major library vendors, Elsevier and Kanopy. Elsevier’s leak involved a server storing user credentials, including passwords, that was not properly secured. Kanopy’s leak involved an unsecured database storing website logs, including user activity. Both leaks involved library patron information, and both leaks were caused by a lapse in security measures on the part of the vendor.

As the fallout from these two breaches continues in the library world, now is as good of a time than any to talk about data breaches in general. Data breaches are inevitable, even if you follow security and privacy best practices. What matters is what you do when you learn of a possible data breach at your library.

On a high level, your response to a possible data breach should look something like this:

  1. Determine if there was an actual breach – depending on the nature of the breach, this could be fairly easy (like a lost laptop with patron information) or requires more investigation (like looking at access logs to see if inactive accounts have sudden bursts of activity).
  2. Contain and analyze the breach – some breaches can be contained with recovering lost equipment, while others can be contained by shutting off access to the data source itself. Once the breach is contained, you can then investigate the “who, what, when, where, and how” of the breach. This information will be useful in the next steps…
  3. Notify affected parties – this does not only include individual users but organizational and government agencies as well.
  4. Follow up with actions to mitigate future data breaches – this one is self-explanatory with regard to applying what you learned from the breach.

The US does not have a comprehensive federal data breach notification law. What the US does have is 50+ data breach notification laws that vary from state to state. These laws have different regulations pertaining to who needs to be notified at a certain time, and what information should be included in the notification. If you are also a part of a larger organization, that organization might have a data breach incident response procedure. All of the above should be taken into consideration when building your own incident response procedure.

However, that does not address what many of you might be thinking in light of last week’s data breaches – how do you prevent having your patrons’ information breached in a vendor’s system? It’s frustrating when your library’s patron information is left unsecured with a vendor, be it through unencrypted passwords and open databases containing patron data. There are a couple of steps in mitigating risk with the vendor:

  • Vendor security audits – One practice is to audit the vendor’s data security policies and procedures. There are some library related examples that you can pull from: San Jose Public Library performed a vendor security audit in 2018, while Alex Caro and Chris Markman created an assessment framework in their article for the Code4Lib Journal.
  • Contract negotiations – Writing in privacy and security clauses into a vendor contract introduces a layer of legal protection not only for your patrons but to your organization as a whole, with regards to possible liability that comes with a data breach. Additions can clarify expectations about levels of security surrounding patron data in vendor systems as well as data breach management expectations and roles between the vendor and the library.

Ultimately, it’s up to the vendor if they want to follow security best practices and have a data breach incident management procedure (though, if a vendor chooses not to implement security protocols, that could adversely affect their business). Nonetheless, it never hurts to regularly bring up security and privacy in contract negotiations and renewals, procurement processes, and in regularly scheduled vendor rep meetings. Make it clear that your library considers security and privacy as priorities in serving patrons, and (hopefully) that will lead to a partnership that is beneficial to all involved and leaves patrons at a lower risk of having their data breached.

Phew! There’s a lot more on this topic that can be said, but we must leave it here for now. Below are a couple of resources that will help you in creating a data breach incident response plan:

#dataspringcleaning

Welcome to this week’s Tip of The Hat!

This week’s newsletter is inspired from last week’s #ChatOpenS Twitter chat about patron privacy, where the topic of #dataspringcleaning made its appearance.

I’m starting the hashtag #dataspringcleaning — I need to do this in my personal life, too! https://t.co/ueVfafKDQ0
— Equinox OLI (@EquinoxOLI) March 13, 2019

Springtime is around the corner, which means Spring Cleaning Time. While you are cleaning your physical spaces, take some time to declutter your data inventory. By getting rid of personally identifiable data that you no longer need, you are scrubbing some of the toxicity out of your data inventory, and lessening the privacy risks to patrons.

When you are done with data, what do you do with it? First, you need to check in to see if you are truly done with that data. Unfortunately, we cannot use Marie Kondo’s approach by asking if the data sparks joy, but here are some questions to ask instead:

  • Is the dataset no longer needed for operational purposes?
  • Are you done creating an aggregated dataset from the raw data?
  • Is the dataset past the record retention period set by policy or regulation? Don’t forget about backup copies as well!

Once you have determined that you no longer need the data, it’s time to clean up! For data on paper – surveys, signup or sign in sheets, reservation sheets – shred the paper and dispose of it through a company that securely disposes of shredded documents. Resist the temptation of throwing the shredding into the regular recycling bin – if your shredder shreds only in long strips, or otherwise doesn’t turn your documents into tiny bits of confetti, dumpster divers can piece together the shredded document.

Electronic data requires a bit more scrubbing. When you delete electronic data, the data is still there on the drive; you’ve just deleted the pointer to that file. Using software that can wipe the file or the entire drive will reduce the risk of someone finding the deleted file. There are free and paid software options to complete the task, depending on your system and your needs (hard drive, USB sticks, etc.).

And now we get to the fun part of deleting data. Any disc drives, CDs, floppy disks, or (where I give my age away) backup tape drives that held patron data need to be disposed of properly as well. Sometimes you are close to a disk disposal center where you can destroy your drives via degaussing machines. If you can’t find a center, then you have to literally take matters into your own hands. Remember that scene from Office Space with the printer?

A man beating a printer with a baseball bat.
That is what you are going to do, but with safety gear. Hammers, power drills, anything that will destroy the platters in the drive or the disk itself – just practice safety while doing so!

And who says that cleaning can’t be fun?

Resources to get you started:

California [Privacy] Dreamin’

A young white boy standing outside of a car saying Californiaaaa.
California is a trendsetter when it comes to state regulation. California’s 2003 data breach notification regulation served as the inspiration for many other states in later data breach regulations. It should be no surprise to learn that California is again setting a trend in data privacy and security regulation.

The California Consumer Protection Act (CCPA) passed in 2018 after a short six months in the state legislature. The Act models the European Union’s GDPR. Depending on who you talk to, GDPR’s enforcement date of May 2018 was one of the reasons why the Act was rushed through the state legislature. Some of the similarities between GDPR and CCPA include user’s rights to request, access, receive, and to delete any personal data that the business has collected.

CCPA differs in several key ways from GDPR, nonetheless. One difference is CCPA’s scope. To fall under CCPA, your business (this most likely includes libraries and library vendors!) must meet at least one of the following criteria:

  • Have $25 million or more in annual revenue,
  • Possess the personal information of more than 50,000 Californian consumers, households, or devices, or
  • Earn more than half of its annual revenue selling Californian consumers’ personal information

Not having a physical business presence in California is not a guaranteed exemption from CCPA compliance. You have to prove that you are not doing business in the state, which can be tricky at best. Most libraries who will fall under the scope of CCPA will most likely do so due to the second criteria of processing personal information.

Even though the CCPA passed in 2018, the enforcement date is not until January 1st, 2020. State legislators can change the Act up to the enforcement date, which makes planning for CCPA compliance difficult. There have been major amendment proposals to CCPA in the past few months: some to address problematic lines in the Act, while others add extra protections. The latest amendment is the “Privacy for All” Act in which further extend the rights of consumers, including more explicit notification and consent for data collection and use, as well as prohibiting discrimination against customers who choose to limit the data collected and shared by the business.

There remain many other loopholes. One loophole that will affect libraries and vendors is who can make a data request. Currently, the definition of “personal information” is very broad in the CCPA – not only it includes data about a person, but about the household associated with that person. For libraries, this could have ramifications regarding patrons requesting information about a member of their household, including adult children, ex-partners, or for libraries who grant teens over the age of 13 the same confidentiality privileges as adults. Confidentiality and privacy policies and procedures will need to be reviewed in light of this broad definition, as well as organization-wide discussions about the unintended consequences for patron privacy.

With other states adopting CCPA-type laws, libraries and vendors who do not fall under CCPA’s scope will have to reckon with CCPA. That is unless the US Federal Government passes a privacy law that overrules individual state laws. As always, stay tuned!

Resources for further reading: