LET’S ENCRYPT

An initiative of note in trying to make the process of implementing https easier, faster, and cheaper is the Let’s En crypt initiative, of which ALA is one of many high-profile sponsors (letsencrypt.org). Let’s Encrypt, provided by the Internet Security Research Group (ISRG), is “a free, automated, and open certificate authority (CA), run for the public’s benefit.” [On March 9, 2016, Josh Aas, ISRG executive director, announced that the Let’s Encrypt client will soon be renamed (the new name is not yet determined) and housed at the Electronic Frontier Foundation (eff.org). —Ed.]

Here are the key principles behind Let’s Encrypt, according to its About page:

• Free: Anyone who owns a domain name can use Let’s Encrypt to obtain a trusted certificate at zero cost.
• Automatic: Software running on a web server can interact with Let’s Encrypt to easily obtain a certificate, securely configure it for use, and automatically take care of renewal.
• Secure: Let’s Encrypt serves as a platform for advancing TLS (Transfer Layer Security) best practices, both on the CA side and by helping site operators properly secure their servers.
• Transparent: All certificates issued or revoked will be publicly recorded and available for anyone to inspect.
• Open: The automatic issuance and renewal protocol will be published as an open standard that others can adopt.
• Cooperative: Let’s Encrypt is a joint effort designed to benefit the community beyond the control of any one organization.

The idea here is to address all of the pain points that have been associated with implementing https on the server side to make encryption more accessible for everyone. Let’s assume you’re sold on encryption and are ready to transform your site from http to https. What should you keep in mind? The following is an oversimplification but, in general, you follow these steps:

• Secure a certificate.
• Install certificate.
• Change any links that are http to https.
• Redirect from your http address to your https address to let search engines find you.

Two potential flies in the ointment: If you haven’t been using relative links on your site (/libraries/hillman/index.html versus http://www.library.pitt.edu/libraries/hillman.html), then you’re in for a lot of manual cleanup, as those http links will no longer work. Using relative links is a standard good practice, though, so I’m sure we’re all in fine shape. The second thing to keep in mind is to be sure to open your https site to crawling in your robots.txt file. You can test your configuration at https://www.ssllabs.com/ssltest.

Accelerated Mobile Pages (AMP)

We’re living in a mobile world; we all know that. Mobile presents webmasters with limited bandwidth, limited data, and network latency. Given these constraints, it’s ironic that webpages are actually getting increasingly heavy (httparchive.org/trends.php). Responsive design, by definition, solves one problem—effectively displaying content across a variety of form factors, making pages at least partially “mobile-friendly.” How ever, responsive does not necessarily mean that these pages are lightweight and performance-friendly. It’s easy enough to design responsive pages that achieve responsiveness by simply hiding full-scale elements. Although you might not see the full size image or the side navigation, it’s still being loaded in the background.

All the major web players have recognized the negative impact these performance issues have on user experience. AMP (Accelerated Mobile Pages) is an initiative from Google that seeks to address some of these (github.com/ampproject/amphtml). Before we applaud Google for coming to the rescue, a few things need to be noted. First, although irrelevant to library websites, a cause of significant slowdowns on the open web are ad network infrastructures, largely JavaScript-based. These infrastructures gum up the works, which is of course Google’s bread and butter. Second, although open source, AMP is as much a business proposition as it is a user experience proposition. The business side to the equation is a response to Facebook Instant Articles and Apple News, both of which achieve similar ends, but which are walled gardens and therefore a threat to Google’s bottom line.

In AMP, certain HTML tags are not allowed; you can only use a very streamlined version of CSS, and the only Java-Script allowed is the JavaScript library that comes with AMP, which utilizes lazy loading, that is, deferring putting elements into play until they’re actually needed, instead of doing it all up front.

What does this mean for you? Because of the restrictions inherent in AMP, it’s really tailored for static textual content. Library websites tend to have a decent amount of this. As of right now there are Drupal AMP modules in development and active Word Press ones, so AMP proper is achievable now. The other takeaway, however, is, that special projects like this aside, webmasters need to focus on performance as an aspect of user experience, in addition to those things we usually associate with UX.

You’ve probably been busy working directly with users to make their online experiences the best they can be, which is as it should be. For most of us, this is the fun part of being a webmaster. Remember, though, the interface is but one piece of the whole experience puzzle. Whether we’re optimizing our servers for security, ensuring uninterrupted access to library content, or trying to create lightweight and speedy pages, all of this activity serves in the end to help make for better experiences for our users.