Adopting Encryption: The Need for HTTPS

By Brendan Riordan-Butterworth

It’s time to talk about security.

In fact, last year was the time to talk about security. From The New York Times to Google, the call went out for websites to encrypt communications with their users, protecting the integrity and privacy of information exchanged in both directions. Even the U.S. government heard this call, and is working to require HTTPS delivery of all publicly accessible Federal websites and web services.

This year, the advertising industry needs to finish catching up. Many ad systems are already supporting HTTPS – a survey of our membership late last year showed nearly 80% of member ad delivery systems supported HTTPS. That’s a good start, but doesn’t reflect the interconnectedness of the industry. A publisher moving to HTTPS delivery needs every tag on page, whether included directly or indirectly, to support HTTPS. That means that in addition to their ad server, the agency ad server, beacons from any data partners, scripts from verification and brand safety tools, and any other system required by the supply chain also needs to support HTTPS.

Let’s break that down a bit more – once a website decides to support HTTPS, they need to make sure that their primary ad server supports encryption. That ad server will sometimes need to include tags from brand safety, audience and viewability measurement, and other tools – all of which also need to support encryption. The publisher’s ad server will often direct to one of several agency ad servers, each of which will also need to serve over HTTPS. Each agency ad server also may include a variety of beacons or tags, depending on how the deal was set up, all of which similarly need to have encrypted versions available. That’s a lot of dependencies – and when one fails to support HTTPS, the website visitor’s experience is impacted, initiating a costly search for the failure point by the publisher.

While the need to support HTTPS delivery will only continue to grow, getting there isn’t as simple as flipping a switch. As those who have already adopted know, there’s management overhead with acquiring certificates and making sure these don’t expire, increased resource requirements on servers to handle the encryption, and other costs. Carnegie Mellon has a great paper on some of the more esoteric impacts of adopting HTTPS. It’s therefore important that you communicate your experiences developing support for encrypted delivery with those who haven’t.

A core function of HTTPS is to prove the origin of a resource delivered from a server to the web browser. Each server delivering encrypted content has to acquire a certificate that’s signed by a trusted authority and issued to their specific domain. This results in a larger set of consistent identifiers for servers, which has beneficial implications in the fight against malware – it’s more expensive for malware peddlers to set up shop on an HTTPS server, and easier to identify the same peddler across occurrences.

Adopting encryption on public-facing servers is an important step in protecting the privacy and security of the public. It also sets the stage for broader support of server-to-server encryption, securing our business communications from eavesdropping when they’re routed over the public internet. Here at the IAB, we feel that broad support for HTTPS on public servers is a best practice for the industry, and that encrypted communications and strong origin identifiers are of growing importance as we tackle issues of fraud, malware, and piracy as a part of the Trustworthy Accountability Group (TAG).