HN Petiton: Get Google to support SSL on all of its APIs
Unfortunately the biggest pain in migrating to SSL are the external API providers — very few of them support or even encourage the use of SSL. And, surprisingly, Google is one of the biggest culprits. I say surprisingly as Google have been very vocal on the use of SSL and have done the most significant real work in reducing the technical overheads of using SSL, e.g. see the awesome work by Adam Langley, an extra-ordinary Googler: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
I've had to resort to various hacks in order to support various Google services, e.g.
* Using server-side API calls instead of cheaper client-side ones.
* Using a custom Flash video player and proxying YouTube videos.
* Proxying all custom domain requests to a Google App Engine app!!
* Using alternative domains, e.g. https://www.google.com instead of http://chart.apis.google.com
I am not happy with any of these hacks, but see no other way around the problem. The rare feature requests on the various Google Groups are often followed by either deadly silence or "not supported" responses from Google.
e.g. http://groups.google.com/group/google-chart-api/browse_thread/thread/95c463d88cf3cfe4
And if you ever want to use Google Maps over HTTPS, then Google would like you to get a Google Maps Premier account which starts at $10,000!! Since when did fundamental security become a premium feature? This seems to be a common trend being adopted by other service providers too, and I'd really like to ask them to rethink SSL as a premium offering. It should be a fundamental feature. Please.
In contrast to Google Maps, Bing Maps from Microsoft does offer an SSL variant:
* https://ecn.dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=7.0&s=1
And, although their API is decent enough, I struggled with switching as the current Bing Map tiles are rather washed out and suffer from usability issues.
In the end, I ended up coming up with a hack for using Google Maps by loading it on a vanilla HTTP domain opened via `window.open` from an HTTPS domain and using `window.postMessage` to communicate between the two windows. This unfortunately won't work in older browsers like IE6, IE7 and Safari 3.x, but works in enough other browsers (IE8+, Firefox 3+, Safari 4+, Chrome) to just about be workable.
I really really really would rather not have to come up with all these workarounds and fragile hacks. And I can't imagine that I am the only developer having to experience this masochism.
In an ideal world, there would be a concerted effort to get all service providers to start offering HTTPS APIs, but Google seem like a good starting point. They've already got great technical support for SSL on their Front End (GFE). And, as can be seen by Google Maps Premier, they already have support for SSL in many apps, and it's clearly a business decision holding back uptake:
e.g. http://code.google.com/p/gmaps-api-issues/issues/detail?id=591
And since a substantial number of Googlers read HN, I figured if we could get enough support here, then there might be some very real chance of change from Google. So, if you, like me, would like to see all Google APIs offered over SSL, then please upvote this article. And if you happen to know Googlers, then please ask them to try and do something about this issue if they can.
Thanks!
23 comments
[ 4.9 ms ] story [ 54.2 ms ] thread* Bing Maps
* Facebook
* GitHub
http://www.imperialviolet.org/2010/11/29/charthttps.html
I hope this is part of a concerted effort to add SSL capability to their various APIs.
If there's one point that we want to communicate to the world, it's that SSL/TLS is not computationally expensive any more. Ten years ago it might have been true, but it's just not the case any more. You too can afford to enable HTTPS for your users.
source: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...
Google is a large company and I can't speak for the Maps nor AdSense teams. They have their own developer relations folks who know far more about their systems than I ever will, but I have chatted with them previously and they are aware of the issue.
In general, Google supports the use of HTTPS [1] and I hope that we can get to the point where it's more widespread.
http://googleblog.blogspot.com/2010/05/search-more-securely-...
Also, https://google.com/ redirects to http://www.google.com/ and https://www.google.com/ redirects to https://encrypted.google.com/.
EDIT: Looks like I am wrong: comment below suggests that HTTPS now works for Charts (http://news.ycombinator.com/item?id=1974878)
EDIT EDIT: Nevermind, it does not work. https://chart.apis.google.com/chart?cht=p3&chd=s:Uf9a...
The deal with encrypted.google.com is explained here: http://googleenterprise.blogspot.com/2010/06/update-on-encry...
Thank you very much.
I understand that Google is a large company. But, with Google Maps in particular it seems to be a business decision rather than a technical one. What can we do to help swing a decision in favour of making HTTPS be part of the public Maps API?
2+ years of comments on http://code.google.com/p/gmaps-api-issues/issues/detail?id=5... hasn't seemed to have had any effect...
Honestly it's pushing me to look for other hosting options (Rackspace, AWS), though I'm really really hoping I won't have to do that. I've invested a lot of effort in various App Engine APIs, and it would be a pity to have to re-do all that work.
https://github.com/tav/ampify/blob/master/src/amp/tentproxy/...
In the next weeks, I'll also be adding optional support for WebSockets which could be linked to a local process for support for custom "comet/long polling" use which App Engine doesn't properly support yet. Email me — tav@espians.com — if you'd like to know more or need any help with the code.
http://code.google.com/appengine/docs/roadmap.html