Chapter 3. The Current State of Practice

This section describes an ongoing study to track the progress of libraries in the implementation of technologies with implications for privacy and security. This study aims to show trends among the body of libraries considered and to help individual libraries become more aware of enhancements needed to their websites to provide better safeguards for privacy and security.

The concerns related to security and privacy issues have been widely disseminated in recent years. The level of compliance with at least nominal levels of conformance in library websites has widespread implications for library users. Increased implementation of encryption via HTTPS and the reduction of advertising trackers will provide increased protection for the private information and online behavior of library patrons as well as improve the reputation of libraries.

A longitudinal study has been underway since early 2018 to measure the implementation of security and privacy measures for public and academic libraries in the United States. This study takes advantage of data in the Libraries.org directory of libraries and automated procedures to capture the characteristics of library websites relating to privacy and security.

Methodology

This study centers on the technical characteristics of library websites in order to identify trends related to privacy and security. The methodology for the study involves automated inspection of library websites via the URLs recorded in the Libraries.org library directory. Only the main URL of each library organization is considered. Although the technical details of online catalogs, discovery services, repositories, and external information products have at least as much significance for the privacy of patron data, these were not considered in scope for this project and may be addressed in a later phase of work.

The automated scripts were developed by the author in the Perl programming language. These scripts initiate a request of the primary URL recorded for each selected library and test for a variety of technical characteristics related to privacy and security. The primary script can be run manually on demand and is also scheduled for automated execution monthly.

A reporting tool was developed to display the aggregate characteristics for each of the core selection groups. This tool includes a visualization of the portions of HTTP and HTTPS implemented across the libraries, any error codes recorded in crawling the sites, and the numbers of libraries where specific tracking agents were detected. Another reporting tool was created to display the security and privacy characteristics of each library, which can be viewed from each directory entry in Libraries.org.

Data Sources

The Libraries.org directory is a component of Library Technology Guides, a website maintained by the author that includes a variety of data repositories developed through a custom-built content management system. Data is managed through an implementation of the open source MySQL relational database. The content management system, controlling the presentation, entry, and editing of records, was written in Perl. Custom scripts developed in Perl enable the creation of specialized reports and visualizations related to any of the underlying data.

Libraries.org directory

https://librarytechnology.org/libraries

Library Technology Guides

https://librarytechnology.org

The Libraries.org directory includes a table that aggregates many different characteristics. The directory includes libraries from all countries, with over 185,000 total entries. Coverage across countries is uneven, with those in the United States having the most comprehensive and accurate data. The database includes 4,081 entries for academic libraries in the United States and 17,308 for US public libraries.

Although the Libraries.org directory includes data from all global regions, currently only the data for US public and academic libraries can be considered sufficiently complete and accurate for this type of study. Work is underway to improve data representing other counties to enable expansion of the study.

Data Structure

The table includes many different columns that describe the organizational structure, locational and demographic details, technology products implemented, statistics, and other categories. Some of the relevant columns for this study include

• LibraryName: the name of the library.
• Institution: the parent institution of the library.
• LibraryWeb: the URL for the library’s main website.
• LinkResponseCode: the HTTP status code returned by the site.
• LinkCheckDate: the date when the site was last checked.
• SecurityPrivacy: a text field containing multiple name/value pairs relating to privacy and security. The multiple values structured into this field enable flexibility in what data is collected without having to add new columns to the main table.
  • CheckDate: the date the last automated check was performed.
  • Protocol: HTTP or HTTPS.
  • Redirect: detected behavior regarding redirection from HTTP to HTTPS.
  • PageRetrievalStatus: whether the automated process was able to capture the content of the web page.
  • GoogleAnalytics: whether Google Analytics was detected.
  • Google Analytics Anonymize: Is the setting enabled to anonymize Google Analytics data?
  • Google Custom Search: Is Google Custom Search implemented?
  • Google Tag Manager: Is the Google Tag Manager implemented?
  • DoubleClick: Tracking tag detected for Double Click?
  • NewRelic: Is the New Relic performance monitor enabled?
  • CrazyEgg: Is the Crazy Egg performance monitor enabled?
  • Facebook Custom Audience: Is the Pixel code for Facebook custom audience enabled?
  • Facebook Connect: Is Facebook Connect enabled?
  • AddToAny: Detection of the AddToAny sharing widget?
  • ShareThis: Detection of the ShareThis sharing widget?
  • Inspectlet: Is the Inspectlet user behavior monitoring tool implemented?
  • TwitterAds: Tracking tag detected for Twitter Ads?

Initial Data Collection and Cleanup

The ability to study the technical characteristics of library websites depends on maintaining accurate representations of their URLs. The links of library websites have been an element that has been maintained since the Libraries.org directory was created in 1995. When I started to prepare for the current study in 2016, the completeness and quality of these links were inconsistent. In order to assess the proportions of libraries using HTTPS, having a clean and comprehensive representation of the website URLs was essential.

A project to systematically update library website URLs for directory entries for all the public and academic libraries in the United States was accomplished in July 2017 with the assistance of J. J. Lamanna, Claire Schmieder, and other volunteers. This cleanup project involved finding valid URLs for sites where the URL was reported as broken through automated link checking and identifying working URLs for sites where they had not been previously recorded. Many libraries continue not to have websites; these libraries were also verified.

A relatively small percentage of these websites return HTTP error codes of 500. Most of these sites display through a web browser but may not respond to the testing performed through the automated script.

This work resulted in a set of records of sufficient quality to serve as the basis of the analysis of the websites of these libraries. The data set includes

• 17,308 public libraries, 16,263 of which have valid URLs recorded
• 4,081 academic libraries, 3,935 of which have valid URLs recorded

Automated Link Checking

Given the number of libraries of interest to this study, manual inspection of each site would not be feasible. Instead, automated tools were developed to probe each site and to collect specific characteristics. The Perl script used to validate links has been enhanced over time to include additional tests for redirection and for screening for tracking agents by searching the contents of the web page for specific text strings.

Manual Spot Checking

The data produced through the automated procedures was checked manually for smaller sample groups. This manual inspection was used to refine the scripts and to help identify text strings able to serve as reliable signatures of tracking agents. Manual testing included verifying whether HTTP or HTTPS was implemented through loading the page in a browser and whether expected redirection was implemented. The Google Chrome Developer Tools were used to investigate errors on websites. The Ghostery Chrome browser extension was used to verify the presence of tracking agents.

The methodology based on the inspection of the source coding used can easily underreport the tracking agents that may be employed by a site. The automated script checks only the top-level page and does not load any of the internal links that may activate tracking or advertising agents.

A browser-based utility, such as Ghostery, uses a much more sophisticated method for detecting tracking or advertising agents. Ghostery has a complete library of signatures for all known agents and processes each file linked within the page. Figure 3.1 illustrates Ghostery’s ability to identify tracking agents on a website.

The less sophisticated method used for this study means that some sites that invoke tracking agents will not be counted or reported. Additional programming would be required to enhance the script used for this study to detect all cases of tracking agents.

Website Validation Script

A website validation script was developed to determine specific technical details that relate to the privacy and security issues discussed earlier in this report. The script is executed periodically to capture the current state of practice in these areas. The figures presented in this report represent data current as of July 2019 and will be continually updated and made available on Library Technology Guides.

Updated figures

https://librarytechnology.org/libraries/security/report

The initial phase of the script sets the scope of the libraries to be analyzed. An SQL query is accordingly formed and run to collect the unique Record Identifiers for each directory entry in the group of interest. These interest groups include two smaller selections—members of the Association of Research Libraries and the Urban Library Council—and the two larger selections of all public libraries and all academic libraries in the United States. The script can also process individual entries. These record keys are pushed into an array used by the main control loop of the program.

Once the array has been populated, the script performs tests on each of the library records. The processing is performed in three phases.

Phase I

Basic Link Checking

Using the LWP::UserAgent and HTTP::Request Perl libraries, the script (figure 3.2) issues a request to the recorded URL held in the LibraryLink field and places the response code into a variable ($ResponseCode). If the page request is successful and the server also returns a redirected URL, it is recorded. This is the expected behavior if the URL has been permanently changed to a new link. The script also detects whether the redirection involves an upgrade from an HTTP to an HTTPS link.

The detected information is then saved into the database record. If the Response Code is 200 with no redirection, the script has an option not to update the record. Any other response codes are recorded into the LinkResponseCode field and the current date is placed in LinkCheckDate. Redirected URLs are placed into LibraryWeb and the LinkResponseCode of 200.

Limitations

The basic test performed by this script for the correct deployment of HTTPS has some limitations. Though it accurately determines whether the page is transmitted with HTTPS, it does not check for important conditions that would be reported by a browser, such as whether the page has been encrypted with a valid digital certificate. It also does not check to ensure that the page does not contain any unencrypted content or links. Even though a page may be recorded as using HTTPS, it may not meet the expectations for privacy though the inclusion of mixed content, as shown in figure 3.3, where the site loads images through nonencrypted links.

Phase II

The second phase of the script (figure 3.4) assesses how each website handles redirection. If a site that has been configured to use HTTPS is accessed with a URL using the HTTP protocol, it should ideally automatically redirect to HTTPS. This redirection ensures encryption of transmission even if the user enters from an older link or types in HTTP instead of HTTPS and is classified by the script as Valid. If the site supports HTTPS but does not automatically redirect to HTTPS, it is classified as Passive. Some sites may redirect from HTTPS to HTTP, even when HTTPS is available. This behavior, possibly implemented during a testing or transition phase, is categorized by the script as Invalid. Sites that do not support HTTPS at all are classified as Unsupported. If this phase results in identifying a reliable URL not found in the first phase, it is saved into the record in the LibraryWeb field with a 200 LinkStatusCode and current LinkCheckDate.

Phase III

The final phase of the script (figure 3.5) works with the content of the page retrieved from the website. It follows a simple approach of testing for strings that can be identified as reliable signatures for specific items of interest, such as page tags for analytics or trackers for advertising networks, social networks, or e-commerce entities.

The search patterns identify selected tracking agents of interest. The text strings used to identify each tracker were initially identified through direct access to websites via the Chrome browser and the Ghostery extension. These strings are not necessarily authoritative, but are strong indicators of the tracking agent in question. Further work is needed to develop more authoritative signatures for each tracking agent. In the interim, the indicators should be considered an initial screening that needs to be reviewed manually using Ghostery or other browser plug-ins.

One weakness of the current script is that it is based only on the HTML source of the main page of the library website. It does not check other files that may be loaded from this page, which results in an underreporting of some tracking agents. Some false positives can also take place when the string used as the signature for a given tracking agent may be used for other purposes.

Findings: The Current State of Practice

The study demonstrates that the library community has made rapid progress in the implementation of technologies on their websites needed to provide a reasonable degree of privacy for patron information-seeking activities. In the period from April 2018 through July 2019, there has been a dramatic improvement from less than 10 percent of academic library websites using HTTPS to 92.1 percent. Public libraries have also seen dramatic improvement, though their current implementation stands at 81.7 percent. Tables 3.1 and 3.2 show the changes in percentages for these libraries since April 2018.

Summaries by Category

Another set of reports and graphs shows additional details regarding the relevant technical characteristics across each of the interest groups (figures 3.6–3.12 and tables 3.4–3.12). A basic pie chart (figure 3.6) shows the proportions of libraries still using unencrypted HTTP transmission for their main websites. Although the percentages are dramatically better than those from the beginning of the study, it also shows that there are substantial numbers of libraries that are not offering basic privacy protection, long past the date in which browsers began flagging these sites as unsecure. It will be important to continue monitoring these figures to see if these remaining libraries are able make these needed improvements.

Table 3.3 describes the numbers and percentage of libraries that have implemented redirection in ways needed to ensure private communications. Although over 90 percent of academic libraries now support HTTPS, only 63 percent require it for all sessions. Almost 30 percent of these libraries do not implement redirection on their websites, so users are able to access the site with unsecured HTTP. A small number of sites redirect from HTTPS to HTTP, presumably as an interim state as encrypted configurations are implemented.

The findings regarding the proportion of libraries using some sort of tracking agent on their websites elicits more concern regarding protections in place for privacy. The implementation of Google Analytics on library websites is almost ubiquitous. A relatively small proportion use the outdated Classic tracking code, which was superseded by Universal analytics in 2012. The total number of sites using Google Analytics cannot be determined automatically from the testing script. As noted earlier, when Google Analytics has been deployed using Google Tag Manager, it is not apparent other than to the site owner what tags have been deployed. It is highly likely that those using Google Tag Manager are also using Google Analytics. We can carry this inference into our observations. Based on these assumptions, at least 3,219 out of 3,948 academic libraries, or 81 percent, use Google Analytics. Among public libraries, 10,568 out of 15,865, or 67 percent, have implemented Google Analytics. The numbers of libraries using Google Analytics that have implemented anonymization of IP addresses appears quite low, with only 335 academics and 1,386 public libraries taking advantage of this feature.

The screening for tracking agents related to advertising and social networks reveals substantial numbers of libraries enabling these connections. The most commonly implemented of this type of tracking agent is for Facebook Connect, detected in the websites of 666 academic and 2,102 public libraries. Facebook Custom Audiences, a more intrusive tracking agent, was detected in 486 academic library websites and in 690 public library sites.

A small percentage of library websites include tracking tags for advertising networks, such as Google DoubleClick. This study includes only preliminary investigation regarding the involvement of libraries in the commercial advertising networks. Searching automatically for the signatures for the tracking tags used so far has not been reliable, with both false positives and false negatives when verified through Ghostery.

In addition to the broad groupings of public and academic libraries, this study also selected two smaller groups. The members of the Association of Research Libraries represent the top tier of academic libraries. The Urban Library Council is comprised of public libraries serving larger urban populations. Both of these groups are more likely to have the financial resources and the technical awareness to implement the strongest measures for patron privacy and security.

The two elite groups of libraries show much higher implementation of technologies to protect privacy than the broader populations. All but 2 ARL members implement HTTPS, though 21 out of the 178 in the ULC group, or 11.8 percent, continue to not provide HTTPS encryption. Tables 3.9 and 3.11 provide the details of each of these groups of libraries.

The data collected for each library in the study group is also presented through individual Privacy and Security Report Cards, an example of which is seen in figure 3.10. These report cards aim to provide a quick overview of how well each library has implemented technologies to protect patron privacy. Implementation of encryption and correct redirection are given green checkmark icons (shown in dark gray in figure 3.10); if the library still uses HTTP, a red X icon appears. Yellow checkmarks are provided when any of the tracking codes are detected (shown in light gray in figure 3.10). A red X is presented if Google Analytics has been implemented without the anonymization option. These report cards can be access through each library’s entry in Libraries.org.