 Welcome, and thank you for joining us for today's TechSoup for Libraries webinar. Today's topic is Protecting Patron Privacy in Public Libraries. My name is Crystal and I'll be your host. Patron Privacy is of critical importance to libraries. It's included in the American Library Association's Code of Ethics and the Library Bill of Rights. As technology changes rapidly, libraries and librarians are working hard to keep up with digital security issues to better protect the privacy of their users. But this is not an easy task. Today we have two guests joining us to help us sort out some of these issues and share examples of solutions. We will focus on public access technology and focus on other related areas as well. Before we begin, I have just a few announcements. We will be using the ReadyTalk platform for our meeting today. Please use the chat in the lower left corner to send questions and comments to the presenters. We will be tracking your questions throughout the webinar and will answer them at the designated Q&A section after each presenter. All of your chat comments will only come to the presenters, but if you have comments or ideas to share, we will forward them back out to the entire group. You don't need to raise your hand to ask a question. Simply type it into the chat box. Should you get disconnected during the webinar, you can reconnect using the same link in your confirmation email. You should be hearing the conference audio through your computer speakers, but if your audio connection is unclear, you can dial in using the phone number in your confirmation email or that we've shared here in the chat. If you're having technical issues, please send us a chat message and we will try to assist you. This webinar is being recorded and will be archived on the TechSoup website. If you're called away from the webinar or if you have connection issues, you can watch a full recording of this webinar later. You will receive an archive email within a few days that will include a link to the recording, the PowerPoint slides, and any additional links or resources shared during the session. If you're tweeting this webinar, please use the hashtag TS4LIBS. We have someone from TechSoup live tweeting this event, so please join us in the conversation there. TechSoup Global is dedicated to serving the world's nonprofit organizations and libraries. TechSoup was founded in 1987 with a global network of partners. We connect libraries and nonprofits to technology, resources, and support so that you can operate at your full potential, more effectively deliver your programs and services, and better achieve your missions. TechSoup has helped to distribute over 14 million software and hardware donations to date through our product donation program. We offer a wide range of software, hardware, and services that are both cost-effective and environmentally friendly. For more information about TechSoup product donations or services, please visit TechSoup.org and click on Get Products and Services. For today's webinar, we're joined by two guests. First up, we have Bill Buddington from the Electronic Frontier Foundation, the EFF. Bill will talk about digital security issues that impact patron privacy in public libraries, and will share tools and information from EFF that can be useful for libraries. Then we'll hear from Chuck McAndrew, the IT librarian at the Lebanon Public Libraries in New Hampshire. He will share examples of actions he has taken at this small library to better protect patron privacy and to teach library users how to better protect their own privacy. My name is Crystal Schimpf, and I'll be your host for today's webinar. Assisting us with chat, we have Becky Wiegand, and on Twitter we have Molly Bacon, both joining us from the TechSoup team. We'll have time again for Q&A after each presenter, and we'll be tracking your questions throughout. Please share your questions in the chat as they arise. And lastly, we will be sending out an archive that will have all of the links shared during the session today, so you can expect that in your email within a few days. All right, well, without further ado, I think it's time for me to hand things over to Bill so he can talk to us about digital privacy and security. Bill? Hi there. Thanks for joining me. I'm having some technical difficulties right now actually. So one thing that I couldn't do is, Crystal, if you can advance my slides, and I can pull up a parallel set of slides on my side. Sorry, just one second. Thanks for bearing with us everyone as we sort out this technical difficulty. We'll get started in just a moment. Okay, so thanks so much for joining me in this Digital Privacy and Security Library Edition. Next slide. Who am I, and why should you listen to me? My name is Bill Buddington. I am a security technologist and security engineer at the Electronic Frontier Foundation. I advise lawyers and activists on technical matters as my primary day job. Next slide. What is EFF? EFF is the Electronic Frontier Foundation. We are a member-supported nonprofit, and we've been fighting for 26 years to promote privacy and civil liberties in the digital world. We do this with a three-pronged attack. We have technologists on staff. We have lawyers, and we also have activists. And using these three different teams at EFF, we have that mission of supporting your civil liberties in the digital world. So next slide. What is privacy and security, and why is it important for librarians? Well, I'd like to start with this quote from Robert G. Vosper, who was the head of the American Library Association. The library is an open sanctuary. It is devoted to individual intellectual inquiry and contemplation. Its function is to provide free access to ideas and information. It is a hidden for privacy source of both cultural and intellectual assessments for the individual reader. And so I think that this really kind of drives home the point of why privacy is important for librarians. And I think most librarians actually understand this. It's not a controversial idea. It's something that is expected as a librarian when you're going into a profession. Next slide. Also, libraries are really seen as these sanctuaries. Whether it's actually true or not, most people go into libraries and they kind of feel this solace. They actually feel like they are being protected in some degree from the outside world. And they can kind of pursue their intellectual freedom and desires in a way that's protected, in a way that's free. And so, yeah, libraries are kind of seen as these sanctuaries. To bring it to the current day, they are seen as sanctuaries, especially for at-risk communities. Next slide. But why security? Why is security important as well? Next slide. Well, to answer that question, we need to take a detour through the Internet. Next slide. Yes, the Internet. Next slide. So when most people think about the Internet, they think of an email and they send an email. And so we have these two figures, Alice and Bob. And Alice wants to send an email to Bob. Next slide. And it looks like from Alice's perspective that that email is going directly to the inbox of Bob. Next slide. But in actuality, there are a number of intermediaries between the connection of Alice and Bob, primarily the email service providers and the Internet service providers. Next slide. And also, three-letter agencies such as ENSA that has control or has special hardware that they can install on backbone and privilege network nodes. Next slide. So in addition, you also have eavesdroppers which can possibly be snooping on the connection either in the home or cafe that Alice is connecting from, or in Bob's home or cafe or wherever they are connecting from. Next slide. With the help of next slide encryption, we can actually make this connection much more secure and that people can actually be insured that the communications that they are sending are not interceptable and not readable. Next slide. What is encryption? Well, encryption scrambles the message content so that it's not readable from anyone that's sitting on the network in the middle of Alice and Bob. It also to note still has metadata. That's everything that isn't the direct contents of that message. So next slide. What is metadata? Next slide. In this example, metadata is the time that that email is sent, the subject line, the time received, the name of the sender, the name of the recipient. All that data is still accessible even if encryption is used. Next slide. So for HTTBS, HTTBS is basically web encryption. And the contents for HTTBS, what's actually encrypted is what exact page you're accessing. For instance, if you are accessing example.com slash sumpath, the sumpath part of that URL of that website, that's the encrypted part. The username and password, if you're logging into a site, that's also encrypted if you're using HTTBS. And also if you're logging into a session, say facebook.com, if you are posting content, that's also encrypted. What's not encrypted is the metadata. What domain you're on, for instance, if you're on bing.com, that's not encrypted. That can be seen. What time you accessed it, and your location data, for instance, your IP address. So your IP address is this unique identifier that's linked to your location. So you can see here by this graph, in the first instance, next slide, what is encrypted, and what's plainly visible from HTTBS and non-HTPS connections. Next slide. Here you can see that there's this green lock, and that indicates that you're actually using an HTTPS connection. And that way you can be ensured that your connection on the web is encrypted. Next slide. We develop at EFF a product called HTTPS everywhere. And what this does is it ensures that if a website offers HTTPS and an unencrypted connection that you're actually using the encrypted connection to that website, you're actually using the best security for that website that is available. Next slide. This is a downloadable browser extension that's available for both Firefox and Chrome. And you can install it on both your own computer and also the patrons' computers that are public stations at your library. Next slide. So why is security important for librarians? This article by the American Libraries Magazine kind of drives home why it's important, and also some of the failures of libraries to actually deploy good HTTPS. Next slide. Their findings are that without encryption, the content that patrons search for, view, or download is easily intercepted. These online streams of communication deserve the same protections granted to circulation records, but few libraries are taking even minimal steps to encrypt this data. So you can see that this is something that encryption, HTTPS specifically, is something that really is important for, and should be granted the same kind of level as circulation records. Next slide. Their findings continue that out of the top 124 American Research Libraries, only 13% of them are actually using HTTPS. Next bullet point. And out of the 25 largest public libraries that they surveyed, only 2 of them, 8%, were using HTTPS on their main websites, and only 28% defaulted HTTPS for search activity. Next slide. So they conclude that we could better attribute this gap in deploying HTTPS to an awareness or lack of expertise in reconfiguring implementations, which basically means that there's not enough staff, and there's not enough people with a skill level to really make it viable for these libraries to deploy HTTPS. Next slide. This is really troubling. Next slide. So why is it troubling? Who cares if HTTPS is on sites? Next slide. Well, we know that the NSA is compromising cloud services. This slide was revealed in the Snowden revelations, and what it shows is that the NSA is actually intercepting the background communications of Google and trying to site it off data of users of Google services. Next slide. We know that the NSA is undermining encryption. They have, for instance, paid $10 million to RSA to essentially privilege a weakened encryption that was called a cipher, which is a way that encryption is performed, and privilege that in the Cypher Suite that NSA, sorry, the RSA provides. Next slide. So we know that the FBI has amended patron records as well. This is a case where in Connecticut, the libraries were, their service providers were basically issued national security letters. The ACLU challenged that, and that's why we're able to talk about it, because national security letters under the Patriot Act are accompanied by gag orders, so you can't even talk about them unless you are combating and winning those cases. So this is something that's really troubling that patron records are actually being requested by the governments, by the FBI in this case. Next slide, and they're being requested over. Next slide, and over again, these two cases were brought against the FBI-demanded records of the Internet Archive, which is the online digital archive. And what they were doing was they were saying in 2007, we want your records. EFF challenged that, and we were able to talk about it in 2007. The latest case in 2016, just last year, the NSL was accompanied by information that instructed how to challenge the NSL, but that was faulty information. They were giving out information how to challenge the NSL that was actually erroneous and misleading, and so we challenged that and kept them to stop that as well. Next slide, so why aren't more libraries' websites offering HTTPS? Well, traditionally, obtaining a certificate which you need to provide HTTPS is pretty hard, and installing that HTTPS certificate once you get it is also really hard. Next slide, so HTTPS certificates also cost money. They have traditionally not been free, and there's no reason why security shouldn't be anything but free. For certificate authorities which issue HTTPS certificates, these are automated systems that cost pennies to issue a single certificate, and there's no reason why. They should cost $10 a pop for every website that you want to encrypt. Next slide, well, introducing CERTBOT. Next slide, CERTBOT is a project of the Electronic Frontier Foundation in collaboration with other organizations, and what it does is it's bullet point automatically issues HTTPS certificates, bullet point and configures your software to use them, so it's not actually hard to deploy. Bullet point, for free. Next slide, so it's important to note here that HTTPS provides security but does not protect privacy. Next slide, your data is big money. This is a graphic that shows when you access the New York Times where your data is actually being delivered. It doesn't just go to the New York Times. It goes to dozens of other organizations, and that's because when you access the New York Times it's pulling in resources from other organizations, maybe ad networks, maybe fonts that are included in other places that New York Times itself doesn't host. So these are actually all places where your data is being delivered when you access the New York Times website. Next slide, and that's delivered to bullet point. Advertisers to market your products at you. For instance, there have been notable instances of differential pricing. If you live closer to a Walmart, for instance, then a website that's trying to sell you things that are also available at that Walmart will have a lower price than if you live very far from a Walmart. And there's also these diploma mills which market typically at low income people to attend universities that grant diplomas that aren't really worth the paper they're printed on. So bullet point, web trackers also do big data analysis on you. And they do that without your consent. No one actually is displayed a warning that's saying, hey look, your data is going to X, Y, and Z places. There are regulations in the European Union, but not here. There's not any federal data protection regime in the US. Next bullet point, sorry, next slide. So there was this August 2016 study of web trackers, next slide, and they found that bullet point at least 75% of the top 500 internet sites contain trackers. And this is us from bullet point, less than 5% in 1998. So we've seen a real, real increase in the amount of sites that are actually performing web tracking that are siphoning off your data as you browse the web. Next slide. The findings continue that the number of trackers have increased, as well as the ability of the trackers to actually employ technologies that track you, and the complexity of those trackers. This is all kind of increased, and this is a really troubling dynamic. Next slide. So enter Privacy Badger. Next slide. Privacy Badger is an extension that's developed at EFF. It's also like HTTPS everywhere, a downloadable browser extension that's available for Firefox and Chrome browser. And what it does, next slide, is bullet point. It tells sites that you do not wish to be tracked. Bullet point, it looks for third parties as you browse the web, and bullet point, if a third party is seen on several different domains, bullet point, and it appears to be tracking you, bullet point, then it gets blocked. So it looks for these different tracking mechanisms that trackers use, and it tries to determine if it's a tracker or not that's doing it, and it blocks them if it is. Next slide. This is Privacy Badger in action. You can see that some websites are blocked because they look like trackers and other websites are allowed. Next slide. So what this all really comes down to is a question of user education. Unfortunately, users aren't really aware of what is happening with their data. Bullet point, generally users don't really know the risks to their privacy and security when they browse the web, when they access the Internet. Bullet point, there are often vested interests that are actively trying to subvert knowledge about how users can protect themselves. I mean, in the case of HTTPS, it might be a government, but in the case of browsing with Privacy, then it's these trackers or ad agencies. Bullet point, and there's this difficult task of actually raising awareness and letting users know that their privacy is at risk. So what librarians can do is they can kind of let their patrons know about these risks, perhaps the home page for their public computers can be something that includes text about how their privacy is being affected. Next slide. And one of our resources at EFF is ssd.ef.org, which is the last resource here. And that explains a lot more info about how users can protect themselves and how you can help your patrons know and yourself get informed about these risks. And I also have the resources here for additional information in the presentation. Thanks very much. Great. Thanks, Bill. And thanks for bearing with us with those technical difficulties. I think we got through everything okay, so thanks for working with me on that. We've got some great questions that have come in. And before we get to those, I just want to say thanks for sharing all of this. I mean, this is an information-rich presentation that you've just given with lots of links and lots of resources. And I just want to remind everyone who's joined us that we are going to be sharing those links in the archive. And I know there were lots of articles that were referenced, and those will also be included so you can go and follow up with those later on. We did get one question about sharing the name of that study. And I think I know which one this is, and I'm just going to go back to it. Well, and actually I'll see if I can find it in a moment. We'll go back to that one that had this study. But Bill, we've been getting some good questions from participants. And so I'm going to go through as many as we can in the few minutes we have before Chuck's presentation. And one of those questions is, does Certbot rely on the Let's Encrypt certificates? And could you talk a little bit more about that? Right. So Certbot is what's called the client side of the dynamic duo of Let's Encrypt and Certbot. So the Let's Encrypt is what's called the server side. So Let's Encrypt acts as the issuing body. Let's Encrypt software runs on not your own computer that you want to get a certificate for a website that you own, but it runs as the issuer on the Internet so that you request certificates from it. So Let's Encrypt is basically, yeah, Let's Encrypt works with Certbot to issue certificates. And they're kind of part and parcel of the same overall thing. Great. And another related question, and I think that you answered this. It came in early on, but I want to make sure we get this really clear. Is there a cost to going to HTTPS versus HTTP? And I think you shared an option with us that was either free or very low cost. Right. So with Certbot, if you download Certbot and the link I have at the end of my presentation has where you can actually download a Certbot software, that's absolutely free. There's no cost for HTTPS deployment other than the cost that it takes to have assistant men run this software. And traditionally, that's been a very high bar. The assistant men that wanted to deploy certificates, it took them, and it took actually security researchers and experts hours often to get it right. And what Certbot does is it takes on a very hands-on approach and deploys the certificates for you. So you don't have to worry about all the configuration options. Great. Now we have a question about HTTPS everywhere. What browsers does that work for? And I'm just going to go back to the slide where we talked about that. Sure. So HTTPS everywhere is what I do at EFF. It's my primary job at EFF is to maintain that browser extension. Currently it is supported in Firefox and in Chrome browser, also in Chromium if you use Chromium which is the free version or free software version of Chrome browser, and also in Opera browser if you use that. Great. And then I guess I'm just trying to go through a couple of quick questions here. We've got some big questions which we'll try to save for later on once we've heard from Chuck as well. But a question about Privacy Badger. Is Privacy Badger free? Yes. All the tools to protect your users that I've listened to this presentation are absolutely free. So Certbot is free and so is HTTPS everywhere and Privacy Badger. Great. Thanks for clarifying that. I know we kind of went through each one individually as those questions came in. And then we've got a question about the difference between the browser option to deny tracking and Privacy Badger. So maybe you could talk a little bit about that and this might be our last question before we move on. Sure. So what browsers are they doing early, I believe it's either early this decade or last decade, is they started delivering this little flag to websites that you access. That says that you do not wish to be tracked. And that's something that is great but it also isn't really enforceable. We send it with Privacy Badger. We actually set that flag to say, hey, Browser, you should send this to websites that I'm accessing that I do not consent to being tracked. But it's not an enforceable mechanism. That's called Do Not Track. The Do Not Track flag. There's also Do Not Track policy that is different that we at EFF have formulated. And that is something that says that if websites say that they are not going to track users, promise not to track users, and post a privacy policy that actually puts in writing that effect that they're not going to track those users, then with Privacy Badger we will selectively unblock those sites that have that privacy policy that promise not to track users. So it's a little tricky, but so there's the Do Not Track policy and the Do Not Track flag. Great. Well thanks for clarifying the difference between those. I'm just going to get back to this slide one last time to let everybody know that I know we had some other questions come in and we haven't had a chance to get to all of them. We'll try to bring Bill back at the end to answer a few more of your questions. And we will follow up via email with anything that we weren't able to answer live today, so don't be discouraged if you ask a question. We haven't gotten to it yet. We'll have other opportunities to do that. But we have another guest and we want to hear from him as well. So at this point I want to welcome Chuck again joining us from the Lebanon Public Libraries in New Hampshire. And Chuck is going to talk to us about what he has done in his library. So Chuck, I'll hand it over to you now and let me know if you need me to advance your slides. I understand you're having the same technical issue. Thanks, Crystal. So my name is Chuck McAndrew. I'm the IT Librarian at the Lebanon Public Libraries in Lebanon, New Hampshire. And Bill gave you a really good overview of the higher level stuff, the way that traffic goes over the Internet. And so what I wanted to do today is give some practical tips, something you can take home and implement in your library right now or today. And it's stuff that we've done in our library and we found worked well. But before I do that, I just wanted to add a plug for Certbot. That's what we use in our library. It is very good. And not only that, I've also pushed our ILS vendor to implement it. And they recently announced they're putting it in place for all their customers. So all their customers now will have HTTPS by default because of Certbot. It's very easy to use. So go ahead and next slide please, Crystal. So I am from the Lebanon Public Libraries. We're about halfway up the state of New Hampshire right on the Vermont border. We're kind of in the middle of nowhere. We think we're a big library for the area. We have about 14,000 people which is big for the area, but I know nationally that's not too huge. But we do a lot for privacy, patron privacy in our library. And if we can do it, so can you. Next slide please. So the first thing I want to talk about is Wi-Fi because a lot of times you see open Wi-Fi in libraries and that's fine. But there are some things you should be aware of when you have open Wi-Fi. So open Wi-Fi is the best for convenience. People can just walk in and click on the Wi-Fi and don't need to worry about a password or anything. And it actually promotes access in that when the library is closed or someone doesn't even want to come through the doors of the library, they can use that Wi-Fi. But it's unencrypted. So the connection between the computer and the wireless access point is not encrypted which potentially allows for snooping and man-in-the-middle attacks. And a man-in-the-middle attack is where someone else pretends to be the website that you're trying to connect to. Now if you have an end-to-end encryption system in place like HTTPS, this is not a huge deal. But if you're connecting to an unencrypted connection then basically anyone on that network can see everything you do. So essentially what we're doing by having open Wi-Fi is replacing the responsibility for security on the patron rather than on the library. Most of our patrons in our library are not extremely tech-savvy. So the more we can do to help them out with privacy and the more we can do to build secure private systems that they can use, the better we're doing as librarians. Next slide please. So an alternative is to have secured Wi-Fi. This is Wi-Fi with a password. The pros is it's an encrypted connection. It is the best for privacy and security. It can limit access though and it's not as convenient. Just as a note, please don't use web encryption. Only use WPA2. Web is broken. You can crack it really quickly with just a normal laptop. Now you can try publicly posting the password. You'll see this a lot of times like in coffee shops and stuff. And that is one way to reduce the convenience concerns here. But it doesn't allow that 24-hour access to your library Wi-Fi and stuff which to me is actually a big service. I know there have been times when I've traveled on road trips and stuff and I've been able to pull into a library's parking lot and use their Wi-Fi even when they're closed. And that was hugely handy. Next slide please. So there's compromises. One is to have both a secured and an open network. And the other compromise is to broadcast a secured network with the password in the name. At our library we do both. This is actually a screenshot from my laptop of our library Wi-Fi networks. So we have library guest which is unsecured. It's open and anyone can use it. And then we have library guest password is LibLibrary. And that is just what it sounds like. It's a guest network with the password right in the name. So anyone looking at that knows what the password is. And then we have library staff because you should never have your library staff using the same network as your library guests which gets more into the infrastructure side of things. But this is a big problem that I see with a lot of libraries. You really want to segregate that out because library staff is dealing with a lot of sensitive patron data that is protected by law in most cases. And so you don't want to have random people able to snoop on your staff network. Next slide please. So those are kind of some of the considerations that go into Wi-Fi selection. You can see we hedged our bets and did all of the above. Now I'm going to talk a little bit about public computers and how we can protect patron's privacy using our public computers. This is not exhaustive I teach an online privacy course at my library. It's two hours sessions and there's five sessions in the course and I consider that kind of just an introduction. So 30 minutes of talking on a webinar is not enough to go into this. So these are just what I would consider very basic things that everyone should be implementing. I'll also note that in the links we've included at the end of this presentation the American Library Association has recently released some checklists of things that libraries should be doing. Take a look at those checklists and run through them for your library. They're very good and they're much more exhausted than this. So public computers keep them up to date. This is the number one thing you can do for security on your computers at home, your patron computers, your staff computers, any computers. Most exploits, most hacks are on vulnerabilities that have already been fixed. Software companies these days are actually pretty good about getting fixes out pretty quickly and a lot of security researchers will notify the software company about a vulnerability before they release it publicly. But the software companies all they can do is release the fix. If you don't update then that's actually on you. You also want to make sure your rollback software doesn't rollback your updates. So if you're using something like Deep Freeze you have to make sure it unfreezes for updates. Otherwise you can install your updates but it's going to roll them back. Automatically installing security updates is a very good thing because it makes sure they get done. You don't have to add it to your schedule. It's not another thing you have to do. There's a little bit of potential for breaking something with automatic updates but most people in libraries who I've seen don't go to the trouble of testing updates before they apply them anyway. So you might as well have them automatically installed. Next slide please. So the next thing, and this is very important for public privacy not in the sense that someone is going to be snooping on them over the Internet but in the sense that the next person who sits down at the computer after them might see something. Restore your computers to a known good state between patrons. I've gone in libraries and seen credit card applications and saved on those computers. You have to wipe out everything the patron does between users. Otherwise it doesn't matter whether you have the most secure connection in the world. The next person who sits down can see everything they did. So if you're using Windows computers having some kind of rollback software such as Deep Freeze, Deep Freeze is just the one I've heard of the most, is really important if you're using something like Chromebooks or Chromeboxes, Chrome OS, this actually comes built into it. You just need a Google domain and you use public sessions. If you're doing something oddball like we do at my library and you're using an open source operating system like Linux then there's actually a script that I wrote that accomplishes this. But regardless of what system you're using, it can be done on all of them. Just make sure that you have a strategy for ensuring that every patient who sits down has a known good situation. This also prevents tampering with the system like installing malicious software such as Keyloggers. There was an article that came out last year about a university library where there were some, I think it was 30 or 40 Keyloggers installed on library computers. So everything that anyone was sitting down and typing into those computers was logged. If you're restoring this system to a known good state and the patrons don't have administrative privileges which is another important point, then anything malicious they try to do should be undone. Next slide please. There's also a lot of tweaks you can make to your browser settings. This example that I have up here is from Google Chrome, but the same all the major browsers allow this. Either have the browser not remember history or open and incognito mode. And what that does is it ensures that nothing is retained between browser sessions. So even if the patron doesn't log out, as long as they close that browser window then it's not going to remember stuff on the browser window. Now that doesn't help if they download something, but it's a good step. And you may say, well I have this rollback software so I don't need to do this. The fact is that none of these are perfect solutions so having a defense in depth where you have multiple layers of security is the way to go. So have it not remember history. Do not have it remember form data. Definitely do not have it remember passwords. And more on the Internet privacy side of things. Set your plugins to click to play. This ensures that plugins like the Flash Player don't just start up and run when you go to a website because those are essentially little programs running inside your web browser. So you want the patron to have control over whether that runs or not. And finally disable third party cookies. All this is done through the settings. The details of it vary by which browser. So just do a quick online search for all of these for whatever your browser of choice is and you can figure out how to do it. Next slide please. So Bill talked about two of the three plugins that we install on all our public computers already, HTTPS everywhere, and Privacy Badger, both very good plugins. And like I say, I put them on all my public computers. And then the third one I install is Ublock Origin. And what Ublock Origin is, it's an ad blocker. Now there's some debate about ad blockers because a lot of sites on the Internet use ad revenue to keep going. And some people feel that there's kind of an implicit contract. You go to the site, you utilize their services and you don't pay anything. You should look at their ads. And I can certainly understand that. I have a lot of sympathy for that. However, the problem is that it's not just that ads are annoying. Ads are frequently malicious. And this is even true or especially true on big well-known websites. These websites do not have the time, money, or staff to really vet every ad. So what they do is they contract it out to third-party advertising companies. And all of the major websites have had cases of malicious advertising showing up on their website. Now malicious advertising means that if you click on that ad, it will do something malicious to your computer. So until they figure out a better way to ensure that their ads are actually safe, I think that it is just common sense that anyone going on the Internet does in fact block ads by default. Now UBlock Origin provides a very easy way to disable it if you do want to see ads on a site or if it's necessary to see ads for the site to work properly, just like Privacy Badger and HTTPS everywhere are very easy to disable. Some of these may interfere with the functionality of some websites. And that's actually okay in my view because often the functionality they are interfering with is not functionality you want. It doesn't benefit your patrons. But there are times when it will prevent the patron from doing what they want. So it's important that your staff know how to disable them. So if a website is not working properly, you can try disabling it. But we want on by default. We want safe by default to ensure that our patrons when they sit down at a library, we can't guarantee they have a completely safe or completely private experience. But what we can do is we can take care of the low hanging fruit. We can take care of the easy stuff. If someone is being tracked by the NSA, probably not much we do on our public computers is going to help them. But we can prevent the script kitties from being able to figure out what they are doing. Next slide please. And the final thing I would say for public computers is install the Tor browser. So if you aren't familiar with Tor, what Tor is, it's a strong anonymity product. And what it does is it encrypts your traffic and it severs the link between the sender and the receiver. So it does this by bouncing it through three voluntarily operated relays. Your computer will connect to what's called a guard relay. And then the guard relay will bounce it to a middle relay. The middle relay has no idea who you are, where the traffic came from. It has no idea where the traffic is going. All it knows is the two other relays it's talking to. The traffic is then sent to what's known as an exit relay which is what goes out and talks to the website. The website sees this traffic as coming from the exit relay rather than from your computer. Tor also will create a new circuit for every separate domain and every separate tab within the browser. So that means if you are on Twitter and on Google in two separate tabs, Twitter may think you are connecting from the Netherlands and Google may think you are connecting from Canada. This prevents cross-site tracking which Bill talked about a little bit earlier which is becoming more and more of an issue. These trackers because so many sites have them, they will follow you across sites which can give them a whole lot of insight into your behavior that you may not want them to have. So the Tor browser is basically a modified version of Firefox that runs everything through the Tor network. Again, this is a screenshot from our public computers at our library. By providing access to the Tor browser you are giving your patrons strong privacy and anonymity. But you are not requiring it. You still offer the other browsers. You are just giving them the option. Now some libraries may have issue with this if they are required to filter their Internet. So one solution that we have kind of come up with when talking to people who are in that situation is you can actually install the Tor browser to a thumb drive. You don't have to install it to the computer. You can put it on a thumb drive and it will run just fine. So you can put the Tor browser on thumb drives and make that available to patrons. That will allow you to still filter your Internet but have the possibility of using the Tor browser for patrons who want it and who aren't subject to filtering like adults. So I would recommend that every library have the Tor browser available to their patrons. It is free. It runs on every major operating system. And it's relatively easy to use. Not only are you offering the technical benefits of the encryption and the anonymity but it's also a great way to raise to start conversations about digital privacy. Once we installed it on our computers and put up signs explaining what it is I've had a lot of patrons come up and start talking to me about these issues. And it's a great way to start an education initiative with patrons. Once they started talking about that, they started asking for classes on how to stay safer online. And that led to our, we call it online self-defense which I shamelessly stole from the EFF with their surveillance self-defense because I thought it was such a cool name. And you can see the link on the slide there, leblibrary.com slash online dash self-defense. That's my entire curriculum. And you can now note the slides and all my notes. So feel free to use it in your library by the way. And there's the ALA Privacy Checklist, the Library Freedom Project. If you don't know about Library Freedom Project, Allison McCrena is awesome and she will come to your area and teach you how to do all this stuff. San Jose Public has an awesome privacy program as well as well as the Electronic Frontier Foundation. So that is all I have today. All right, Chuck, thank you for again a very information-rich presentation. And again just to let everybody know, we are going to share the slides and all of these links in the archive. And you will get that in the email, in your email that you used to register for this webinar. So that will be coming within a few days. Now we've gotten a lot of questions, Chuck. People want to know more details about some of the things you're doing. So I'm going to see how many of these we can get to in the short period of time that we have. And I know Bill's been responding to some of those extra questions in chat so we'll let him keep working on that and if we have time we'll bring him back. But we got some questions just to go back to what you were talking about early on with the Wi-Fi network. We got one question that said, and I think this is a good one, so when you broadcast your password as you showed over the Wi-Fi network, can't you still get man in the middle, MITM attacks? And I'm just going to go back to this slide where you talked about this. That's a good question. And the answer is no, because the password is not the important part. The encryption is the important part. So the secured network basically creates an encrypted connection between the wireless access point and the computer. The password is not the encryption key. So each individual client, each individual computer will have its own one-time use encryption key that secures that session. So every time you connect it basically generates a new encryption key. And that's what prevents the snooping and that's what prevents the man in the middle attack. It's basically the same thing that's going on with HTTPS. Great. And we got another question and I feel like the answer may be similar but correct me if I'm wrong. So on Wi-Fi if everyone shares the same login, can they use that to decrypt all the traffic if we all have the same password? Do we all have the same key? And the answer is no, you don't have the same key. So the password is just essentially to authenticate yourself to the network, but then your computer and the wireless access point negotiate a key. If you want to know more about how the encryption works the Khan Academy has an excellent series on YouTube it's called Gambling with Secrets. I haven't included that link but I can find it real quick. And it is really great for understanding how encryption works including these, how do you negotiate a key without having a shared key to start with. And Chuck if you share that with me then we'll try to include that in the archive. So yeah, that would be a great additional resource to add. All right, we got a question now moving on to restoring the PCs to their known good state. And someone said to restore our public PCs to a known good state requires a reboot. So would rebooting so often decrease the life of the PC? It should not, it especially wouldn't if you had a solid state hard drive. But no, it should not significantly impact the life of the computer. And of course many of the things that you are talking about here are related to kind of the back end IT function of the computers. And so you do a lot of that in-house as your role as IT librarian. But we got a question for those who maybe don't have that same relationship with their IT department. All of our computers are maintained through the IT department at the city and we don't have a lot of control over these issues. So do you have any suggestions for how to convince the city of the importance? So that is actually where my library was a few years ago. And they hired an IT librarian specifically to change that. So that is one option is to bring it in-house. A lot of IT departments, especially like municipal IT departments don't really have a good understanding about the IT needs of libraries because what we do tends to be very different than what other city departments do. So you either need to be able to communicate with the IT department in a way they understand your needs, which of course involves understanding your IT needs. So you need a base level of understanding yourself so you can talk to them and communicate. Or you need to train or hire someone on staff who has this understanding and either can do it themselves or can communicate. So it will involve either staff training, professional development, or it will involve actually hiring someone who already has those skills. But I would say if you look at what public libraries especially do today, the technology side is as important as books are, if not much more important. And we never think twice about hiring a cataloger or hiring someone to do collection development. But a lot of libraries bulk at hiring someone with IT skills. And I think that just needs to change in libraries. This is a mindset that hasn't kept up with the reality of what we do. All right. Great. Thanks for answering that question. Now we're still getting a lot of good questions coming in. And I want to just assure everybody that if we don't have time for them today, we'll get to them via email later on. But I have one last question. Actually this came on early on. Chuck, I'm going to have you answer it first. And then Bill, if you have any last comments, we'll have time for that as well just a minute or two, whether it's to answer this question or just to add anything else in. But this question actually gets a little bit at some of the – and we didn't talk about this a whole lot, but about the concept of collecting library patron data, whether this is from the ILS or the public computers, the types of data you might be collecting to make customer service decisions and to market services better to patrons. And Chuck, I don't know if in your library you had any conversations around this, but it certainly revolves around this patron privacy issue. So Chuck, if you have just some brief words on that to share from your perspective in the IT or your perspective as a librarian, and then we'll bounce it over to Bill. Sure. First I would say check your local laws because every state has patron privacy laws regarding what library information can and cannot be used for what purposes. Now using patron information to better market your library services, I would say typically what we would look for is just making it an opt-in rather than an opt-out. That is you don't just send out mass emails to everyone who has a library card, but you can ask them when they sign up for a card, would you like to be included in our emails? Our children's librarian actually collects email addresses from parents so she can let them know about upcoming children's events. And that's an opt-in model. And I think that's perfectly fine because that's patrons actually saying yes, we would like to participate in this. Yes, we would like to have our information used for these purposes. And you also have to have a good well thought out privacy policy saying what you will and will not use the information for and make sure you hold yourself and your staff to it. Great. And just one more bit from – check that was a thank you for sharing your perspective on that from your library. This is also something that is included in the American Library Association's statements on patron privacy and collection of patron data. And those are links we will also be sharing in the archives and it's a part of the new checklist that we talked about as well. So it is included the recommendations from the American Library Association and Lita are going to be included in the archive. Bill, we have just one minute if you're still on the line and you have any last words you want to share whether it's on that question or something else, come on and let us know. Yeah, I mean the only other thing that I had to add to that and Dr. Really did that question due diligence is to make sure that the patrons themselves are aware of any information that they're giving out and have links to learn more. You know, user education again is really important and if the patrons don't know where that information is being delivered and how it's being dealt with then they can't really have any objective assessment of whether or not they'd like to opt in or opt out. Great. All right. Well, thank you Bill. Thank you Chuck for sharing all of this today. I'm afraid that's all that we have time for but it sure has been information rich hour. We'll follow up on those unanswered questions soon via email. I did want to let you all know about some upcoming webinars that might be of interest including one on the 28th of March about technology donations through TechSoup, one on Disaster Prep and Recovery on April 4th, and one on digital storytelling for libraries on April 26th. Save the date for that one. Also please visit us at TechSoupforLibraries.org where we've got blog posts and webinar archives and all sorts of other information that is library specific for you. And that's all. We just want to give one last word of thanks to ReadyTalk, our webinar sponsor for today, and thanks to all of you for joining us. Have a great day.