Google Restricts Autocomplete API
Written by Ian Elliot   
Monday, 27 July 2015

As the world argues over SDKs and copyright, Google has decided to make clear that its APIs are for it to control. If you have discovered how to use the Autocomplete API then it is time to find another way to do the same job. Google is going to stop you using the unpublished API on August 10th. 

Of course you shouldn't use unpublished APIs - but the temptation to use them is overwhelming. You can more or less get a free lunch because you don't have to implement your own server doing the same job. Of course, if you are on the other side of the fence and random people are using your API, then you might just consider it stealing. After all, you have to pay for the server and the bandwidth and you aren't getting anything back from the programs freeloading on your service. 

With Google Autocomplete the situation is even more tempting. Autocomplete is intended to be used with search and if you want to know the sort of words people are searching for most often just enter the start and see what the Autocomplete API offers you. That is, Google Autocomplete can provide information that is specific to the Google search engine that you just can't get any other way. So it's hardly surprising that it was reverse engineered and made use of. 

As the Google Webmaster Central Blog states:

"We built autocomplete as a complement to Search, and never intended that it would exist disconnected from the purpose of anticipating user search queries. Over time we’ve realized that while we can conceive of uses for an autocomplete data feed outside of search results that may be valuable, overall the content of our automatic completions are optimized and intended to be used in conjunction with web search results, and outside of the context of a web search don’t provide a meaningful user benefit."

So it seems that Google isn't really upset that programmers are making use of its servers without permission, but it is upset that autocomplete is being used for search engine optimization. As a result it has decided to shut down the operation:

"In the interest of maintaining the integrity of autocomplete as part of Search, we will be restricting unauthorized access to the unpublished autocomplete API as of August 10th, 2015. We want to ensure that users experience autocomplete as it was designed to be used -- as a service closely tied to Search. We believe this provides the best user experience for both services."

There is also the suggestion that if you still want to make use of the API you should switch to Google Custom Search Engine, which means you might be able to use the autocomplete, but not in any way disconnected from search. So this isn't really an alternative. 

spookygoogle

One interesting question is how is Google going to shut the API down?

Securing a "public"API is very difficult. If you want to offer an API to a set of registered users then you can issue tokens tied to domains or IP addresses and hence control access. You only allow access when a token is presented to your server from the right domain or IP. 

This isn't foolproof, but it sort of works. Now consider the problem of restricting access to the Autocomplete API which is accessed on the Google search page from any browser. You can't restrict access using a token and you can't tie a token to a domain - the user isn't registered. All you can do is to try to confirm that the API request is coming from your web page and while this is possible it is very easy to subvert - browser automation is all you need

webmasters

 

No details of how Google plans to restrict access to the Autocomplete API are given and it will be interesting to see how it goes about this difficult problem. This might be an easy thing to promise/threaten, but much more difficult to deliver. 

 

Banner


GTK 4 Released
07/01/2021

A major new version of GTK has been released with improvements to the internal design and an improved application programming interface (API). Support has been added for OpenGL and Vulkan hardware dra [ ... ]



Veracode Reveals Security Flaws
12/01/2021

Three-quarters of applications have some sort of security flaw, although high-security flaws are found in only a quarter. PHP is the programming language with the highest prevalence of flaws while Pyt [ ... ]


More News

 

square

 



 

Comments




or email your comment to: comments@i-programmer.info

 

Last Updated ( Monday, 27 July 2015 )