Welcome to the library-privacy-pledge wiki!

Q: What is HTTPS and what do we need to implement it?

A: When you use the web, your browser software communicates with a server computer through the internet. The messages back and forth pass through a series of computers (network nodes) that work together to pass messages. Depending on where you and the server are, there might be 5 computers in that chain, or there might be 50, each possibly owned by a different service provider. When a website uses HTTP, the content of these messages is open to inspection by each intermediate computer- like a postcard sent through the postal system, as well as by any other computer that shares a network those computers. If you’re connecting to the internet over wifi in a coffee shop, everyone else in the coffee shop can see the messages, too.

When a website uses HTTPS, the messages between your browser software and the server are encrypted so that none of the intermediate network nodes can see the content of the messages. It’s like sending sealed envelopes through the postal system.

Your web site and other library services may be sending sensitive patron data across the internet: often bar codes and passwords, but sometimes also catalog searches, patron names, contact information, and reading records. This kind of data ought to be inside a sealed envelope, not exposed on a postcard.

Most web server software supports HTTPS, but to implement it, you’ll need to get a certificate signed by a recognized authority. The certificate is used to verify that you are who you say you are. Certificates have added cost to HTTPS, but the Electronic Frontier Foundation is implementing a automated certificate authority that will give out certificates at no charge. To find out more, go to Let’s Encrypt.

Q: Why the focus on HTTPS?

A: We think this issue should not be controversial and is relatively easy to explain. Libraries understand that circulation information can’t be sent to patron on postcards. Publishers don’t want their content scooped up by unauthorized entities, and they want to be highly ranked by search engines. Service providers don’t want to betray the trust of their customers.

Q. Is HTTPS really immune to eavesdropping?

A: While HTTPS, when properly implemented, is a strong protection against eavesdropping and malicious content insertion during data transmission, there are other ways that attacks can occur. Privacy and security improvements will be an ongoing process. But HTTP has no protections at all against eavesdropping, so HTTPS is a vast improvement.

Q. Isn’t HTTPS more about security than it is about privacy?

A: Implementing HTTPS doesn’t result in privacy by itself. If libraries, publishers and vendors collect and share personal data about library patrons, it won’t make any difference if they use HTTPS. But if they don’t use HTTPS, the data will get collected and shared by third parties no matter what they do. That’s why converting to HTTPS is just a first step towards improving privacy in libraries.

Q. How can my library/organization/company add our names to the list of signatories?

A: Email us at pledge@libraryfreedomproject.org. Please give us contact info so we can verify your participation.

Q. Is this the same as HTTPS Everywhere?

A: No, that’s a browser plug-in which enforces use of HTTPS.

Q: My Library won’t be able to meet the 6-month implementation deadline. Can we add our name to the list once we’ve completed implementation?

A: Of course! If there’s a date you’re willing to commit to, let us know.

Q: We’re not sure if we have the technical expertise to implement HTTPS on our own. Can the Library Freedom Project help us?

A: We’ve had a number of people with technical skills ask us how they can help libraries improve privacy. Send us an email at pledge@libraryfreedomproject.org and we’ll try to connect you.

Q: A local school uses an internet filter that blocks https websites to meet legal requirements. Can we sign the pledge and continue to serve them?

A: Most of the filtering solutions include options that will whitelist important services. Work with the school in question to implement a work-around.

Q: What else can I read about libraries using HTTPS?

A: The Electronic Frontier Foundation has published What Every Librarian Needs to Know About HTTPS.

Q: How do I know if I have implemented HTTPS correctly?

A: The developers behind the “Let’s Encrypt” initiative are ensuring that best practices are used in setting up the HTTPS configuration. If you are deploying HTTPS on your own, we encourage you to use the Qualys SSL Labs SSL Server Test service to review the performance of your implementation. You should strive for at least a “B” rating with no major security vulnerabilities identified in the scan.

Q: Our library subscribes to over 200 databases only a fraction of them currently delivered via https. We might be able to say we will not sign new contracts but the renewal requirement could be difficult for an academic library like ours. Can we sign the pledge?

A: No one is going to penalize libraries that aren’t able to fully implement their pledge. As an alternative, it might be a good idea to clearly label for users the small number of insecure library resources that remain after 2016 as being subject to surveillance.

Q: Our company provides a number of different services. Some of them will not be converted to HTTPS by 2016. Can we sign the pledge on behalf of our converted services?

A: The pledge is meant to support services that implement HTTPS, not to penalize companies that offer non-HTTPS services. Please sign the pledge at whatever granularity you feel is appropriate.

Q: What does it mean to “require” HTTPS?

A: If you have been using HTTP, links to your website will start with “http://”. We don’t want these links to break! Your server should redirect these links to the corresponding https://… link. Although will still be some leakage of user data when they use the http link, content and subsequent links will run over https. If you want to plug this leakage, too, consider implementing HSTS, HTTP Strict Transport Security. Facebook has written an informative article about their transition to HTTPS which discusses many of these issues.

Q: I/We can contribute to the effort in a way that isn’t covered well by the pledges. Can I add another pledge?

A: We want to keep this simple, but we welcome your support. Email us with your individualized statement, and we may include it on our website when signatories are announced.

Q: Our library supports the general direction of the Pledge, but for uninteresting reasons we can’t sign or endorse it. Will we be somehow labelled a “bad” library?

A: Everyone should recognize that many libraries may not be able to raise their voices in this way. We hope that they are able to benefit nonetheless.

Q: Our library runs EZProxy, a re-writing proxy server, to handle remote use of library resources. Are there special considerations we should know about?

A: It’s very important that you at least force HTTPS for the EZProxy login. You can do this with a Let’s Encrypt certificate. But to work for very large numbers of secure resources, EZProxy needs a “wildcard” certificate, which is NOT supported by Let’s Encrypt. You’ll find it easy to purchase a wildcard certificate and install it using these instructions. EZProxy will then use HTTPS “end-to-end” for HTTPS resource. It will not use HTTPS for insecure resources, which is the correct behavior. EZProxy logs can contain privacy-implicating data, and should be handled accordingly.

Q: Our company uses https in all places where PII(Personally Identifiable Information) is being transmitted. Would we be eligible to participate in the pledge?

A: All services should be accessible securely (via HTTPS), not just just those transmitting PII, like logins. Otherwise a user’s search terms are exposed and cookies can be stolen by anyone with access to the network, (wifi in a coffee shop, for example). If your company has implemented HTTPS for logins, it obviously has certificates in place, and clearly it’s moving in the right direction. It’s easy to make mistakes in a partial implementation. We hope your company, having made a good start, will show its commitment to finishing the job of securing its service.

Q: I’ve heard that HTTPS causes a slowdown in web page delivery. Is that true?

A: There’s a good discussion of HTTP vs. HTTPS performance on Stack Overflow. TL;DR: If you serve a lot of small static pieces of content, performance of HTTPS will be significantly slower than HTTP. If you serve large, dynamic resources, the difference is probably negligible. But since HTTPS blocks content surveillance, HTTPS won’t be delayed by relay nodes that are trying to see what’s going through.

Q: How can I tell if HTTPS is implemented properly?

A: First, try out a site with a URL starting with "https://". If you’re using Chrome, there will be a green lock icon next the the URL. Other colors may indicate a problem. In Safari or Firefox, look for a gray lock icon. If you also want to check for the best security, you can use the SSL Server Test, which gives letter grades for any website. Unfortunately there are more often library and academic sites in the right column (recent worst) than in the middle (recent best).

Q: One of our vendors has a "legacy" publishing system and can’t commit to a date for switching to HTTPS. Can we still sign the pledge?

A: We’re asking for a "best effort" to meet deadlines. Everyone should understand that unexpected delays will occur in any complex development project. If you’re convinced that the vendor is making a good-faith best effort to make the switch, then don’t let working with that vendor stop you from signing the pledge.

Q: Our company has been making acquisitions. If a newly acquired product doesn’t use HTTPS, how does the pledge apply?

A: Add the new product to your pledge as soon as possible, but not sooner! None of us can or should make promises about future hypotheticals.

Q: Is the Pledge still accepting new endorsements?

A: Yes! In July 2016, we changed the text of the pledge so the calendar makes sense for new pledgers.