Comment by devsda
3 days ago
> Leaked key blocking. They are defaulting to blocking API keys that are discovered as leaked and used with the Gemini API.
There are no "leaked" keys if google hasn't been calling them a secret.
They should ideally prevent all keys created before Gemini from accessing Gemini. It would be funny(though not surprising) if their leaked key "discovery" has false positives and starts blocking keys from Gemini.
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 Language API grant from every API key ever issued.
This is going to break so many applications. No wonder they don't want to admit this is a problem. This is, like, whole-number percentage of Gemini traffic, level of fuck-up.
Jesus, and the keys leak cached context and Gemini uploads. This might be the worst security vulnerability Google has ever pushed to prod.
The Gemini API is not enabled by default, it has to be explicitly enabled for each project.
The problem here is that people create an API key for use X, then enable Gemini on the same project to do something else, not realizing that the old key now allows access to Gemini as well.
Takeaway: GCP projects are free and provide strong security boundaries, so use them liberally and never reuse them for anything public-facing.
Imagine enabling Maps, deploying it on your website, and then enabling Google Drive API and that key immediately providing the ability to store or read files. It didn't work like that for any other service, why should it work that way for Gemini.
Also, for APIs with quotas you have to be careful not to use multiple GCP projects for a single logical application, since those quotas are tracked per application, not per account. It is definitely not Google's intent that you should have one GCP project per service within a single logical application.
6 replies →
I’m usually client side dev, and am an ex googler and very curious how this happened.
I can somewhat follow this line of thinking, it’s pretty intentional and clear what you’re doing when you flip on APIs in the Google cloud site.
But I can’t wrap my mind around what is an API key. All the Google cloud stuff I’ve done the last couple years involves a lot of security stuff and permissions (namely, using Gemini, of all things. The irony…).
Somewhat infamously, there’s a separate Gemini API specifically to get the easy API key based experience. I don’t understand how the concept of an easy API key leaked into Google Cloud, especially if it is coupled to Gemini access. Why not use that to make the easy dev experience? This must be some sort of overlooked fuckup. You’d either ship this and API keys for Gemini, or neither. Doing it and not using it for an easier dev experience is a head scratcher.
3 replies →
I was exploring this today and just clicked on the "maps" Platform or APIs & Services to just explore and it immediately popped up a screen with "This is your API key for maps to start using!" without my input.
It sent me to a url: https://console.cloud.google.com/google/maps-apis/onboard;fl...
which auto-generated an API key for me to paste into things ASAP.
---
Get Started on Google Maps Platform You're all set to develop! Here's the API key you would need for your implementation. API key can be referenced in the Credentials section.
Isn't there a limit to the number of projects you can make and then you have to ask support to increase it?
4 replies →
Everytime someone proposes protobuf as an rpc format, I respond “Hell no! There’s no support for protocol versioning.”
Of course, I bring this up because they could just version their API keys, completely solving this problem and preventing future ones like it.
Versioning data formats is wrongthink over there, so I’m guessing they just… won’t.
Does JSON have support for protocol versioning?
1 reply →
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.
Maliciously thinking allowing this increase billable. Thus it increases the bottom line and make stock go up... Which is good for vesting...
Sheesh. We're in a world where a global Big Tech security team lacks comptetance to run even one high-street locksmith.
I hope Google has a database with the creation timestamp for every API key they issued.
You can see the creation date even on the GCloud dashboard. But this information isn't helpful in recovering from this issue, if they're interested in recovering correctly, because there's no guarantee that even keys created before the launch of Gemini didn't have Gemini access added to the keys intentionally. There are also likely public keys created after the launch of Gemini that also erroneously received the Gemini grant. The key creation date is ultimately useless; what it comes down to is whether the key's usage is intentional or malicious, which is impossible for Google to determine without involving the customer.
If there's one thing Google is good at, it's logging.
I think Google has a database with everything. EVERYTHING.