Live data from Hacker News

Google API keys weren't secrets, but then Gemini changed the rules

trufflesecurity.com

261–270 of 326 posts

Re: Google API keys weren't secrets, but then Gemini changed the rules

#261
post #256

Earlier quoted context omitted.

I'm spitballing here, but I suspect that (same with AWS) google uses post processing for billing, they run a job that scrapes the states THEN bills you for that. instead of the major AI companies are checking billing every API request coming in.

Yes, you are on the money. A cloud service provider needs to maintain reliability first and foremost, which means they won't have a runtime dependency on their billing system. This means that billing happens asynchronously. You may use queues, you may do batching, etc. But you won't have a realtime view of the costs

>they won't have a runtime dependency on their billing system

Well, that makes sense in principle, but they obviously do have some billing check that prevents me from making additional requests after that "final query". And they definitely have some check to prevent me from overutilizing my quota when I have an active monthly subscription. So whatever it is that they need to do, when I prepay $x, I'm not ok with them charging me more than that (or I would have prepaid more). It's up to them to figure this out and/or absorb the costs.

Re: Google API keys weren't secrets, but then Gemini changed the rules

#263

Earlier quoted context omitted.

Isn't there a limit to the number of projects you can make and then you have to ask support to increase it?

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 work…

As long as you are over a certain spend. I started something for my own project and went to apply the recommended architecture, which does not work without a quota increase. As it was from a fresh account, the email was we won't look at this until you spend or pre spend so much money. Frankly, for a trail period when evaluating at prior enterprises, that would have made me just say no to their cloud. One expects that the recommended architecture can be deployed in the trial run without hoops.

Re: Google API keys weren't secrets, but then Gemini changed the rules

#264

This 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'll riff off this and say that even Google in its heyday was strangely uneven from product to product. Some products were amazing, still pretty dang good. Some products were released in a mess, abandoned nearly from the start, or driven into the ground with seemingly very little competence driving them. It always felt like Google had a bit of a darker side lurking as far as just getting basics wrong product to product / team to team.

Re: Google API keys weren't secrets, but then Gemini changed the rules

#265
post #114

Someone on the Google subreddit did report getting a 80k bill yesterday from a Gemini key. I’m very careful with Google and co since they’re so intent on infinite scaling access to your wallet

The article mentions "Building software at Google's scale is extraordinarily difficult...", which I've seen many times before when one or another of these big corporations has a serious security flaw. If a company like Google, with its ability to attract the best of the best, cannot handle the complexity of security and safety with SaaS/PaaS products, at what point do we say that perhaps this sector needs much more o…

Oversight by whom?

Re: Google API keys weren't secrets, but then Gemini changed the rules

#266

Earlier quoted context omitted.

let's hope it happens soon, I'm pretty sick of this reality where companies get to charge you whatever they want and it's designed to always be your fault

You're configuring something that costs money (electricity, hardware, real estate) to provide. Either it's "pay as you go" or you have a flat rate and a cap. If you have a cap and then your thing hits the front page and suddenly has 10000% more legitimate traffic than usual, and you want the legitimate traffic, they're going to get an error page instead of what you want. If there is no cap, you're going to get a larg…

The main thing Google is screwing up is that if my API key somehow leaks and I end up with extremely out of line billing at Microsoft, I will be on the phone with a customer representative as soon as we or they notice something weird happening and a solution will be found.

Google will probably have me go through five bots and if, by some kind of miracle, I manage to have a human on the phone, they will probably explain to me that I should have read the third paragraph of the fourth page of the self service doc and it's obviously my fault.

Re: Google API keys weren't secrets, but then Gemini changed the rules

#267

This 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?

Google does have a security review process on literally everything it launches. Which is what makes this so notable. Did the security review not catch this, or did they choose to launch anyways because it was too hard to fix and speed was of the essence?

Have you been on these reviews? The idea that the review will catch a misuse of the key generation infrastructure is a bit over the top.

Re: Google API keys weren't secrets, but then Gemini changed the rules

#268

This is mind-blowing, and it defies all security common sense. Changing global API keys permissions? Come on! We’re accustomed to seeing issues like this from Redmond but didn’t expect it from Google.

It shows their red teams were preoccupied with something else. Even the primary rejection of this issue by G themselves shows some serious ignorance.

Re: Google API keys weren't secrets, but then Gemini changed the rules

#269

Earlier quoted context omitted.

let's hope it happens soon, I'm pretty sick of this reality where companies get to charge you whatever they want and it's designed to always be your fault

You're configuring something that costs money (electricity, hardware, real estate) to provide. Either it's "pay as you go" or you have a flat rate and a cap. If you have a cap and then your thing hits the front page and suddenly has 10000% more legitimate traffic than usual, and you want the legitimate traffic, they're going to get an error page instead of what you want. If there is no cap, you're going to get a larg…

Imagine the outrage here, when a company credit card expires and the cloud provider terminates all their instances, deletes all your storage and blob backups?

Re: Google API keys weren't secrets, but then Gemini changed the rules

#270
post #15
post #6

> 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…

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.

Post reply on HN