Here’s a list of screenshots of all the relevant browsers displaying normal valid (DV) certificate-encrypted site:
IE6, IE7, IE8, IE9, IE10, IE11, Win7 Firefox, Win7 Chrome, OS X Chrome, OS X Safari, OS X Firefox, iOS6 Safari, iOS7 Safari, android 4 webkit, android 4 chrome
All of them have a padlock icon of some sort, which tech-savvy users associate with secure connection.
But things change when a browser detects that some content on the https secure page is served from http. The situation when the page is loaded via a secured HTTPS connection but tries to load some resources from an unsecure connection has a special name — ”mixed security content”.
There’s an in-progress spec explaining what should be considered mixed security content and also a W3C recommendation on how agents should behave when they see mixed security content appearing on the page.
With regards to the certificate type, mixed security content case is handled differently for EV and DV (commonly used) certificates:
EV — a page is considered not TLS-validated if it has an EV cert and the page tries loading any mixed content: images, scripts, iframes, video, objects; the EV green bar disappears.
non-EV — mixed security content is divided into two types: passive and active. Passive mixed security content usually includes images, video, objects (flash included), audio — everything that can’t change the DOM. Browsers load passive mixed security content though this fact is indicated to the user, usually by showing ”insecure mixed content” icon somewhere in the address bar or elsewhere in the UI. And the active mixed security content (usually all the content that can modify DOM — scripts, stylesheets, iframes, fonts) is not loaded by most of the browsers and a security warning is usually dumped to the console log.
To illustrate the behaviours of all the modern browsers I prepared a table of testcases and resulting screenshots (older IE6-7-8 behaviour is described below the table):
| # | resource | IE9 | IE10 | IE11 | Firefox 30 | Chrome 35 | Safari 7 |
| 1 | Iframe | No | No | No | No | No | Yes |
| 2 | Script | No | No | No | No | No | Yes |
| 3 | Stylesheet | No | No | No | No | No | Yes |
| 4 | Font | No | No | No | No | Yes | Yes |
| 5 | js XHR | No | No | No | No | Yes | Yes |
| 6 | Flash | No | No | No | Yes | Yes | Yes |
| 7 | https flash + http xhr | Yes | Yes | Yes | Yes | Yes | Yes |
| 8 | Video | Yes | Yes | Yes | Yes | Yes | Yes |
| 9 | Audio | Yes | Yes | Yes | Yes | Yes | Yes |
| 10 | Image | Yes | Yes | Yes | Yes | Yes | Yes |
General notes:
Safari seems to not care about the type of mixed security content, it loads any mixed security content regardless of its type though it removes the padlock icon from the progress bar (almost always, see below for details)
similarly to Safari, IE up to version 8 (inclusive) does not differentiate between active and passive mixed security content; it shows a modal dialog (asking if user wants to load only secure content or not) upon detecting any mixed security content in the page: IE6, IE7, IE8. If user chooses to load only secure content, mixed security content is blocked and the padlock icon is retained: IE6 IE7 IE8; if the user prefers to allow loading mixed security content, padlock icon is removed and mixed security content is loaded, rendering the view similarly to normal http pages: IE6 IE8 IE7
IE starting from version 9 started handling different types of mixed security content differently based on its type: passive mixed security content is loaded though the padlock icon is removed, active mixed security content is blocked and a special UI informational popup is shown. Chrome and Firefox could not lag behind, and so they followed IE: first Chrome and two years later Firefox started distinguishing passive and active mixed security content, both browsers are now able to detect when mixed security content is loaded and block what they consider active mixed security content; passive mixed security content is loaded with a corresponding UI change. To me, Chrome padlock UI looks cleaner and saner — when passive mixed security content is loaded, padlock icon still persists but a yellow warning sign is shown on top. Both Firefox and Chrome behave similarly on OS X and Windows.
Chrome persists user’s choice to load active mixed security content for the site: if user chooses to load HTTP iframe on one page, HTTP-served script will be loaded on another page. Neither IE nor Firefox persist the user’s choice (which makes sense to me). Safari has nothing to persist as it always loads the content.
iOS Safari doesn't have any "insecure mixed content" icon, it just doesn't show the padlock icon at all if any mixed security content is present on the page while loading all the resources.
Test-specific notes:
#1, #2, #3 (iframes, scripts, stylesheets). As Safari doesn’t differentiate between types of mixed security content, it simply removes the padlock icon and loads the content. IE9, IE10, IE11, Firefox and Chrome all consider HTTP-based iframe / script / stylesheet on an HTTPS page active mixed security content and therefore block the content and render the padlock icon. All these browsers render additional UI elements which allow user to explicitly allow loading blocked content. If a user chooses to unlock insecure content, padlock icon is removed and the page ”looks” insecure (screenshots: Chrome/Firefox/IE9/IE10/IE11).
#4 (Fonts). Same behaviour in all browsers as for the previous case (iframe/scripts/stylesheets), but for some reason Chrome considers fonts passive mixed security content and behaves correspondingly — loads the font and displays notification icon on top of the padlock.
#5 (js-XHR to HTTP) IE9 does not support cross-domain XHR, XDomainRequest is used instead, which will block any requests to HTTP resource from a HTTPS page. IE10 started supporting CORS-enabled XHR, but both IE10 and IE11 block CORS XHR requests to the HTTP page with a simple ”access denied” message in the console log. Safari follows its usual procedure — loads the content but removes the padlock icon, Firefox considers XHR to a HTTP active mixed security content and blocks it with its usual warning icon, Chrome considers AJAX passive mixed security content, loads the content and adds its usual passive mixed security content informational triangle on top of the padlock icon.
#6 (flash). IE9, IE10 and IE11 consider flash active mixed security content, other browsers treat it as passive mixed security content; so IE9+ blocks the flash object from downloading, and there’s a specific bug easy to spot on the screenshot — the loading spinner never stops rotating. Which, combined with the IE’s usual ”Only secure content is displayed” dialog makes http-based flash on HTTPS pages almost unusable.
#7 (flash-XHR to HTTP) IE9, IE10, IE11 and Safari do not consider HTTP-XHR from flash as mixed security content. Both IE and Safari retain the padlock icon as if all requests were made through a secured connection. Even the console log is empty of warnings or errors. To me this quite clearly seems to be a security hole.
#8, #9, #10 (audio, video, images). IE9, IE10, IE11, Firefox and Chrome consider images, HTML5 audio and video as passive mixed security content and treat it correspondingly — load the content and change the UI (IE removes the padlock icon, Firefox replaces it with informational triangle icon, Chrome puts informational icon on top of the padlock icon). Safari has interesting and non-consistent behaviour here: it treats images normally (displays them and removes the padlock icon), but for some odd reason it treats HTML5 audio and HTML5 video loaded via HTTP as normal secure content, it doesn’t even drop the padlock icon.Either Safari developers thought that images are more insecure than audio or video somehow or, more likely, Safari<->Quicktime link lacks notion of the mixed security content concept (Quicktime plugin is used by Safari to handle all audio/video download).
The tests were done for Google Chrome of version 35, Apple Safari 7.0.5, and Mozilla Firefox 30.
