This document explains how a Conferences i/o web app can be embedded into an HTML iframe. 


Why would I want to embed Conferences i/o into an HTML iframe?

There are two common patterns we have seen for embedding Conferences i/o into an HTML iframe.

Pattern #1: Livestream / webinar integration

Web-based livestream platforms often allow for custom HTML to be inserted into a side panel, in a space that might typically be used for live chat or information about the livestream. When this option is available, you can use an HTML iframe to insert Conferences i/o into that side panel space. Though viewers can always use a secondary device (like their phone or another browser) to join Conferences i/o, embedding into a side panel is certainly the most convenient option.

Pattern #2: Intranet integration

Most intranet software (like Sharepoint) allows for custom HTML to be inserted. If you have an intranet, you might want to embed Conferences i/o into your intranet software at various times. For example, if you’re holding an organization-wide town hall, you could collect questions through a Conferences i/o session that is embedded in your intranet.

Other patterns

Though livestream integration and intranet integration are the most common patterns, there are certainly other scenarios where an HTML iframe makes sense.

What Conferences i/o URL should be embedded into an HTML iframe?

This question has a complex answer because there are two potential forms of URLs in Conferences i/o.

The first form is a standard Conferences i/o URL, what you would see if you browse to a Conferences i/o web application. For example, (FYI - that link will not go anywhere, it’s just to visualize).

The second form is a modified Conferences i/o URL that specifically triggers an “activation” process that gives the Conferences i/o iframe access to browser cookies. The modified form is identical to the standard form, except that “/iframe” is appended between the domain and the remainder of the request. For example,

If you need to collect identifying information (name, email, etc), if you’re using our “consent module”, if you’re using any kind of single sign-on integration, if you’re passing identifying information into Conferences i/o via the URL, or if you’re using our attendance tracking functionality — you must use the modified form of the Conferences i/o URL to trigger the activation process. Please see Appendix A below for more information on the modified URL form that triggers an activation process.

What does HTML iframe code look like?

Here is a simple example of HTML iframe code to embed Conferences i/o.

Notice that the URL embedded into this HTML iframe is a direct link for a session.

This example includes CSS style attributes which help define the size of the <iframe>. For your own purposes, you will likely need to include similar attributes and customize them for the space your need to occupy.

Appendix A: HTML iframe Activation Process

Why is the activation process necessary?

Like all web-based applications, Conferences i/o requires access to browser cookies for normal functioning. When you are loading a Conferences i/o page directly, this is generally not a problem; by default your browser will allow cookies to be created in this first-party context.

However, the circumstances change when you are embedding Conferences i/o into another website using an HTML iframe, what is known as third-party context. Some browsers (like Chrome) allow the websites in an iframe to access cookies as if you’d gone directly to that site. But, some browsers (like Safari) do not. Increasingly, browsers are moving to stricter rulesets for third-party cookies, so this is an obstacle that is not going away.

If you’re curious about the rationale for why some browsers block third-party cookies, it has to do with how advertising networks and social networks silently track people across the websites they visit (when those sites use analytics tools provided by those networks). You may have heard of these as “tracking” cookies, and unfortunately the only simple mechanism for blocking tracking cookies also prevents legitimate application-style usage like with Conferences i/o.

What can you do to trigger the activation process?

The good news is that we have developed a special way to embed Conferences i/o in an HTML iframe and have full access to cookies. The mechanism of action is an interstitial page on your Conferences i/o app that checks for cookie access and then helps a user activate cookie access when cookies are not immediately available.

From your perspective, all you need to do is slightly modify the URL that is embedded into an HTML iframe. For example, consider this URL:

Now, modify it by appending “/iframe” after the “” part. Here is what it looks like:

Pretty simply, right? The /iframe addition triggers the special interstitial page on your Conferences i/o app. When cookies are available, users will be redirected to the expected page.

What does the interstitial page look like?

If your browser requires additional steps to activate cookies for the Conferences i/o iframe, you will see something like this:

The “activation” button will open a new tab/window.

The “activation” button will open a new tab/window.

Browser-specific notes

Chrome (Windows/Mac/Mobile)

As of August 2020, Chrome on Windows and Mac is cookie-permissive by default. Generally, you will never see the interstitial page when using a Chrome browser.

Incognito Mode in Chrome — By default, Incognito Mode in Chrome completely blocks third-party cookies. An HTML iframe embedded Conferences i/o page will never work with Chrome’s Incognito mode.

Firefox (Windows/Mac)

As of August 2020, Firefox is cookie-permissive by default.

Safari (Mac/iPhone/iPad)

Safari requires the most process-wise to get cookies working. During the “activation” process you will see a prompt like this:

Unfortunately, there is no way to avoid this step, and users must choose “Allow” to complete activation.