Background

In late 2017 we completed the formidable task of migrating our web platforms to HTTPS. This update was prompted by a change in the Google Chrome browser that began to identify any HTTP webpages where users can type information as "Not Secure."  This meant that our Library Catalog, homepage, and many of our search widgets would have triggered a "Not Secure" warning for users accessing our website via Chrome (over half our total website visitors!).

To make these pages secure within Google Chrome (and other browsers that would follow Google's lead), we updated our web platforms to support the HTTPS protocol and analyzed and updated our website content to eliminate "mixed content". HTTPS is more secure because it provides encrypted communication between websites and the user's browser.

Benefits of Serving Web Pages over HTTPS

• Authentication - HTTPS provides some level of verification that the website is managed by whom it claims it is.

• Data Integrity - HTTPS websites are more resistant to being tampered with.

• Privacy - HTTPS websites are harder to read by a third party.

What Is Involved with an HTTPS Migration?

There are 2 steps to migrating web platforms to HTTPS:

1. Web platforms must have an SSL (e.g., "security" certificate).
2. Website content must be analyzed to identify "mixed content" and that content must be updated to load via HTTPS.

What is Mixed Content?

Mixed content occurs when a webpage is loaded over HTTPS, but the page contains some content that is loaded over HTTP. Most webpages, except for the most basic ones, contain resources that aren't actually part of the HTML file. Examples of external webpage resources are images, scripts, or iframes. Because webpages that are loaded over HTTPS are intended to be secure, most browsers will actually block the loading of  "risky" HTTP resources (e.g., scripts) into a page that was loaded over HTTPS. That means that whatever functionality that script was intended to provide would be broken on that page.  Many search widgets rely upon scripts to provide their search functionality so it's critical that search widgets are maintained and tested.

Note that images referenced via an HTTP URL, like <img src="http://library.somewhere.edu/images/logo.jpg" alt="Library Logo"> are a useful example of mixed content, because it's easy to understand that they are separate files from the basic HTML of a webpage, but most browsers do not block the loading of HTTP images on HTTPS pages at this time.

Which Types of Mixed Content are Blocked?

Here are the types of webpage resources that we think you are most likely to use in your guides, and which will be blocked by most browsers, if you try to load them as HTTP resources.

• external scripts
• external stylesheets
• iframes
• embedded content (such as widgets, videos, etc.)

Mozilla has detailed information about mixed content

This overview was adapted from Google's What is Mixed Content page.

All LibGuides-generated URLs are good to go!

All LibGuides functionality, that allows you to point and click to insert content, or generates content for you, that doesn't use URLs that will load those resources over HTTPS on HTTPS pages.

There is a bit of nuance here, that you might want to be aware of, if you peek under the hood. Some LibGuides-generated URLs start with HTTPS, and those are, obviously, good to go. LibGuides also uses a special type of URL called a "protocol-neutral" URL. Those URLs start with //, which means that they don't specify either the HTTP or the HTTPS protocol. Web browsers will automatically complete those URLs, by prepending the protocol used by the current web page, so those URLs will use HTTPS on HTTPS pages. Those URLs are also good to go.