# Friday, 28 October 2011

If you use Internet Explorer, lately around the web you might have been receiving a LOT of "Only secured content is displayed"  messages such as the one below.


After you get such a message, the site might not work properly, or you might not be able to interact with certain features on the site.

Why is this happening? Well, the culprits include, but are not limited to...


Yes.. the simple LIKE type buttons.

In order to better protect the privacy of their users, the scripts for these buttons are now being retrieved via HTTPS instead of deciding which to use depending on the protocol the source page is using.  This means there's now a mixed scheme content scenario that's occuring.

I'll try to explain it in simple terms. If you visit a website using the url of


And that page chooses to draw in content from another source using HTTPS such as


The page now contains content from a secured location as well as an insecured location. And IE treats that as a potential privacy concern, and hence pops up the message you see at the top of this article.

The Solution

There'll be people who argue that it's GOOD that IE decides to warn users about such mixed mode content, and there'll also be people who argue that IE is BAD for not allowing it since the other browsers have no such problems (I'll get to them later) But... if you want to get rid of these warnings (which might be a good or bad thing) here's what you do.

Go to Internet Options (Under the GEAR menu for IE9, Under Tools menu for older versions)


Select the Security tab, then hit the Custom Level button.


In the giant list that appears find Display mixed content and change it from Prompt to Enable


Click on the OK button to accept the changes and you'll be rid of the mixed mode warnings.

What about the other browsers?

Now... what about the other browsers how do they handle mixed mode content?

Google Chrome takes a more conservative approach to it's warnings in the sense that if your main page is viewed using HTTP and then gets something from a more secured HTTPS connection, it won't complain about anything since the extra content is MORE secure than the original content. But... if you're on a HTTPS page, which then calls for something from a HTTP source such as images, plugins, widgets, etc. etc. you get the warning below.


(Site identity removed because I'm not implying that the site isn't secure and I don't want people to get that idea) Clicking on the broken lock presents a non intrusive indicator (crossed out https) to show that everything the site is showing isn't fully encrypted. Even comes out with a explanation of the current mixed mode situation. Of course a normal user probably couldn't care less about how much of the page they're viewing is encrypted. And thus we come to Firefox's method of handling mixed scheme content.

It's what I'd like to call the "Users don't give a damn about this stuff anyway!" method.


First of all there's NO indication on the address bar that anything is amiss with the page at all when a HTTPS page contains mixed mode content from a less secured source. Clicking on the help indicator would give you some information, but as there's no broken HTTPS indicator like in Chrome, a user would have no incentive to click it and find out if anything's amiss

Ok... So there is one DIFFERENCE between a mixed content page, and a fully secured page


A fully secured page show's it's domain name in the address bar, but how many users would know that if it wasn't pointed out to them?

Of all the 3 browsers and how they deal with mixed scheme content. I must say I personally prefer Google Chrome's non intrusive method of telling users about mixed scheme content. Though the crossed out HTTPS icon might scare users into thinking the page is not secured.

Friday, 28 October 2011 16:55:55 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  | 
# Monday, 24 October 2011

I was preparing my Silverlight XNA hybrid application in Windows Phone 7.5 Mango presentation demo project for TechInsights 2011 (Sign up now!) When I hit a problem, The ContentManager  threw an exception whenever it was time to load an asset. Specifically it was a KeyNotFoundException.

After some digging around it seems like there's a problem with the project template itself. (!) The gist of it is, in the App.xaml.vb file. Under the InitializeXNAApplication function. You'll find the line below :-

If obj Is GetType(IGraphicsDeviceService) Then

This line is supposed to find an obj that implements IGraphicsDevicesService and add it into a list of services. But the code is wrong, this line needs to be changed to:-

If TypeOf obj Is IGraphicsDeviceService Then

In order to work properly. This ONLY affects the Visual Basic Windows Phone Silverlight And XNA Application project template.

The main question I'd like to ask is how the heck did this error make it out to the release SDK? Since I do remember everything working during the CTP. Also, even Microsoft's own VB code samples for this project type uses the correct method call.

Monday, 24 October 2011 10:09:00 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  |