| ▲ | 827a 10 hours ago |
| 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. |
|
| ▲ | decimalenough 9 hours ago | parent | next [-] |
| 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. |
| |
| ▲ | rezonant 8 hours ago | parent | next [-] | | 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. | | |
| ▲ | chrisjj an hour ago | parent | next [-] | | > It didn't work like that for any other service, why should it work that way for Gemini. Artifical Intelligence service design and lack of human intelligence are highly correlated. Who'd have guessed?? | |
| ▲ | edoceo 7 hours ago | parent | prev [-] | | Really? I make multiple GCP projects per app. One project for the (eg) Maps API, one for Drive, one for Mail, one for $THING. Internal corp-services might have one project with a few APIs enabled - but for the client-app that we sell, there are many projects with one or two APIs enabled only. | | |
| ▲ | rezonant 6 hours ago | parent [-] | | If you ever have to enable public OAuth on such a project, you'll need to provide a list of all the API projects in use with the application, and Google Trust and Safety will pressure you to merge them together into a single GCP project. I've been through it. You can do what you're describing but it's not the model Google is expecting you to use, and you shouldn't have to do that. It seems what happened here is that some extremely overzealous PM, probably fueled by Google's insane push to maximize Gemini's usage, decided that the Gemini API on GCP should be default enabled to make it easier for people to deploy, either being unaware or intentionally overlooking the obvious security implications of doing so. It's a huge mistake. | | |
| ▲ | chrisjj an hour ago | parent [-] | | > decided that the Gemini API on GCP should be default enabled to make it easier for people to deploy Like deciding ATM cabinets should be default open to make it easier for people to withdraw cash. No, there must be more behind this than overzealotry. |
|
|
| |
| ▲ | franga2000 7 hours ago | parent | prev | next [-] | | Isn't there a limit to the number of projects you can make and then you have to ask support to increase it? | | |
| ▲ | simoncion 3 hours ago | parent [-] | | There is, yes. The rumor mill suggests that the default limit is 30. At $DAYJOB, we had a (not very special) special arrangement with GCP, and I never heard of anyone who was unable to create a project in our company's orgs [0]. Given how Google never, ever wants to have a human do customer support, I expect a robot will quickly auto-approve requests for "number of projects" quota increases. I know that's how it worked at work. [0] ...with the exception of errors caused by GCP flakiness and other malfunction, of course. | | |
| ▲ | kl4m 2 hours ago | parent [-] | | Many products using the Cloud APIs auto-create projects. I know of AI Studio and Google Script (including scripts embedded in Docs, Sheets, etc) So many organizations have the IAM "Project creator" role assigned to everyone at the org level. I think it's even a default. |
|
| |
| ▲ | refulgentis 8 hours ago | parent | prev [-] | | 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. | | |
| ▲ | StilesCrisis an hour ago | parent [-] | | They started off behind, and have been scrambling to catch up. This means they didn't get the extra year of design-doc hell before shipping, so mistakes were made. |
|
|
|
| ▲ | chrisjj an hour ago | parent | prev | next [-] |
| Sheesh. We're in a world where a global Big Tech security team lacks comptetance to run even one high-street locksmith. |
|
| ▲ | brookst 7 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | Ekaros 5 hours ago | parent [-] | | Maliciously thinking allowing this increase billable. Thus it increases the bottom line and make stock go up... Which is good for vesting... |
|
|
| ▲ | crest 8 hours ago | parent | prev [-] |
| I hope Google has a database with the creation timestamp for every API key they issued. |
| |