Chrome seems to have changed its default security policy again in the last few versions (I am not sure exactly when).
Previously, when the gadget was attempted to be load without SSL, whilst the server was running under SSL, Chrome would present a bar at the top of the screen to ask if this is ok. Until you accepted it the gadget would appear 'broken'. More recently, Chrome is now silently blocking this 'insecure' requests so the gadget immediately appears 'broken', and a user is unable to bypass this (without starting chrome with a special command line flag, which is not a valid workaround). There seem to be 3 different servers involved in loading a gadget successfully: 1) The Wave server hosting the wave 3) The server hosting the gadget xml file 2) Some Google interim server (googleusercontent.com) though which the gadget data seems to be loaded. If (1) has SSL off, (3) has SSL off then the gadget loads If (1) has SSL on, (3) has SSL off then the gadget fails to load (2) always seems to use the same settings as (1) so isn't an issue. I am not sure how we can handle this since (most of the time) the actual gadget xml file is stored on some third party server (which rarely has SSL support enabled). In the mean-time, for the gadgets I am interested in, I will be hacking the jsongadgets.json file (and the gadget xml file) to point to my locally (and securely) delivered xml (and supporting json/css) files. In the longer term, I am uncertain how we should handle this. Thoughts? Ali
