NPR and Encrypting the Web

NPR Digital has launched an effort to convert our website and products to secure connections, in step with many of our media and technology colleagues. Internally, we have labeled our project “Https Everywhere” (the meaning of HTTPS and its impact on the web to be explained below) and one of the hurdles we’ve encountered in moving to be secure has been the myriad of audio sources and streams within our systems and databases.

Our products, such as NPR One and the NPR News App, ingest and serve our newscasts, audio programs and podcasts. Because NPR One features content from member stations and third-party podcast producers, we interact with audio that is created on many different platforms: some support secure RSS feeds, some don’t. Therefore, we hope to briefly share our intentions and reasoning, and educate the wider podcasting and public media audience about what secure really means.

What do we mean by “secure”?

The web as a whole is taking part in an initiative to encrypt itself. Hypertext Transfer Protocol (HTTP) has long been the standard for site traffic. NPR’s website has much of its own hyperlinks as HTTP. As has been discussed in the news and by experts, this protocol has flaws that allow for malicious users on the internet to take control of a user’s browsing session, listen in on what someone else is doing on the internet and even spoof or redirect users to malicious sites.

HTTPS tries to resolve these issues through encryption. It works by having a digital certificate signed by a trusted Certificate Authority on a site’s server. Browsers have pre-loaded Certificate Authorities they know to trust and will normally avoid sites with bad CAs, or at least warn users. Each digital certificate has a public and private “key” that is used to encrypt data and allows both browser and server to un-encrypt communication between each other. This type of communication is called Secure Sockets Layer (SSL) because packets to a server are encrypted and then exchanged over a different port (Port 443).

The result: It’s not just having “https” and a green lock icon in the address bar. Having an SSL-enabled site makes eavesdropping more difficult. NPR listeners often donate to stations or register for newsletters and notifications on our site — making sure no one can peek into that activity is important to us. SSL certificates also assure browsers that we are who we say we are. If an authority signs a certificate and stands by it, then it is like a digital form of a passport.

In an age of spoofing, hacking and general thievery on the internet, NPR must establish trust among visitors to our site.

What NPR is Doing to Protect Listeners

We have established a team of product owners and technicians to assist in making NPR encrypted, safe and secure. Our site and products have a wide range of audio and visual content both from NPR and NPR-affiliated stations and partners. This makes the job of securing the site multifaceted and complex. Secure has different meanings depending on the type of content we are servicing.

Central to all of these concerns, though, is the fact that our products such as NPR One, our News App and the’s persistent player need end-to-end secure audio.

If at any point in the process of downloading, ingesting or consuming audio there is an insecure (HTTP) link, then the listening session is insecure. Just having a link to a playlist being secure may not be enough if that playlist references insecure audio. While this makes the job of transitioning to full HTTPS more difficult, we know that it will ultimately provide a better experience for the end user.

Consider that users today want to ensure content is from a trusted source: If they get an RSS feed for a podcast from a SSL-enabled, Certificate Authority-backed site but then download audio from another, non-SSL source, the chain of trust is broken.

To illustrate and explain this concept, let’s take a look at two of our efforts to secure audio.


A secure podcast is defined by our team as one that exhibits the following qualities:

  1. The main RSS URL needs to be HTTPS.
  2. The main RSS URL should not redirect to a HTTP feed.
  3. The enclosure URL for audio needs to be HTTPS (ex: <enclosure url=”" length=”0" type=”audio/mpeg”/>).
  4. Each HTTPS audio link does not redirect to HTTP and works over HTTPS.

Our podcast content — merged from our own NPR-produced shows, station shows and partner feeds — constitutes a great deal of traffic on our site. For our own produced shows, we have secured our Content Delivery Network (CDN) to serve all our audio securely. In addition, we’ve made sure that our RSS feeds are linked with the HTTPS protocol. For stations and partners, our technicians and product owners are working to have them update their own feeds.

Live Radio Streams

Our live streams — which are played both in iTunes as well as the site’s persistent player — are being actively converted to HTTPS. This work is done via our StationConnect tool that stations use to update their streams on NPR and member stations’ sites. As with podcasts, the requirements for security are multifaceted and have to do with locking down the end-to-end experience in HTTPS:

  1. All links to MP3, AAC, M3U and PLS must be https:// and work (i.e. do not redirect to HTTP, timeout or send back invalid certificate issues).
  2. All listed audio links within M3U and PLS files follow the same criteria as above in #1.

What NPR is Doing To Protect Website Visitors

When navigating to our main site ( over HTTPS, you are currently directed to the HTTP version. This is a conscious decision since much of our content is still “mixed media,” meaning it is from from both secure and insecure sources. The site needs to go through its own HTTPS work before we serve it over HTTPS. NPR Digital has obtained SSL certificates for most of our NPR domains and is setting up new servers and infrastructure with SSL.

Additionally, we are working to make sure content that can be served securely already is converted or migrated to do so. For example, many of our audio files were originally served through an insecure domain. This domain is not SSL-enabled and therefore we’ve moved — and continue to move — content over to our secure domain, “”

On a separate track, we are moving forward with applying infrastructure changes to bolster site security. This is primarily in the form of security headers inserted in each request to our server via our server software. To date, we have implemented a key subset of recommended headers that we find to be relevant to our site and still have a positive impact to our HTTPS everywhere goal. These help boost security by enforcing shutting off loading a page if code injection is detected, preventing undocumented or malicious use of pages in iframes and stopping browsers from possibly analysing compromised content. While not all browsers support these headers at the time of this writing, we still feel it important to keep ahead of the curve in browser security.

The staff at NPR has been given freedom to insert any links, images and content they need into stories. We are gradually limiting insecure media additions within our content management tool. Our TechOps team is focusing on converting existing media content that is currently served over HTTP to be served over HTTPS. Several NPR Digital teams are converting functional portions of the site to work over HTTPS; an example of this is our login page, which is using secure encryption. More work is slated to convert all of our pages with user input to be encrypted as well. All of these efforts together form a consistent and significant milestone toward making our site be served over HTTPS everywhere.

We are going to continue to charge ahead this year on this work and we would welcome hearing your organization’s experience with HTTPS. It’s a large effort, involving many stakeholders, but we know it’s valuable.

Stacey Goers also contributed to this post.