alt Hacker NewsYeah 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.
Replies
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.
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.
I hope Google has a database with the creation timestamp for every API key they issued.
Sheesh. We're in a world where a global Big Tech security team lacks comptetance to run even one high-street locksmith.