Stewardship or Surveillance?: The Ethics of Data Minimization

Libraries need to collect data, but have a duty to their patrons

Authors:

Sam Suber
A librarian practicing data minimization

In the library technology landscape, we often find ourselves caught between two powerful currents. On one side is our foundational ethical commitment to patron privacy: whatever a user reads or accesses is their own business. On the other side is the rising tide of institutional pressure for learning analytics and assessment data to prove the library’s value to the university’s bottom line or to provide evidence for mandatory accreditation reviews.

How do we reconcile the library as a sanctuary for privacy with its function as a data-driven node in the academic ecosystem? The answer is a recommitment to data minimization and privacy by design principles.

The Core Conflict: Stewardship vs. Surveillance

For decades, the standard library practice regarding data was to collect the data, use the data for the transaction, and then destroy it. If a book was returned, the link between the book and the patron was severed.

However, the modern “student success” narrative has complicated this. Administrators and vendors have increasingly urged libraries to feed data into larger institutional repositories to fuel predictive modeling. This is often framed as the “holy grail” of retention: the ability to see a holistic, 360-degree view of a student’s life to catch them before they fail. For example, by using a student’s library interactions as data points (e.g., database logins, room bookings) an algorithm could be designed to forecast their likelihood of dropping out. Many librarians, already experiencing “assessment burnout,” feel the weight of this arms race. There is this constant pressure to produce more granular metrics to justify a budget that was once a given.

While these efforts are well intentioned, answering them requires a level of persistent tracking that moves the library away from stewardship and dangerously close to surveillance. This creates a “chilling effect,” where students may hesitate to research sensitive topics if they know their footprints are being permanently recorded and analyzed.


🔥 Stay up-to-date with LibTech Insights by signing up for our free newsletter. Just one weekly email with our new blog posts, top tech news stories, and other bonus content. Check out some posts from our archive:

💜 ALA is having its 150th anniversary. Come celebrate with us!


Returning to the Roots: Data Minimization as Ethics

Data minimization is not necessarily a technical constraint but, rather, an ethical stance. It basically says that we should limit data collection strictly to what’s necessary to deliver essential services.

For example, if a patron is checking out a laptop, we would need the patron’s ID and the laptop’s barcode number. Once the laptop is returned, do we need to keep a permanent record of who borrowed it to maintain inventory? Likely not.

Adopting this data minimization mindset forces us to answer these questions before rolling out any new tool:

  1. Why do we need this data point?
  2. How long do we need to keep it?
  3. Who else will have access to it?

From Theory to Practice: A Data Retention Matrix

To help determine whether a data point passes a specific ethical test for data minimization, librarians can apply a decision matrix to their workflows. This table helps distinguish between operational necessity and data hoarding. Librarians can use this table as an example or to build off of.

Data CategoryOperational NecessityRetention RuleMinimization Strategy (Ethical Goal)Legal/Audit Compliance (Legal Reality)
Circulation RecordsRequired to track inventory and manage fines/feesActive Only. Retain while the item is checked out or fines are outstandingOnce the transaction is resolved, sever the link between the user ID and item ID immediatelyConflict: Financial auditors often require “proof of transaction” for 3–7 years   Solution: Keep the transaction ID and date, but scrub the specific book title.
Authentication Logs (OpenAthens, EZProxy)Security auditing and troubleshooting access issuesRolling Window. Keep for 30–90 days for security reviews then purgeAnonymize logs after retention window if long term stats are neededIT security policies often mandate 90 days for forensic “incident response”
Reference InteractionsManaging follow-up questions or complex research consultationsCase-based. Retain name/email until case is resolvedRemove personal identifiers from the interaction record before moving it into the logging databaseLow risk. Usually classified as “transitory records” with no mandatory retention period
Learning AnalyticsUnderstanding how library usage impacts student success (institutional reporting)Aggregate Only. Never retain student history for assessment purposesPrioritize cohort-level aggregation. If IDs are required, use pseudonymization§ (salted hashes) with a mandatory “Key Destruction” policy after the reporting cycle to prevent long-term trackingFERPA* requires that if this data is identifiable, it must be part of a secure student record.
Computer/Room BookingManaging limited resources and prevent monopolizationSession-based. Retain only for the duration of the reservationConfigure booking system to delete user details 24 hours after reservation endsMost state and university retention schedules (like the GRRS†) allow for the destruction of “scheduling materials” as soon as they lose administrative value. No long-term audit requirement exists for who was in a room, only that the room was used
Web & Discovery AnalyticsUnderstanding site traffic, broken links, searchImmediate Anonymization‡. No retention of full IP addressesMatomo or Fathom are good privacy first tools. If using Google Analytics, enable IP anonymization and disable data sharing among Google productsNo legal requirement to track specific visitors. GDPR/CCPA¶ often require “Opt-Out” or “Opt-In” banners for nonessential tracking

Key:

* FERPA (Family Educational Rights and Privacy Act) is a federal law in the United States that protects the privacy of student education records.

† GRRS (General Records Retention Schedules) is a legally mandated document used by universities (especially public ones) to manage the lifecycle of information.

‡ Anonymization is the process of permanently destroying any link between the data and the individual. Once data is anonymized, it can never be “re-identified.”

§ Pseudonymization (and Salted Hashes) is when you replace a student’s name or ID with a “token” (a string of random characters). The “Salt” is when you add a random string to the data before it is hashed to make it even harder to crack.

¶ GDPR (General Data Protection Regulation) European Union and CCPA (California Consumer Privacy Act), which grant individuals the right to access and delete their personal data (often called the “Right to Be Forgotten”). While primarily targeting commercial entities, these laws have forced global library vendors to adopt privacy standards for all users by default.     

The “Privacy by Design” Approach

In truth, we cannot ignore the reality that libraries must demonstrate impact. However, we can satisfy assessment needs without sacrificing privacy by using a “Privacy by Design” framework. This approach embeds privacy into the architecture of our systems rather than an afterthought.

Here is how we can balance the scales:

Aggregate data, don’t individualize

The pressure for learning analytics often comes from the desire to see trends. We can do this through aggregation. For example, instead of saying Steve Smith accessed JSTOR at 2:00 PM. We can instead track that an undergraduate student accessed JSTOR at 2:00 PM. We can then assess usage volume and peak times without retaining Personally Identifiable Information (PII).

Data expiration policies

Privacy by Design requires automated purging. If we must collect granular data for a specific assessment project, the system should be configured to anonymize or delete the data once the project concludes. Data should not be retained just in case it may be useful later.

Vendor contracts diligence

We often feel powerless against large vendors, but we have leverage before we sign. Instead of fighting for privacy during contract renewal, you can actually embed it in your selection process. For example, you could have an RFP (Request for Proposals) kill switch, where the vendor must agree user data is solely owned by the library and must be purged upon contract termination.

You could also leverage your consortium to adopt a “Privacy Rider” addendum regarding data ownership that applies to all member contracts for resources.

Lastly, many platforms default to “opt-in” for data sharing during setup. Make it a standard launch procedure to review every admin setting and turn off “User Experience Improvement” tracking before the link goes live to students.

The Way Forward

The library’s role is not to be a black hole of data or a house of surveillance. It is to be a steward. By advocating for data minimization, we can protect our patrons from data breaches and the effects of constant surveillance. We can participate in learning analytics, but on our own terms, providing insights on populations and services rather than tracking individuals.

In the era where personal data is the world’s most valuable commodity, the most radical technology choice a library can make is the refusal to collect it.

References and Further Reading

For those looking to deepen their understanding of privacy ethics and tips for implementation, these resources provide very helpful guidance:

Privacy By Design (PbD): A foundational framework developed by Ann Cavoukian, Ph.D., that mandates privacy be integrated into the architecture of IT systems and business practices by default, rather than as an add-on.

NISO Consensus Principles on User’s Digital Privacy: A foundational document outlining 12 principles for libraries, publishers, and software providers to respect user privacy.

ALA Library Privacy Guidelines: The American Library Association’s comprehensive checklists for vendors, e-book lending, and library management systems.