There was an unexpected error authorizing you. Please try again.

SHARC! We’re Going to Need a Bigger…Team!

We’re building a new API-managed container for handling ads cross-platform, but we need your help!

What is SHARC?

SHARC is an acronym for Safe HTML Ad Richmedia Container. For those of you familiar with SafeFrame or MRAID, SHARC is a new development aimed at taking the best of both worlds (or ad serving environments, in this case) and creating one API that can serve an interactive ad anywhere. 

The SafeFrame/MRAID Dilemma

MRAID, or Mobile Rich-media Ad Interface Definition, is the container standard that enables rich media ad experiences in mobile native apps. MRAID 1.0 was released in October of 2011. The biggest use case that MRAID covered was expandable ads and has supported that since the first version. The latest version (MRAID 3.0) supports many additional features, such as audio and video, resizable ads, and exposure controls. Since its last update a few years ago, newer web technology has made MRAID implementations more archaic and the container standard is showing its age.

SafeFrame is the container standard for managing ads in a web browser, most notably used to wrap ads served from Google Ad Manager. Originally developed in 2013, it has served its purpose as a way to place rich media ads on a publisher’s webpage without exposing page data. With the last minor update in 2014, SafeFrame has its limitations. When rich ad features don’t work using the current SafeFrame implementation, ad tech parties in the supply chain may request that the SafeFrame feature be turned off rather than troubleshoot broken features. However, removing the SafeFrame wrapper can put the publisher at risk and shifts resources toward implementing work-arounds to protect the publisher and its audience.

MRAID is widely adopted in mobile environments, but isn’t used in web environments. SafeFrame was made for web and could work in mobile and elsewhere IF the standard was adopted in those environments. As it is today, having two safe container APIs requires the build of at least two ads, each to function safely in their targeted environment.

Over the years, ad tech engineers have tried to create adapters or some kind of unified framework so that an MRAID ad could function in a SafeFrame container or a SafeFrame ad could function in an MRAID player. The results have…well, there have been no results. Any sort of adapter would require adoption of different pieces with different parties. 

The Opportunity

Last year, the SafeFrame working group worked on an update that would at least be closer to allowing for some level of cross-platform ad interaction. However, before release, we realized that this was our chance to start from scratch… 

…to create one safe container that can handle an interactive ad whether it was served to the Web, a mobile device, or even in-game. 

We would have one container with calls that all worked as expected. 

We could use new technology that would improve performance. 

We could simplify the technical spec by supporting integration with other ad tech standards that handle non-display functions like: ad requests, header bidding, ad delivery, and measurement.

We could set the technical spec and guidance details so that every party to the interaction would know their role and behave as expected.

We could create an API that would enable ad developers to “write one ad and serve it anywhere!”

We would have a lot of work ahead of us…

We would have to scrap the SafeFrame update and retire any efforts to update MRAID. We would have to encourage all of ad tech to drop their SafeFrame and MRAID implementations and adopt a whole new standard. We would have to instruct all parties in the ad supply chain on what they need to do to implement, use, and maintain the new standard. We would have to provide tools, modules, adapters, and support to make adoption as easy as possible. 

But most importantly…

We need developers to help us build, from the ground up, a new standard, proof of concept, and ultimately a new reference implementation and supporting tools if we’re going to make this dream a reality.

Baby SHARC Do-doo-do-doo

SHARC is the child product of SafeFrame and MRAID and is in its infant stage of development. We have a list of use cases and some requirements. We have a vision and notes. Coming on the heels of IAB Tech Lab’s Open Source Initiative announcement, we have the governance for inviting all developers from anywhere to help us build this important new ad tech standard.

Our next step is to build a proof of concept, but we need your help. If you are a developer, or know a developer, who can program in technologies that make use of the Web, webviews, or native apps (HTML, JavaScript, iOS, Android, etc.), we’d like to get in touch. 

Be part of a revolutionary effort to standardize safe ad interactions everywhere ads are served.

Head over to GitHub to get started or contact IAB product lead, Katie Stroud to get involved.


Jeff Carlson
Senior Manager, Technical Solutions Consulting

Aron Schatz

Aron Schatz
Former Head of Product and Data
Jeeng (PowerInbox)

Katie Stroud
Senior Product Manager
IAB Tech Lab