Continuing our exploration of web browser security from last episode, Liz and Geoffrey look into cookies, JavaScript, extensions, and plugins and discuss how best to mitigate their privacy and security risks while browsing the web. Plus, a serious Reddit breach provides a timely reminder to toughen your two-factor.

Timeline

• 1:01 - Security news: Reddit breached via intercepted SMS messages for two-factor authentication
• 2:08 - Security news: Google is now making hardware security keys
• 3:03 - Security news: ways around iOS's USB Restricted Mode
• 3:42 - Security news: health insurers are getting personal details from data brokers
• 5:07 - Security news: Facebook suspends Crimson Hexagon
• 5:49 - Security news: Fortnite won't be distributed via the Google Play Store
• 7:28 - Web browser security model recap and snow boots
• 9:42 - Introduction to cookies
• 10:36 - Third-party cookies, ads, and tracking
• 13:18 - Other tracking methods, such as localStorage
• 16:51 - Running code in the web browser, browser plugins like Flash and Java
• 20:12 - Browser extensions, a safer way to run code
• 21:58 - Recommended extensions for better web privacy, ad blockers

Show notes & further reading

Cookies

There are some subtleties in the definition of "origin," especially as applied to cookies, because cookies date from the early days of the web before the same-origin policy was well-defined, and the rules can't be changed now without breaking existing websites. The high-level rule we discuss in the show - that storage from one website can't be read or modified by a different website - conveys the general idea, although web developers or security auditors may need to consult technical documentation on how cookies define "same website" differently from most other web features.

Supercookies and zombie cookies

One of the mistakes in the original definition of "same website" for cookies was that it was permissible to set a cookie for, say, all of .com as easily as for .looseleafsecurity.com. This cookie would be sent to all .com websites, allowing easy tracking across a large portion of the web (as well as some attacks involving fake login sessions). The term "supercookie" originally referred to these cookies, which browsers have since disallowed.

Now, it often refers to cookie-like techniques that permit similar tracking across many websites, such as Verizon Wireless injecting a unique ID into unencrypted HTTP traffic or a trick using a browser security feature, HSTS, to encode a unique identifier. Browsers are generally blocking supercookie techniques as they are discovered, but it is something of a cat-and-mouse game.

Another risk is "zombie cookies" or "evercookies," which use multiple forms of browser storage to try to persist cookie data if you only clear cookies. Browsers have also worked to reduce some of these mechanisms. As we discuss in the episode, if you're clearing cookies, remember to also clear all other forms of storage including browsers caches to protect yourself from these.

Extensions in snow boots

Because Chrome had been designed from the outset to sandbox all parts of the browser, they pioneered the approach of extensions being written entirely with web technologies like JavaScript and CSS. Chrome's approach is undergoing standardization as the WebExtensions API, which is supported in Firefox and Microsoft Edge.

Browsers that have been around for longer, like Firefox (which derives from Netscape Navigator), Internet Explorer, and Safari, had add-on / extension frameworks that often permitted direct access to the browser itself and therefore to the entire desktop; for instance, old-style Firefox extensions had access to Firefox's own C code. Newer browser architectures like Edge or Firefox Quantum have generally dropped support for this older style of extension.

Safari, uniquely, has moved from an older extension model based on sandboxed web technologies to a newer model allowing communication with a native app - but the native app is distributed through the Mac App Store, which places apps in "snow boots," as we briefly discussed last episode. So Safari App Extensions still don't have unrestricted access to your desktop.

Extension permissions

WebExtensions authors can request several permissions for access to various browser features, such as the ability to copy to or paste from your clipboard, to edit your bookmarks or read your history, or to change your proxy or DNS settings. Chrome, for example, will ask your assent for some, but not all, of these permissions. Notably, the activeTab permission allows an extension to read and modify the current tab when you click its icon in the toolbar (i.e., it gives complete access to the current website's snow boot), without prompting you for permissions in advance. This limits the access of a malicious extension - it cannot silently mess with all your web pages - but it's still a serious amount of power, so you should be careful about what extensions you install, even if they don't ask for special permissions. Of course, any extension that can "Read and change all your data on the websites you visit" can do exactly that, without any further prompting.

Unwanted content blockers

As discussed in the episode, we suggest uBlock Origin if you're interested in an ad blocker, and Privacy Badger if you just want a cookie / tracking blocker.

If your browser has an option for disabling third-party cookies or trackers, such as Safari's third-party cookie prevention (which is on by default) or Firefox's tracking protection, that's also generally a good idea to enable. All of these options carry some small risk of breaking websites that were designed with the assumption that third-party tracking would always work (for instance, Mozilla's developer documentation on tracking protection gives an example of a poorly-designed website that breaks if Google Analytics is nonfunctional), and some websites have started detecting ad blockers. A content / ad blocker is the most effective at protecting against tracking and malvertising, but also the most likely to break sites, so pick something that works for you and your level of willingness to tinker with things.

Even more effective is NoScript for Firefox, which disables all JavaScript by default. This will certainly break large parts of the modern web until you customize it, so we only recommend it for people who think they're at unusual risk and are willing to spend time tweaking settings for every web page they use.

In the news

Reddit suffered a major security breach last week, when an attacker was able to intercept SMS-based two-factor authentication codes for some of their employees. Reddit says, "We point this out to encourage everyone here to move to token-based 2FA." We agree - check out our episode on two-factor authentication methods for more about that! Also, for those of you with anonymous / pseudonymous Reddit accounts, note that the breach exposed a way to link email addresses to usernames for all accounts created in 2007 or earlier, effectively deanonymizing those accounts.

Transcript

Geoffrey Thomas (GT): There's nothing quite like a warm, chocolate chip cookie fresh from the oven. But if I eat too many cookies, I sort of feel sick. Don't you feel the same, Liz?

Liz Denys (LD): Mmm, browsing the web is kind of like that. A few cookies are good, but some cookies can do more harm than good.

GT: Today on Loose Leaf Security, we continue our series on web security and privacy by focusing on cookies, JavaScript, plugins, and extensions.

LD: Geoffrey, I really hope the rest of the episode has better analogies than eating too many cookies.

Intro music plays.

LD: Hello and welcome to Loose Leaf Security! I'm Liz Denys,

GT: and I'm Geoffrey Thomas, and we're your hosts.

LD: Loose Leaf Security is a show about making good computer security practice for everyone. We believe you don't need to be a software engineer or security professional to understand how to keep your devices and data safe.

GT: In every episode, we tackle a typical security concern or walk you through a recent incident.

Intro music fades out.

LD: Reddit announced a major security incident last week. An attacker compromised some employees accounts by intercepting SMS messages for two-factor authentication.

GT: This breach is an excellent reminder of how SMS is pretty insecure and that you should use more secure two-factor authentication methods like authenticator apps and security keys whenever you can.

LD: The breach included email digests from this past June and all sorts of Reddit data from 2007 and before, including account information like email addresses, public posts, and even private messages.

GT: Reddit says only salted hashed passwords were breached, but since it looks like it was a weak hash and small salt by modern standards, you should update your password if you're still using the same one that you were using in 2007.

LD: We also want to be clear that this breach links email addresses to usernames for all accounts created in 2007 or earlier, effectively deanonymizing those accounts. Reddit included a link for removing information from your account with their announcement about the incident.

GT: Kudos to Reddit for a pretty clear disclosure of what happened, but for those of you who had a Reddit account in 2007, this seems like a pretty concerning breach, and you should think about what data was exposed, including your private messages.

LD: Remember how last episode we mentioned that Google said that none of their employees have been a victim of phishing attacks since they started requiring them to use security keys for two-factor authentication? Now Google is launching their own hardware security key products.

GT: One of them is a pretty standard USB security key that you plug in and tap when you want to authenticate, and the other has Bluetooth support for mobile devices.

LD: We're pretty excited that Google's USB security key brings more competition to the security key space, but we're worried about the option that communicates to your mobile device over Bluetooth. Yubico, the original, well-known manufacturer of USB-based security keys, issued a response saying that Google's Bluetooth offering "doesn't meet their standards for security, usability and durability," which makes sense since Bluetooth is a relatively insecure protocol, as we discussed in our episode "Securing your phone."

GT: Security concerns aside, Bluetooth based security keys also require batteries, so when the charge runs out, you might find yourself unable to get into your accounts.

LD: Last month, USB Restricted Mode made it out of the iOS beta and into the main release.

GT: We were optimistic that this would help fight back against unlocking devices like the GrayKey, but it looks like researchers have already found a way around the shorter one hour lockout period introduced with USB restricted mode.

LD: The way to get around this is unfortunately simple: connecting any accessory device to an iPhone resets USB Restricted Mode's 1 hour lockout timer if the device hasn't already gone into that mode.

GT: USB Restricted Mode is still an improvement because hackers or law enforcement have to attach some accessory device your iPhone within one hour of your locking it, but the best defense against unlocking devices like GrayKey is a long passcode.

LD: In privacy news, ProPublica and NPR released a story about how health insurers are getting details about hundreds of millions of Americans from data brokers, things like your education level, what TV you watch, what you order online. Insurers claim that they want to use this information to identify potential health issues in their clients so they can get them services that they need, but there wasn't any evidence that they've actually been doing this. I've certainly never seen anything from my health insurers before.

GT: And this isn't just health or wellness data, like how often you go to the doctor, but also things like what magazine subscriptions or hobbies you have - information they're using to analyze health costs across groups of people, even if it isn't very accurate for inferring things about any individual. The article also says that data brokers often require that this sort of information shouldn't be used to set health insurance prices, but they asked a research scientist from one of the companies about whether that happens, who said, "I can't say it hasn't happened."

LD: This is actually pretty interesting because data brokers will generally claim that they sell anonymized versions of your data, but if health insurers are getting it to the granularity where they could be using it to set prices, it's not anonymized. Even if they're only using it to offer additional help or services to their customers, as they state, that still requires identifying data down to the individual person.

GT: Unfortunately, there's not really anything we can do with this information, but as health care is a fairly hot topic in US politics right now, privacy laws surrounding our personal data might be something to keep an eye out for. Speaking of privacy concerns, Facebook has suspended Crimson Hexagon, an analytics firm, while they investigate concerns over how Crimson Hexagon collected and shared public user data.

LD: This story seems to still be developing, and hopefully Facebook will be transparent with the results of its investigation. According to the Wall Street Journal, the suspension involves figuring out whether contracts with the US government and a Russian nonprofit tied to the Kremlin violate Facebook's government surveillance policies. Facebook prohibits user data being used for government surveillance, a policy that came to be after pressure from various civil liberties groups last year.

GT: This comes in the wake of the Cambridge Analytica scandal, so it's very likely we'll have more details soon thanks to increased public scrutiny of Facebook's data practices.

LD: Fortnite, a popular online game from Epic Games, is making a peculiar distribution decision for their Android release. In order to avoid giving Google a 30% cut of its Android sales, they're going to direct players to a website to download a ".apk" file and install it directly, instead of going to the Google Play Store to get the app.

GT: ".apk" files are Android package files, but usually you don't deal with them directly. The Google Play Store typically handles distribution of them to you - it has a library of ".apk" files that have been vetted by Google to guarantee they don't have malware - and when you click to add a new app from the Play Store, your phone downloads and installs that app for you.

LD: Downloading an ".apk" directly from the web opens up a whole can of worms - if you don't carefully vet which file you're getting you could be getting malware instead of Fortnite. There's already been rumors that people are saying this as of yet unreleased Android game is already available, and providing them with a link to malware.

GT: There's a checkbox in Android settings for whether the phone will let ".apk" files that aren't from the Google Play store be installed. Enabling this - called "sideloading" - carries the risk of installing malware that hasn't gone through any review or oversight in the the Google Play Store, so it's uncomfortable that a generation of gamers are going to have phones with this checkbox checked. Google did start recently doing malware scans of sideloaded Android apps, but they still have much less control than they do on the Play Store itself.

LD: And this case, that lack of control translates to lowered security. We'll get to our main segment after a quick break.

Interlude music plays.

GT: Last episode, we started our journey through web security by exploring the history of web browsers, and how they use a technique sometimes called a "sandbox" to keep websites from spilling out into your computer.

LD: Although sandboxes aren't very good at keeping all of the sand inside the sandbox, so we decided it might be better to think of it as a snow boot. Even in deep snow, a good snow boot will make sure that what's inside stays inside and what's outside stays outside.

GT: Just like each of your feet stays within its own snow boot, each website stays in its own place. It has its own storage, its own limited ability to access the web, and its own isolated place for running code.

LD: We chatted last time about the web's security model, which restricts what web pages can ask the web browser to do because of these snow boots. To recap, anything from a website has pretty unrestricted access to the same website - its origin. It can ask your computer to run code and communicate with those same web servers, which is how a lot of interactive features work - like live updates or chat apps.

GT: But access outside that origin is heavily restricted, as is access to your computer itself. It doesn't have access to your files, for instance. The only way it can get to a file is if you go through an upload dialog, or drag-and-drop something onto the web page.

LD: And while it can send messages to other websites, its ability to read things from other websites is very limited - those websites have to specifically say, everything I have is public, it's okay for any other website to see it.

GT: So if you're logged into your email account in your browser, only that website can get to your email. The browser won't let other websites make connections to the web servers that have your email. This snow boot model is what makes it fundamentally safe to browse random websites - a new website shouldn't have access to do anything interesting - and because billions of people visit countless websites every day, web browsers have been forced to figure out how to make security layers that are pretty hard to get past.

LD: This is the opposite of how desktop applications work. Any regular, traditional desktop application you have installed has access to every file on your computer and has unrestricted ability to make network connections. So that video game you just installed - if it wants to - can just figure out where your email password is saved and connect to your email server and do whatever it wants.

GT: But a video game you're playing inside your web browser can only talk to the web server it came from, and it also can't get to passwords or login sessions for other websites, anyway.

LD: Yeah, another thing that's kept in each snow boot separately is cookies.

GT: Mmm, I love cookies! But I don't like getting them in my boots...

LD: On the web, "cookies" are short pieces of information that websites can ask the browser to store, and every connection back to that origin gets the cookie. This is usually used to make website logins work. When you enter your password, and hopefully your second factor, the website sends back a small identifier saying who you're logged in as. Next time you open a web page from the same origin, you don't need to enter your password again, and your web browser doesn't save it. It just sends that cookie that says you're authenticated.

GT: A web page from another website can't access those cookies, so it can't pretend to be you, even though it's running from the same browser. It doesn't even have the ability to send those cookies back to its own servers, where something on the server can try to log in as you.

LD: But a regular desktop app can do exactly that - stealing the authentication information from another desktop app, or from your web browser itself because it's not constrained by snow boots.

GT: While cookies are absolutely necessary for basic web features like logins, they can also be used to track you across different websites as you browse the web. Remember that the web's security model doesn't consider it to be a problem for web pages to embed other web pages, and it definitely allows web pages to include images from other origins. And when the browser loads one of those images, it sends over any cookies for that origin, like it always does. That's called a "third-party cookie": the server it's accessing isn't the first party, the origin of the web page you're visiting, but some third party providing a resource, and the third party gets to see its cookies.

LD: Loading images from other websites happens very frequently - any web forum is full of this, for example - but two very notable cases are online ads and share icons for social media sites.

GT: Some browsers give you an option to disable third-party cookies, which is generally a good idea for privacy. If a browser has third-party cookies enabled, which most browsers do by default, then every time you visit a website with an ad from the same ad network, that ad network can tell that the same person is visiting all of these different websites, because it'll see the same cookie, plus a reference to each site that it's purchased ad space on. Similarly, if you're logged into Facebook, every time you visit a site with a Facebook share icon, Facebook can tell that you've been to all of these sites.

LD: Third-party cookies are able to get much broader access to your web history than a first-party cookie can, and often they're specifically intended to track your web history across all pages that allow a given advertiser or other third-party access to their cookies. This isn't necessarily exactly malicious, though.

GT: Advertisers often argue that personalized ads are better for you because they're more relevant. And yes, I'd prefer to see an ad for, say, the latest two-factor auth token than for restaurants in another country. I'm public about some of my interests, but third-party cookies don't give me any control over this - if any website I visit is using an ad network, that ad network knows who I am.

LD: It's also not just a personalization problem, but also a granularity problem. Ads are often not just personalized to know what types of things you are interested in, but specific things you expressed interest in. I find it rather creepy when I get an ad for a particular item I was looking at from Target, and because I'm creeped out, I personally am less interested in clicking on an ad and actually buying that something that I was thinking about buying before. Honestly, I'd be a lot more susceptible to somewhat personal but less specific ads that maybe communicated something more like, "Target is a store you might want to purchase something from." A big part of it is that because I've seen how specific their information is already, I don't want to give them even more extremely specific information by clicking on such a pinpointed ad. However, I could envision a web where I had more control to say something like, "Only communicate high level data to advertisers," that would be enticing for me to click on, without being too creepy, and that could be a big win-win overall.

GT: But sadly, that's not the web we're in, and even if you disable third-party cookies, there are other ways that third-party sites can track you. A couple years ago, web browsers added something called localStorage, which is much higher capacity than cookies. Websites with features that "work offline" generally use localStorage. Unlike cookies, they're not sent across the net when you request a site; they're only accessible to JavaScript running as part of the website's origin. There are a few other ways to store data using JavaScript, but in terms of security, they're basically similar to localStorage.

LD: All of these work in the same way as cookies: whatever is in one snow boot stays inside that snow boot, and isn't accessible to websites running in other snow boots unless the website that owns the data specifically sets up a way to make that data accessible.

GT: Because localStorage isn't sent with an HTTP request, it can't be used to track you on websites that simply load images. But if one website is embedding an actual HTML page from another website, which has started being popular with more complex ads and things like embedded tweets, then the HTML page counts as the third-party origin, and has access to its localStorage.

LD: Browsers are very inconsistent about whether blocking third-party cookies also blocks third parties from accessing other forms of storage. If they don't, then embedded ads or social media functions can track you by keeping a unique identifier in some form of localStorage. It's a little more work on their part than just checking a cookie, but it's not hard at all.

GT: Like cookies, localStorage can be cleared when you clear your browser's history, but it's worth noting that the specific similarities between cookies and localStorage but separation of the two has led to a particularly nasty type of cookie called a "zombie cookie" that reappears when you clear only the cookies by drawing on the other session information in localStorage.

LD: To make sure you clear that, you should clear all of your browser's history at once - cookies and localStorage and whatever else.

GT: It's sort of a historical anachronism that you can still clear these separately - before the rise of password managers, there was a desire to delete as much browser history as you could without having to re-login to every site you were visiting.

LD: This shouldn't be a real problem anymore, though, because as long as you're using a password manager to manage your passwords, logging in doesn't require having to remember or find all of your separate, different passwords, and ideally, it's even integrated into the browser to help protect against phishing from the wrong origin like we mentioned last time.

GT: Right, there's really no reason not to clear everything because recovering the parts of your former session that you wanted is easy with password managers, and this helps to keep zombie cookies from popping back up.

LD: Beyond the ubiquity of ads that are tracking you as you browse the web, there's a specific problem with "malvertising" - the delivery of malware via online advertisements. Since many ad networks permit advertisers to control the HTML content being shown in the ad, online ads are a popular avenue for malware authors to get their code in front of as many people as possible.

GT: Ads are just web content, so they are protected by the same snow boot just like everything else on the web. But there's a higher risk of malicious ads intentionally trying to get past the browser's defenses, when probably the actual website you're visiting isn't trying to hack you.

LD: A good first line of defense against both these security risks and the privacy risks of cross-site trackers is an extension that blocks unwanted content. Usually these extensions are ad blockers, either on purpose or as a side effect of the things they block, but they're worth installing for their security benefits alone.

GT: We'll talk about this more later in this episode when we get to extensions.

LD: But first, let's take a quick break.

Interlude music plays.

LD: If you've been around the web for a while, you know there's a lot more going on than just cookies and other types of information storage. Cookies aren't programs and they don't run code, but there are other ways to run code. The idea that the modern web is full of pages that are running code probably makes you a little nervous, and for good reason. Remember Java and Flash and how often they had security issues?

GT: Right - is there anything that makes JavaScript and videos and everything else safer? Or is it just that one technology got more popular and the rest got less popular?

LD: There is an important difference, and it's basically that JavaScript and all these HTML5 features are built into the web browser. Java, Flash, and so forth are things that are added on top - so they're trying to use the same policies, but they're not using the same snow boot itself.

GT: They're kind of like socks that get wet and pull water into your boots and then your feet start to freeze.

LD: Sure, something like that.

GT: In the last few years, most websites using Flash and Java have moved to technologies that are built into the web browser. And on the whole, that's been very good for web security. The job of web browsers has gotten harder in the process - it's harder to make snow boots that keep your feet dry when you're stuffing more things inside - but the popular browsers have all gotten very good at it.

LD: Before we move on to more modern ways to run code in a web browser, let's talk about the history of Flash and Java because their mistakes informed modern web browser design around running code in the browser. Web browsers originally supported very little functionality for web pages and slowly built that up over the last twenty years or so, but Flash and Java were built to be, well, flashy from day one. They prioritized getting cool features to work immediately because people wanted them, instead of prioritizing careful, secure development.

GT: This definitely showcased what the web could be, but also caused no end of security problems.

LD: Java and Flash are browser plugins, which means that they're software separately installed on your desktop, not something that runs entirely inside the browser and its snow boot. They only run when you're on a website with a Java applet or a Flash animation, but unlike JavaScript, the web browser starts up this outside program. So that means two things: first, any bugs in Java or Flash can potentially give access to your entire desktop, just like a bug in any other desktop program. Second, Java and Flash don't get to use the browser's idea of snow boots. They have to implement their own mechanisms for isolating websites, and they don't always get things right. Some of the security issues have been things like, a website can use Flash to read files from other websites that it shouldn't be able to.

GT: Google Chrome started working on sandboxing Flash in 2010 and got it working for all platforms in 2012, in part by redesigning the plugin interface to not require full desktop access. This didn't scale well to plugins in general.

LD: Apple's iOS never supported Flash, partly because of its security track record but also because of the architecture. iOS has always put each program in its own snow boot, so supporting Flash would involve either making it share the web browser's snow boot, risking many of the same security problems as on desktop, or significantly redesigning Flash.

GT: Between the inability to use Flash on iPhones and iPads and the poor security history, most websites have moved to newer technologies built into HTML, so you rarely need Flash installed these days. Chrome's redesign of the plugin interface never got picked up by other browsers, so if you absolutely have to use Flash, the safest way is via Chrome.

LD: Other plugins like Java also have very little use these days. If you're on an older computer where you may have installed Java or Flash in the past, it's a good idea to uninstall it unless you know of anything that needs it.

GT: A step down from plugins are extensions. These are also additions to the browser, but unlike plugins, they're not structured as actual desktop software that happens to work with the browser - they're built using web technologies like JavaScript, so they're fully contained within the browser itself.

LD: Extensions also get their own snow boots, but they have the ability to request permissions to access other websites' snow boots. For instance, a password manager extension might be able to work with any web page as long as you click the password manager button.

GT: Or a night mode extension might add a stylesheet to replace light backgrounds with dark ones, or an ad blocker might just prevent ads from loading.

LD: There are also extensions that don't need any permissions - for instance I have one that just loads some cute cartoon cats on every new tab.

GT: Extensions are relatively safe, but the ones that ask permission to modify content on web pages are risky, because that's a pretty straightforward way of bypassing the snow boots' protection. If a single extension has access to every snow boot, you have to trust that it's not breaking your security in the process. For a night mode extension, that's probably easy. For a password manager, that's definitely riskier.

LD: There was a pretty bad vulnerability in the LastPass browser extension two years ago where it turned out it wasn't computing the site name of a website correctly: an attacker could make a website with a specially crafted URL that tricked LastPass into thinking it was from, say, twitter.com, and LastPass would give it your Twitter password.

GT: We still think that for most people, the benefits of using a browser extension for password management outweigh the risks - I installed one recently and it's gotten me to update a bunch of weaker passwords - but it's worth being aware of.

LD: And of course an actively harmful extension has a lot of power over your browser, especially if it gets the ability to read and change content on web pages. Extensions are a much better architecture than plugins, but it's not safe to download random extensions the way it's safe to visit random websites.

GT: There are a few extensions you might consider installing, besides a password manager. As we mentioned earlier, an ad blocker, or really an unwanted content blocker, can be pretty valuable for your security and privacy.

LD: Finding a trustworthy ad blocker can be hard, because in order to work, an ad blocker must have pretty unrestricted access to all pages in your browser. Double-check the name and author of the blocker you want to use. One researcher recently found a number of low-effort copies of ad blockers, many that added malicious code, on the Google Chrome extension store, with apparently twenty million users having downloaded one of those fake ad blockers.

GT: AdBlock Plus was popular for a while, but then they introduced an "Acceptable Ads Policy" that rubbed many people the wrong way, with accusations of advertisers being able to pay for AdBlock Plus not to block them. The current leading contender seems to be uBlock Origin - not to be confused with uBlock, the old name of the same project, which is not actively developed and not under the control of the original project developer.

LD: uBlock Origin bills itself as a "wide-spectrum blocker, which happens to be able to function as a mere 'ad blocker.'" Its goal is to reduce unwanted network traffic, which both prevents sending cookies and reduces your network traffic usage. It's based on the same list AdBlock Plus uses, but has additional rules and filters.

GT: If you're not comfortable with blocking ads - say, if you feel that it's unfair to view ad-supported websites without loading the ads - a somewhat more finely tuned option is the EFF's Privacy Badger extension. Privacy Badger attempts to detect whether a website is tracking you, and has the ability to block third-party cookies and perhaps all access to third-party websites when you're being tracked, but not otherwise.

LD: So a regular image-based online ad will still load like it always has, just without a cookie that tells the advertising company who you are. The website you're visiting still gets the ad revenue from when you visit.

GT: Privacy Badger is also probably a little more effective and a little less likely to break sites than your browser's built-in third-party cookie tracking. I've been using it for a few years, and it's only broken a website once for me, and it was pretty easy to tell it to load the content that it had blocked.

LD: If you think you're at an unusually high risk of attack and are willing to risk websites being not completely usable in order to keep your computer safe, you might also want to consider NoScript, which disables JavaScript on websites by default. It's a pretty big hammer, but it does vastly reduce the attack surface that malicious websites can use.

GT: But for most people, the best option is probably to install either uBlock Origin or Privacy Badger and leave JavaScript and cookies enabled. Modern web browsers are pretty good at keeping you safe; just take a few extra steps to maintain your privacy.

LD: And make sure to check what extensions and plugins you have enabled, and get rid of anything that you don't need.

GT: Since the web is so complex, we still have one more episode in our series on safely surfing the World Wide Web: privacy concerns.

LD: Look forward to hearing all about HTTPS and private or incognito mode browsing next time!

Outro music plays.

LD: Loose Leaf Security is produced by me, Liz Denys.

GT: Our theme music, arranged by Liz, is based on excerpts of "Venus: The Bringer of Peace" from Gustav Holst's original two piano arrangement of The Planets.

LD: For a transcript of this show and links for further reading about topics covered in this episode, head on over to looseleafsecurity.com. You can also follow us on Twitter, Instagram, and Facebook at @LooseLeafSecure.

GT: If you want to support the show, we'd really appreciate it if you could head to iTunes and leave us a nice review or just tell your friends about the podcast. Those simple actions can really help us.

Outro music fades out.