4 ms·

It's pretty weird in this case. Google serves web pages and adds rate limits to keep people from taking their servers down (or, at least, from making them use

It's pretty weird in this case. Google serves web pages and adds rate limits to keep people from taking their servers down (or, at least, from making them use way more servers than normal, which would make providing the services too expensive, which would force them to take the servers down). If their servers go down, then users can no longer use their web pages properly. But, here we see the rate limiting is itself keeping users from using web pages properly. So the rate limiting is effectively disabling services even though the whole point of the rate limit is to protect them! I wonder if there are other feedback loops in Chrome where, in order to be able to keep serving web pages, Google could sometimes accidentally prevent Chrome users from viewing web pages?

mseebach 9y ago
This is not a feedback loop, nor is it representative of any kind of systemic failure. The geocoding API is an external dependency, and in implementing their integration of this dependency, the Chromium developers failed to respect the contract of the dependency, specifically to secure a sufficiently large quota, and this resulted in a bug. This is amusing and all because it comes from the same company, but Google is a huge company, and it's unlikely that the Chromium team's relationship with the geolocation API team is that much different than any other enterprise customers'.
londons_explore 9y ago
The API key built into Chrome isn't exactly super secure - anyone can reverse engineer the binary to extract it. One might imagine that an evil user has done exactly that, and started sending billions of requests to the API, exhausting the quota. It is better to have the quota exhaust, effectively blocking all Chrome users, than have the service fail due to overload which would block all users (for example, maps.google.com, and iOS and Android) The long term fix is probably to issue temporary per-user keys to each signed in user, so that anyone who misuses the key will only block themselves. Since Chrome allows non-signed in users, there will be considerable complexity and difficulty with that approach.

mseebach 9y ago

This is not a feedback loop, nor is it representative of any kind of systemic failure. The geocoding API is an external dependency, and in implementing their integration of this dependency, the Chromium developers failed to respect the contract of the dependency, specifically to secure a sufficiently large quota, and this resulted in a bug. This is amusing and all because it comes from the same company, but Google is a huge company, and it's unlikely that the Chromium team's relationship with the geolocation API team is that much different than any other enterprise customers'.

londons_explore 9y ago

The API key built into Chrome isn't exactly super secure - anyone can reverse engineer the binary to extract it. One might imagine that an evil user has done exactly that, and started sending billions of requests to the API, exhausting the quota. It is better to have the quota exhaust, effectively blocking all Chrome users, than have the service fail due to overload which would block all users (for example, maps.google.com, and iOS and Android) The long term fix is probably to issue temporary per-user keys to each signed in user, so that anyone who misuses the key will only block themselves. Since Chrome allows non-signed in users, there will be considerable complexity and difficulty with that approach.