> This makes sense. These keys were designed as project identifiers for billing, and can be further restricted with (bypassable) controls like HTTP referer allow-listing. They were not designed as authentication credentials. Can't you just run up a huge bill for a developer by spamming requests with their key? I don't see how this wasn't always an issue?
Google API keys weren't secrets, but then Gemini changed the rules
111–120 of 326 posts
Re: Google API keys weren't secrets, but then Gemini changed the rules
#112Earlier quoted context omitted.
Gemini API is not enabled by default, a project owner has to go explicitly enable it. The problem described here is that developer X creates an API key intended for Maps or something, developer Y turns on Gemini, and now X's key can access Gemini without either X or Y realizing that this is the case. The solution is to not reuse GCP projects for multiple purposes, especially in prod.
You are wrong that increasing projects have no cost; many services have project based costs (Cloud Armour rules cannot be used cross project at the base tier), many services (mostly observeability) degrade significantly cross project, the Google Cloud Console _sucks_ cross project. You are also wrong in saying there are no projects that could reasonably have a safe api key made unsafe by this exploit. One example, a…
[Edit: It's likely that you intended to reply to this comment: https://news.ycombinator.com/item?id=47163147 ]
Re: Google API keys weren't secrets, but then Gemini changed the rules
#113Earlier quoted context omitted.
Yeah its tremendously unclear how they can even recover from this. I think the most selective would be: they have to at minimum remove the Generative Language API grant from every API key that was created before it was released. But even that isn't a full fix, because there's definitely keys that were created after that API was released which accidentally got it. They might have to just blanket remove the Generative…
I started replying with a clever approach to layer scopes onto keys… but nope. Doesn’t work. How did this get past any kind of security review at all? It’s like using usernames as passwords.
Re: Google API keys weren't secrets, but then Gemini changed the rules
#114I’m very careful with Google and co since they’re so intent on infinite scaling access to your wallet
Re: Google API keys weren't secrets, but then Gemini changed the rules
#115Re: Google API keys weren't secrets, but then Gemini changed the rules
#116This seems so… obvious? How can a company of this size, with its talent and expertise, not have standardized tests or specs preventing such a blatant flaw?
First of all, Google is a shell of the company it used to be. That said, I’d actually argue there’s an evolutionary explanation behind this where at a certain size, and more importantly complexity, an oversight like this becomes even more likely, not less.
I think this was much less likely to happen without the needless obfuscation. If the only purpose is to identify what project the data is for, and you're trusting the client to report that value, and counseling the client to use that value in a way that trivially exposes it to everyone... what is the point of making it look like cryptic garbage? Just use the account signup name or something, and don't call it a "key" in your query parameters. Keys are supposed to unlock stuff. A name tag is not a key.
Re: Google API keys weren't secrets, but then Gemini changed the rules
#117Re: Google API keys weren't secrets, but then Gemini changed the rules
#118This seems so… obvious? How can a company of this size, with its talent and expertise, not have standardized tests or specs preventing such a blatant flaw?
Security. The final frontier. Where no developer has ever bothered before.
Re: Google API keys weren't secrets, but then Gemini changed the rules
#119[flagged]
Indeed, the key doesn't change. The new capability comes from the new code.
It would not be a re-evaluation of risk, because this is a new project. The evaluation of risk is supposed to come at the moment when the new capability is implemented, and consciously tied to an existing key type, which was previously advertised as non-secret.
Re: Google API keys weren't secrets, but then Gemini changed the rules
#120This seems so… obvious? How can a company of this size, with its talent and expertise, not have standardized tests or specs preventing such a blatant flaw?
First of all, Google is a shell of the company it used to be. That said, I’d actually argue there’s an evolutionary explanation behind this where at a certain size, and more importantly complexity, an oversight like this becomes even more likely, not less.
Isn't that squarely at odds with Google's supposed AI prowess? Is the rot really so severe that their advances in AI (including things they've yet to make public) are insufficient to overcome it? Or are the capabilities of Gemini and AI systems in general being oversold?