Request for feature: thumbnail proxying to avoid mixed content warnings in browsers

[Walter McGinnis]

Happy Friday,

First, some background.

I've spent the last few days wrestling with "Mixed Content Warnings"
when users visit https://chinesecommunity.org.nz/ in Internet
Explorer. The cause is SRC values that are hardcoded http:// (i.e.
Javascript, CSS, or image tags).

I've adjusted the Kete source code and the site content to use either
relative URLs or protocol relative URLs where "http://" was hardcoded
and https was available, but there are some services that are beyond
my control. The main one is the Google Maps API javascript (you can
get the JS over HTTPS, but it breaks on two internal http:// uses)
which I'll probably end up proxying as outlined in
http://jay.gooby.org/post/avoiding-https-mixed-content-warnings.

The other one is DigitalNZ RSS version of the API when it returns
results with thumbnails (thank you for this feature, it is excellent)
and they have the full URL for the image source. I know that many
content providers won't offer a HTTPS version of their URLs for image
thumbnails, so it is impractical to simply replace the URLs with
protocol relative versions.

One option is that I turn off DNZ thumbnails in Kete when the page is
being served under HTTPs, but I think it makes sense for DNZ to
implement a new feature instead.

The feature:

It would be great if the API (I'm most interested in the RSS version)
would provide a service that returns a protocol relative (i.e. just
//) version of the thumbnail hosted by DNZ. Something like this:

DNZ returns "//api.digitalnz.org/media/replay?url=the_original_thumb_url"
# probably with some validation processing, beyond just proxying
the_original_thumb_url

Further background:

Now you might say that this is overkill and that really only pages
that aren't making DNZ requests should be served under HTTPS, but
after the Firesheep debacle many services are moving to only serve
their complete site under HTTPS.

Here's the EFF's thinking on it:
https://www.eff.org/pages/how-deploy-https-correctly

What do you think?

Cheers,
Walter

[Stuart A. Yeates]

I agree that DNS should be able to do https. If you're looking to
motivate librarians to this cause, you may want to read
http://www.ala.org/ala/aboutala/offices/oif/statementspols/ftrstatement/freedomreadstatement.cfm
which is a touch-stone in this area and far better known among
librarians than the EFF I suspect.

cheers
stuart