Hacker News new | past | comments | ask | show | jobs | submit login
HN Petiton: Get Google to support SSL on all of its APIs
72 points by tav on Dec 6, 2010 | hide | past | favorite | 21 comments
As a security-conscious developer, I have started switching over my apps to be served over only SSL. Whilst this might end up being a costly exercise (e.g. having to proxy images in user generated content), the added privacy and security for my users is justification enough for me.

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!




As I've noted before, the issue with HTTPS is not one of server cost any more. However, I am aware of several Google services that are not available over HTTPS. Maps and AdSense are the ones which I'm familiar with and, if people are having issues with others, please let me know.

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-...


Google Charts API does not work over HTTPS. It redirects you to Google's homepage after showing a certificate warning.

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...


I got Chart API fixed, although on a different hostname: http://www.imperialviolet.org/2010/11/29/charthttps.html

The deal with encrypted.google.com is explained here: http://googleenterprise.blogspot.com/2010/06/update-on-encry...



Adam, nice work on getting Charts on HTTPS!

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...


A major pain point for me is not being able to use https with my App Engine apps that have their own domain names: http://code.google.com/appengine/kb/general.html#httpsapps

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.


I'm writing an https frontend in Go which proxies to App Engine. It increases the bandwidth bill slightly, but means that you can take full advantage of the App Engine APIs. You can see the work in progress here:

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.


FWIW, it's the top item on their roadmap:

http://code.google.com/appengine/docs/roadmap.html


The Google Charts API was updated with SSL support only a week ago:

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.


Is it in beta? Doesn't seem to work now... and your link has no chart but an img placeholder in the page.



thanks! seems to work when requested directly, but not integrated / within HTML / jquery etc.


Hmm. That's something that I'll have to look into. It should be served the same as anything else.


try it with some sort of dynamic data, one you never http-request it before (talking about the page-embedded scenario). i can't get it to work, even in different environments/networks. it always works when the chart is requested directly :(


On a related note, it would be great to have a listing of all the service providers who do have comprehensive support for open APIs over SSL. Here are a few to get the list started:

* Bing Maps

* Facebook

* GitHub


While I surely see the value of SSL, it also brings me a bad user experience, full of redirects, and maybe for some people slowdowns and mixed content warnings. But worst of all is that Safari does not remember secures sites at all. So forget about auto-completion.


Please fix typo in the header: HN Petition. Thanks!


Good catch, thanks! Unfortunately, it's now too late for me to edit, but perhaps someone with appropriate powers can make the correction?


Hopefully, as a security-conscious developer, you are also looking at alternate solution providers to reduce the potential risk of making all your info available to Google.


I think it will be expensive for Google to provide SSL on all its APIs unless clients are willing to pay.


Not true according to Google:

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...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: