Data Discounts

Welcome to this week’s Tip of the Hat!

At LDH we have been known to have a sweet tooth – there are always four to five different types of sweets within reach of the office desk. Therefore, it shouldn’t come to a surprise to our newsletter readers that when presented with the option to get a free cup of Heart Eyes (red velvet cookie dough, white chocolate chips, and heart sprinkles) from a local edible cookie dough vendor, LDH took full advantage of the opportunity to indulge.

The free cup of dough came with a catch, though. The free dough was part of a grand opening celebration for a co-working space. To receive the free dough, you had to give your email address to the co-working space company. Here we have a dilemma – what are the privacy tradeoffs that I’m willing to make for cookie dough?

Multiple times a day we find ourselves asking similar questions – what are the privacy tradeoffs that we’re willing to make for discounts at our favorite store, or a particular brand, or other business? What are the privacy tradeoffs you’re willing to make for everyday items or essential services? A recent opinion piece in The New York Times illustrates this tradeoff with a fictionalized company that finds its inspirations from many different sources, from grocery store loyalty cards to checking in at a store location or posting a brand marketing hashtag on social media. The story also touches on how surveillance and tracking disproportionally affect vulnerable populations, such as those who can’t afford basic services without giving up their data to receive a discount. A real-life example of this happened to LDH. We received an offer from our health insurance company to sign up for a discounted Amazon Prime account that was only available to those receiving insurance through the state health insurance marketplace (we declined the offer).

You can choose to not trade your data for discounted goods and services, though it is getting harder to avoid this data transaction when paying for goods and services, or if you interacted with a business through their website or social media. Even going to a physical store location can involve a data transaction if the business is using beacons to seek out your mobile phone WiFi or Bluetooth signal or using facial recognition technology at their store. If the only way that you can afford health or car insurance is to install a tracking device in your car or to provide data from your health app, then your data is paying for that cash discount.

Currently, you have limited options to protect your privacy when dealing with health and car insurance companies. For other businesses, though, there are some ways you can limit how much data you give to them:

Using one or more of these strategies can limit the amount of personal data collected on you by the business while still receiving the financial incentives provided by the company.

Going back to our “free” cookie dough situation, the co-working space company did get an email address (used for promotions) from us, but nothing more, even though the email form included fields for name, address, and phone number. We got our cookie dough, the company got an email address that will promptly toss their promotional emails into a filtered folder, followed by an unsubscribe request. The things that we will do for free cookie dough…

NISO Cybersecurity webinar, February 12th

Come join LDH and others on Wednesday, February 12th, for a webinar discussion on cybersecurity!

NFAIS Forethought: Cybersecurity: Protecting Your Internal Systems
Every organization, as a standard course of action, should be implementing protection policies and updating protective measures surrounding their confidential data and internal systems. Phishing and malware are a constant threat. As a response, reliable cybersecurity requires an integrated approach in ensuring the safety of networks, devices, and data. How should enterprises and institutions be thinking about their cybersecurity needs? What basic requirements should be in place? What guidelines or best practices exist? What are the best resources? This roundtable discussion will bring together experts active in the field to address these and other questions.

Confirmed participants in this roundtable discussion include: Daniel Ayala, Founder, CISO/Chief Privacy Officer, Secratic; Blake Carver, Senior Systems Administrator, LYRASIS, Becky Yoose, Principal, LDH Consulting Services; Hong Ma, Head, Library Systems, Loyola University of Chicago; Wayne Strickland, Acting Associate Director at Department of Commerce, National Technical Information Service; Christian Kohl, Principal, Kohl Consulting.

NISO members can attend the webinar for free; non-members can also register for the webinar at https://www.niso.org/events/2020/02/nfais-forethought-cybersecurity-protecting-your-internal-systems. We hope to see you there!

Beyond Web Cookies: WordPress, Plugins, and Privacy

Welcome to this week’s Tip of the Hat!

Previous posts in our series about web cookies, tracking, and privacy discussed ways that tracking applications such as Google Analytics can track website users across sites. We covered how using other Google-related products can put site user privacy at risk through third party data collection. This week we explore another area in which online user privacy might be compromised, and this area is one that libraries and library vendors are familiar with – WordPress.

WordPress is one of the most used content management systems – over 35% of the sites you visit on the Web use WordPress. Sometimes libraries need a website that works “out of the box”: install on a local server, pick a theme, edit some pages, and publish. Sometimes libraries choose to host a site on the WordPress.com commercial hosting service. Other times libraries use WordPress when they need a customized site to fit their libraries’ needs. Library vendors also work with WordPress by working with libraries to create customized WordPress sites and plugins.

WordPress is popular for a reason. It’s flexible enough to provide a good basic site with as little or as many customizations as the site owner sees fit. One of the ways WordPress achieves this flexibility is plugins. Because WordPress is Open Source, anyone can write a plugin and share the plugin with others. On the WordPress Plugin Directory site, there are almost 55,000 plugins to choose from, ranging from site statistics and analytics and form creators to social media integrations and email newsletter systems (for example, LDH uses MailPoet). The possibilities plugins bring to a library website are endless.

The same could be said about the ways that plugins can put your patrons’ privacy at risk. WordPress plugins have the potential to collect, retain, and even share your site users’ data to the creators of the plugin and other third parties. For example, some libraries might forego Google Analytics to use Jetpack or other WordPress statistics and site management plugins. What they might not be aware of is that site management plugins like Jetpack also use cookies, along with other tracking methods, to collect user data from your site.

These plugins can carry a security risk as well. WordPress plugins are used to compromise WordPress sites. One such hack happened with the GDPR compliance plugin in 2018 (the irony of this hack is not lost on LDH). What can you do to protect the privacy of your library and site users when using WordPress plugins?

  • Research the developer – some plugins are created by one person, while others are created by companies. Evaluating the developer can help with determining the trustworthiness of the plugin as well as uncover any potential privacy red flags.
  • Read the privacy policy – unfortunately, the Plugin Directory doesn’t have a standard spot for developers to publish their plugin privacy policy, which means that you will need to research the developer’s site. Jetpack has a general site regarding data collection and tracking which some might have skipped over if they didn’t search the support site.
  • Download plugins from trusted sources – the Plugin Directory is a good place to search for plugins, though this doesn’t relieve you from doing some homework before downloading the plugin.
  • Once you download the plugin:
    • Check and change any settings that might be collecting or sharing user data
    • Update the plugin regularly
    • If you no longer use the plugin, delete it from your site

This is only a small part of how you can use WordPress and still protect the privacy of your patrons. In a future installment of the series, we will talk about how you can be proactive in communicating privacy practices and options to your site visitors through WordPress.

Thanks to subscriber Carol Bean for the topic suggestion!

Beyond Web Cookies: The Ways Google Tracks Your Users

Welcome to this week’s Tip of the Hat!

Earlier we discussed the basics of web cookies, including the cookies used in tracking applications such as Google Analytics. However, there are many ways Google can track your online behavior even when you block Google Analytics cookies and avoid using Google Chrome. Because Google provides applications and infrastructure for many web developers to use on their sites, it’s extremely hard to avoid Google when you are browsing the Web.

An example of this is Google Fonts. The LDH website uses a font provided by the service. To use the font, the following code is inserted into the web page HTML code:

link href=”https://fonts.googleapis.com/css?family=Open+Sans&display=swap” rel=”stylesheet”

For those who are not familiar with HTML code, the above line is instructing the web page to pull in the font style from the external fonts.googleapis.com site. The FAQ question about user privacy describes the data exchanged between our site and the Google Font API service. The exact data mentioned in the FAQ is limited to the number of requests for the specific font family and the font file itself. On the surface, the answer seems reasonable, though there is always the possibility of omission of detail in the answer.

This isn’t to say that other Google services provide the same type of assurance, though. In Vanderbilt University Professor Douglas C. Schmidt’s research study about how Google tracks users, many other Google services that collect data that can be tied back to individuals. Schmidt’s study leans heavily toward tracking through mobile devices, but the study does cover how users can be tracked even through the exclusive use of non-Google products thanks to the pervasiveness of third-party tracking and services that feed data back to Google.

We covered some ways that you can avoid being tracked by Google as a web user in our earlier newsletter, including browser add-ons that block cookies and other trackers. Some of the same add-ons and browsers block other ways that Google tracks web users. Still, there is the same question that we brought up in the earlier newsletters – what can web developers and web site owners do to protect the privacy of their users?

First, take an audit of the Google products and API services you’re currently using in your web sites and applications. The audit is easy when you’re using widgets or integrate Google products such as Calendar and Docs into your site or application. Nonetheless, several Google services can fly under the radar if you don’t know where to look. You can make quick work out of trying to find these services by using a browser plugin such as NoScript or Privacy Badger to find any of the domain URLs listed under the Cookies section in Google’s Privacy and Terms site. Any of the domains listed there have the potential to collect user data.

Next, determine the collection and processing of user data. If you are integrating Google Products into your application or website, examine the privacy and security policies on the Google Product Privacy Guide. APIs are another matter. Some services are good in documenting what they do with user data – for example, Google Fonts has documentation that states that they do not collect personal data. Other times, Google doesn’t explicitly state what they are collecting or processing for some of its API services. Your best bet is to start at the Google APIs Terms of Service page if you cannot find a separate policy or terms of service page for a specific API service. There are two sections, in particular, to pay attention to:

  • In Section 3: Your API Clients, Google states that they may monitor API use for quality, improvement of services, and verify that you are compliant within the terms of use.
  • In Section 5: Content, use of the API grants Google the “perpetual, irrevocable, worldwide, sublicensable, royalty-free, and non-exclusive license to Use content submitted, posted, or displayed to or from the APIs”. While not exclusively a privacy concern, it is worth knowing if you are passing personal information through the API.

All of that sounds like using any Google service means that user tracking is going to happen no matter what you do. For the most part, that is a possibility. You can find alternatives to Google Products such as Calendar and Maps, but what about APIs and other services? Some of the APIs hosted by Google can be hosted on your server. Take a look at the Hosted Libraries page. Is your site or application using any libraries on the list? You can install those libraries on your server from the various home sites listed on the page. Your site or application might be a smidge slower, but that slight slowness is worth it when protecting user privacy.

Thank you to subscriber Bobbi Fox for the topic suggestion!

Cookies, Tracking, and You: Part 2

Welcome to this week’s Tip of the Hat! We covered the basics of web cookies in Part One, including tracking and what users can do to protect their online privacy and not be tracked by these not-so-delicious cookies. Part Two focuses on the site owners who use tracking products to serve up those cookies to their users.

A Necessary Evil (Cookie)?

Many site owners use web analytics products to assess the effectiveness of an online service or site. These products can measure not only site visits but also how visitors get to the site, including search terms in popular search engines. Other products can track and visualize the “flow” or “path” through the site: where users enter the site (landing page), how users navigate between pages on the site, and what page users end their site visit (exit page).

Web analytics products provide site metrics that can help assess the current site and determine the next steps in investigating potential site issues, such as developing usability testing for a particular area of the site where the visitor flow seems to drop off dramatically. Yet, products such as Google Analytics collect personal information by default, creating user profiles that are accessible to you, the company, and whoever the company decides to share the data. Libraries try to limit data collection in other systems such as the ILS to prevent such a setup, so it shouldn’t be any different for web analytics products.

Protecting Site User Privacy

There are a few ways libraries can protect patron privacy while collecting site data. Most libraries can do at least one or two of these strategies, while other strategies might require negotiation with vendors or external IT departments.

User consent and opt-out

Many sites nowadays have banners and popups notifying visitors that the site uses cookies. You can thank the EU for all of these popups, including the ePrivacy Directive (the initial law that prompted all those popups) and GDPR. US libraries such as Santa Cruz Public Library and Stanford University Libraries [1] have either adopted the popup or otherwise provided information to opt-out of being tracked while on their site. The major drawback to this approach, as one study points out, is that these popups and pages can be meaningless to users, or even confuse them. If you decide to go this route, user notification needs to be clear and concise and user consent needs to be explicit.

Use a product other than Google Analytics

Chances are, your server is already keeping track of site visits. Install AWStats and you’ll find site visit counts, IP addresses, dates and times of visits, search engine keyword results, and more just from your server logs.

(Which, BTW, do you know what logs are kept by your server and what data they are collecting?)

Several web analytics products provide site data without compromising user privacy by default. One of the more popular products is Matomo, formerly Piwik, which is used by several libraries. Cornell University Library wrote about their decision to move to Piwik and the installation process, and other libraries are already running Matomo or are starting to make the migration. You can find more information about privacy-focused analytics products in the Action Handbook from the National Forum of Web Privacy and Web Analytics. Many of these products allow you to control what data is being collected, as well as allow you to install and host the product on a local server.

If you must use Google Analytics

There are times where you can’t avoid GA. Your vendor or organization might use GA by default. You might not have the resources to use another analytics product. While this is not the optimal setup, there are a couple of ways to protect user privacy, including telling GA to anonymize IP addresses and turning off data sharing options. Again, you can find a list of recommended actions in the Action Handbook. You might also want to read Eric Hellman’s posts about GA and privacy in libraries, as well as how library catalogs leak searches to Amazon via cookies.

Protecting patron privacy while they use your library’s online services doesn’t necessarily mean prohibiting any data collection, or cookies for that matter. Controlling what data is collected by the web analytics product and giving your patrons meaningful information about your site’s cookie use are two ways in which you can protect patron privacy and still have data for assessing online services.

[1] Hat tip to Shana McDanold for the Stanford link!

Cookies, Tracking, and You: Part 1

Welcome to this week’s Tip of the Hat!

LDH would like to let our readers know that in the eternal feud between Team Cookie and Team Brownie, we are firmly on Team Brookie.
A pan of brookies cut into bars, with two bars missing. One bar sits on top of the other bars.
But that doesn’t mean we don’t appreciate a good cookie!
A plate of honey nut cookies.
Unfortunately, not all cookies are as tasty as the ones above, and some we actively want to avoid if we want to keep what we do online private. One such cookie is the web cookie.

Web Cookie 101

You probably encountered the terms browser cookie, HTTP cookie, and web cookie when you read articles about cookies and tracking, and they all refer to the same thing. A web cookie is data sent from a website and stored in the user browser, such as Edge, Chrome, or Firefox. Web cookies come in many different flavors including cookies that keep you signed into a website, remember your site preferences, and what you put in your shopping cart when you were doing some online shopping at 2 am. Some cookies only last until you close your browser (session cookies) and some will stick around after you close and reopen your browser (persistent cookies). A website can have cookies from the site owner (first-party cookies) and cookies from other sites (third-party cookies). Yep, you read that right – the site that you’re visiting may have other sites tracking you, even if you don’t visit those other sites.

However, you don’t need a third-party cookie for a site to track you. Chances are that you’ve been tracked when you are browsing the Web by web analytics products such as Google Analytics. What does that all entail, and how does it affect your privacy online?

Tracking Cookies and Privacy

Many web analytics products use cookies to collect data from site visitors. Google Analytics, for example, collects user IP addresses, user device information (such as browser and OS), network information, geolocation, if the user is a returning or new site visitor, and user behavior on the site itself. A site owner can build a user profile of your activity on their website based on this information alone, but Google Analytics doesn’t stop there. Google Analytics also generates demographic reports for site owners. Where do they get this demographic data from? Cookies, for the most part. This is a feature that site owners have to turn, but the option is there if the owner wants to build a more complete user profile.

(Let’s not think about how many libraries might have this feature turned on, lest you want to stress-eat a batch of cookies in one sitting.)

This is one example of how cookies can compromise user privacy. There are other examples out there, including social media sites and advertising companies using cookies to collect user information. Facebook is notorious for tracking users on other sites and even tracking users who do not have a Facebook account. If there’s a way to track and collect user data, there’s a web site that’s doing it.

Using Protection While Browsing The Web

Web users have several options in blocking tracking cookies. The following guides and resources can help you set up a more private online browsing experience:

You can also test out your current browser setup with Panopticlick from the EFF to find out if your browser tracker blocker settings are set up correctly.

Stay Tuned…

But why do users have to do all the work? Where do site owners come into protecting their users’ privacy? Next week, we’ll switch to the site owners’ side and talk about cookies: what can you do to collect data responsibly, regulations around web cookies, and resources and examples from the library world. For now, go get a real-world cookie while you wait!

Silent Librarian and Tracking Report Cards

Welcome to this week’s Tip of the Hat! We at LDH survived the full moon on the Friday the 13th, though our Executive Assistant failed to bring donuts into the office to ward off bad luck. Unfortunately, several universities need more than luck against a widespread cyberattack that has a connection to libraries.

This attack, called Cobalt Dickens or Silent Librarian, relies on phishing to gain access to university systems. The potential victims receive a spoofed email from the library stating that their library account is expired, followed by instructions to click on a link to reactivate the account by entering their account information on a spoofed library website. With this attack happening at the beginning of many universities’ semesters, incoming students and faculty might click through without giving a second thought to the email.

We are used to having banking and other commercial sites be the subject of spoofing by attackers to obtain user credentials. Nonetheless, Silent Librarian reminds us that libraries are not exempt from being spoofed. Silent Librarian is also a good prompt to review incident response policies and procedures surrounding patron data leaks or breaches with your staff. Periodic reviews will help ensure that policies and procedures reflect the changing threats and risks with the changing technology environment. Reviews can also be a good time to review incident response materials and training for library staff, as well as reviewing cybersecurity basics. If a patron calls into the library about an email regarding their expired account, a trained staff member has a better chance in preventing that patron falling for the phishing email which then better protects library systems from being accessed by attackers.

We move from phishing to tracking with the release of a new public tool to assess privacy on library websites. The library directory on Marshall Breeding’s Library Technology Guides site is a valuable resource, listing thousands of libraries in the world. Each listing has basic library information, including information about the types of systems used by the library, including specific products such as the integrated library system, digital repository, and discovery layer. Each listing now includes a Privacy and Security Report Card that grades the main library website on the following factors:

  • HTTPS use
  • Redirection to an encrypted version of the web page
  • Use of Google Analytics, including if the site is instructing GA to anonymize data from the site
  • Use of Google Tag Manager, DoubleClick, and other trackers from Google
  • Use of Facebook trackers
  • Use of other third-party services and trackers, such as Crazy Egg and NewRelic

You can check what your library’s card looks like by clicking on the Privacy and Security Report button on the individual library page listing. In addition to individual statistics, you can view the aggregated statistics at https://bit.ly/ltg-https-report. The majority of public library websites are HTTPS, which is good news! The number of public libraries using Google Analytics to collect non-anonymized data, however, is not so good news. If you are one of those libraries, here are a couple of resources to help you get started in addressing this potential privacy risk for your patrons: