5 ms·

Chrome's geolocation fails daily due to API limit

117 points by zspitzer 9y ago

Flammy 9y ago
Heh, so Google's own projects run into Google rate limits too.
- Scaevolus 9y ago
  Rate limits are how services prevent even legitimate clients from accidentally destroying them!
  - blaisio 9y ago
    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.
xpaulbettsx 9y ago
https://www.chromium.org/developers/how-tos/api-keys https://www.chromium.org/developers/how-tos/api-keys
- wehere1 9y ago
  you posted this in the chromium thread too and ... it's not relevant
  - berg43w2t3t 9y ago
    I think it might be relevant, this seems to indicate that google is hardcoding their API keys in the shipped chrome binaries. These exceeded, and broke functionality in the app. This seems like a bad security practice and it is very relevant to call it out here.
    - NateyJay 9y ago
      There's really no practical alternative but to ship binaries with baked in API keys. Maybe you dynamically provision API keys, but the binary needs a baked in permission to access that API to start with...
      - captn3m0 9y ago
        so every release goes out with its own API key?
    - dbbk 9y ago
      Well, they're obviously going to have to hardcode something into the binary, I think you're imagining an issue that doesn't exist.
- mastax 9y ago
  Interesting... if you make a chromium derivative, you need to pay for user's google API access. Or replace them with something else.
gondo 9y ago
does this mean that technically (not legally) one can extract API credentials form chromium/chrome and use them in other project?
- KekDemaga 9y ago
  You can do that for practically any API you can imagine if you are creative enough.
  - gondo 9y ago
    i don't understand what do you mean. how can i do that? f.e. how would i do that with AWS API? the thing with chromium is: it is open source (you can find the credentials), it is meant to be used on any computer via any IP (you can't whitelist API requests)
    - ktta 9y ago
      >the thing with chromium is: it is open source (you can find the credentials) No, you have to get your own API keys via Google Cloud API Manager before building chromium. That's the reason why Chromium on Windows doesn't let you log in. I presume Chromium on linux distros will use an API key of the package maintainer. Also, in most closed source binaries (which chrome is a part because it has binary blobs not present in Chromium - see Google Cast, etc) you will have to sign a EULA where you agree to no disassemble and use that API key, so doing so is illegal too.
    - Gaelan 9y ago
      Chromium != chrome. It doesn’t add much security, but I bet the API keys are added as part of whatever process google uses to build chrome from the chromium source
  - jpatokal 9y ago
    You can apply on server-side restrictions on Google API keys: https://developers.google.com/maps/documentation/javascript/get-api-key#key-restrictions https://developers.google.com/maps/documentation/javascript/... https://developers.google.com/maps/faq#keysystem https://developers.google.com/maps/faq#keysystem The most secure approach is to get a premium plan with a cryptographic key and sign your requests serverside. This is complicated/not feasible for some APIs and client-side applications though. Disclaimer: Googler, used to work on Google Maps, nothing to do with Chrome.
zspitzer 9y ago
I've been told this has been addressed. If you want to test POSITION_UNAVAILABLE, IE 11 always fails after the first request. For anyone interested, the location emulation in Chrome Dev Tools is also buggy, Chrome also fires two callbacks on failure, TIMEOUT and POSITION_UNAVAILABLE https://bugs.chromium.org/p/chromium/issues/detail?id=542923 https://bugs.chromium.org/p/chromium/issues/detail?id=542923
- ncr100 9y ago
  Comment 9 by scheib@chromium.org, Today (33 minutes ago) Status: Started Thank you for reporting. We have adjusted API limits that should ease this immediately. Our monitoring is clearly not sufficient and we will follow up with process improvements to avoid this recurring.
spaniard_dev 9y ago
I'm almost sure this also happens with the translation API. Some days when I try to translate websites I get 403 errors and I have to wait for some time until I can use the feature again.

117 points by zspitzer 9y ago

Flammy 9y ago

Heh, so Google's own projects run into Google rate limits too.

Scaevolus 9y ago
Rate limits are how services prevent even legitimate clients from accidentally destroying them!
- blaisio 9y ago
  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.

xpaulbettsx 9y ago

https://www.chromium.org/developers/how-tos/api-keys https://www.chromium.org/developers/how-tos/api-keys

wehere1 9y ago
you posted this in the chromium thread too and ... it's not relevant
- berg43w2t3t 9y ago
  I think it might be relevant, this seems to indicate that google is hardcoding their API keys in the shipped chrome binaries. These exceeded, and broke functionality in the app. This seems like a bad security practice and it is very relevant to call it out here.
  - NateyJay 9y ago
    There's really no practical alternative but to ship binaries with baked in API keys. Maybe you dynamically provision API keys, but the binary needs a baked in permission to access that API to start with...
    - captn3m0 9y ago
      so every release goes out with its own API key?
  - dbbk 9y ago
    Well, they're obviously going to have to hardcode something into the binary, I think you're imagining an issue that doesn't exist.
mastax 9y ago
Interesting... if you make a chromium derivative, you need to pay for user's google API access. Or replace them with something else.

gondo 9y ago

does this mean that technically (not legally) one can extract API credentials form chromium/chrome and use them in other project?

KekDemaga 9y ago
You can do that for practically any API you can imagine if you are creative enough.
- gondo 9y ago
  i don't understand what do you mean. how can i do that? f.e. how would i do that with AWS API? the thing with chromium is: it is open source (you can find the credentials), it is meant to be used on any computer via any IP (you can't whitelist API requests)
  - ktta 9y ago
    >the thing with chromium is: it is open source (you can find the credentials) No, you have to get your own API keys via Google Cloud API Manager before building chromium. That's the reason why Chromium on Windows doesn't let you log in. I presume Chromium on linux distros will use an API key of the package maintainer. Also, in most closed source binaries (which chrome is a part because it has binary blobs not present in Chromium - see Google Cast, etc) you will have to sign a EULA where you agree to no disassemble and use that API key, so doing so is illegal too.
  - Gaelan 9y ago
    Chromium != chrome. It doesn’t add much security, but I bet the API keys are added as part of whatever process google uses to build chrome from the chromium source
- jpatokal 9y ago
  You can apply on server-side restrictions on Google API keys: https://developers.google.com/maps/documentation/javascript/get-api-key#key-restrictions https://developers.google.com/maps/documentation/javascript/... https://developers.google.com/maps/faq#keysystem https://developers.google.com/maps/faq#keysystem The most secure approach is to get a premium plan with a cryptographic key and sign your requests serverside. This is complicated/not feasible for some APIs and client-side applications though. Disclaimer: Googler, used to work on Google Maps, nothing to do with Chrome.

zspitzer 9y ago

I've been told this has been addressed. If you want to test POSITION_UNAVAILABLE, IE 11 always fails after the first request. For anyone interested, the location emulation in Chrome Dev Tools is also buggy, Chrome also fires two callbacks on failure, TIMEOUT and POSITION_UNAVAILABLE https://bugs.chromium.org/p/chromium/issues/detail?id=542923 https://bugs.chromium.org/p/chromium/issues/detail?id=542923

ncr100 9y ago
Comment 9 by scheib@chromium.org, Today (33 minutes ago) Status: Started Thank you for reporting. We have adjusted API limits that should ease this immediately. Our monitoring is clearly not sufficient and we will follow up with process improvements to avoid this recurring.

spaniard_dev 9y ago

I'm almost sure this also happens with the translation API. Some days when I try to translate websites I get 403 errors and I have to wait for some time until I can use the feature again.