iFrames or “inline Frames” were first introduced in 1997.
In over 20 years of use the technology industry used, praised, shunned and ignored iFrames.
This article explores this wonderful technology and how it can be used in a very positive sense.
iFrames or multiple screens?
Space is a premium for everyone. From the macro to the micro. However when a user needs information from multiple sources, space becomes even more of a challenge.
By 2020, multiple screens are common place.
In the late 90s multiple screens were not the focus. If you needed multiple sources of information available, then it was multiple computers with one screen each.
Technology is a tool to help users. So is there a better tool? Consequently software helped where hardware was a little slower to keep pace.
On one screen, could you have 4 web pages? iFrames enabled a very powerful option.
How it works
Set the width and height a little less than 50% and you can create the following.
As an output you get the following web page
Result!
So technically there are 5 webpages there. The frame page and then the 4 pages in the iFrames.
However the frame page became even more helpful. The pages in the frames can share information with the frame page itself.
Very simply put, details from the frame page can pass to each page in each frame, saving time and effort.
Abusing the system
This sharing information capability also became the Achilles heel of the technology.
Unscrupulous actors realised shared information between the frame page and the contents of the iFrames is possible.
A simple webpage, which had your online banking login in it.
So when the user typed in their username and password the frame could capture it.
Instantly iFrames went from hero to villain, so how to protect from this?
Server developers and browser developers employed a combination of technological solutions.
Servers adding information
When a server sends a webpage to your browser, it doesn’t just send the page, it also sends a host of helpful hidden information.
Because this information is sent before the body of the webpage, they’re called Headers.
Think of it like the envelope wrapping a letter.
Servers write extra information on the envelope (the headers).
The receiving browser reads the envelop and understands whats inside before opening.
Consequently as this abuse of a useful tool affected browsers and servers, it meant the heavy weight companies came together to agree on the approach to handle it.
The solution was a new header called “X-Frame-Options”. The server writes this extra piece of information on the outside of the envelope.
If the server does not supply an X-Frame-Option then it is not set and the browser can draw this content in iFrames.
Furthermore when the server sets the header as “deny”, browsers do not draw it in any iFrame, no matter what.
Adjusting to the challenges
The technical term amongst security experts became “Clickjacking”. The process is widely known and detailed by various security sites.
The browser responding to this header wasn’t always possible. Browsers only did this check from around 2009 / 2010 onward.
Why not ban iFrames completely?
Yet some people do want to use iFrames. This is a great way to share their brand.
YouTube and Wikipedia allow you to embed their videos and their articles in your website, they don’t mind iFrames and you using their web pages.
Sameorigin iFrames
Facebook show some Ads using iFrames. So another option is available.
“sameorigin” says, yep, this can be drawn in an iFrame. However the URL must have the same domain name.
So if the frame is on facebook.com and the page in the iframe is also on facebook.com then it will draw fine
Here is an invisible iframe as the width is 0 and height is 0. Embedded on the homepage of Facebook it collects data for Facebook.
The src of the iFrame is on the same server / domain as facebook.com, therefore allowed.
WhereWeLearn and iFrames
WhereWeLearn uses iFrames to deliver material but we recognise the pros and cons of iFrames.
So when the Educator adds a URL to the system as a Material, the engine of WhereWeLearn contacts that webpage and asks… “is your X-Frame-Option set?”
Depending on the response dictates how WhereWeLearn responds automatically.
WhereWeLearn intelligently sets the best option for you based on the URLs response when you add the material.
- Firstly if not set, WhereWeLearn, draws the content in an iFrame on the page. (True)
- Set to Deny? then WhereWeLearn, draws a button on page that allows the user just open a new tab in the browser with this page.
- Same? [sameorigin] then WhereWeLearn can’t draw it, so draws the button like Deny.
- Then again, the author may just want to force it not to be in the iFrame, so the False option is an override which forces the button to appear.
However if the author sets the option to True and the X-Frame-Option does not allow it, it will not draw properly.
iFrames are here to stay. Used properly they are a very powerful tool. WhereWeLearn is a good example of where iFrames can be used positively and worked with.
