Live data from Hacker News

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

trufflesecurity.com

211–220 of 326 posts

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

#211
post #61
post #36

> Retroactive Privilege Expansion. You created a Maps key three years ago and embedded it in your website's source code, exactly as Google instructed. Last month, a developer on your team enabled the Gemini API for an internal prototype. Your public Maps key is now a Gemini credential. Anyone who scrapes it can access your uploaded files, cached content, and rack up your AI bill. Nobody told you. Malpractice/I can't…

They should limit the new features to new API keys that explicitly opt-in instead of fucking over every user who trusted their previous documentation that these keys are public information.

Isn't it standard practice to harden permissions on API keys? Like, if I were a bootstrapped startup maybe I'd take shortcuts and let an API key have a * permission but not for anything that could rack up thousands of dollars in bills for the customer. But at googles scale that just seems irresponsible.

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

#212
I think this is making at least some waves in google. I literally just got an email from them with the subject "[Action Advised] Review Google Cloud credential security best practices"

A slew of recommendations, one of them being:

Disable Dormant Keys: Audit your active keys and decommission any that show no activity over the last 30 days.

(Although I don't think this even addresses the underlying issue)

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

#213
post #184

Many people wanted to be able to set a spending limit on google cloud account for many years but they were unable to implement anything, always suggesting a workaround by hosting a Cloud Run function which would remove billing from a project via API https://docs.cloud.google.com/billing/docs/how-to/disable-bi...

I haven't used these budget alerts, maybe they are a pain to implement?

https://docs.cloud.google.com/billing/docs/how-to/budgets

They are still not a spending cap of course.

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

#215

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

> 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 But have you considered it from the companies POV? Charging whatever you like and its always the customers fault is a pretty sweet deal. Up next in the innovation pipeline is charging customers extra fees for something or other. It'll be great!

Healthy, even.

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

#216

Since I've never used them, how could API keys for Firebase or Maps be safe for embedding in client side code? I mean, I get that authentication to the service is performed via other means, but what's the use of the key then? I'm guessing it's just a matter of binding service invocations to the GCP Project to be billed, by first making sure that the authenticated principal has rights on that project, in order to prot…

They’re bound to http Referrer iirc

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

#219

Earlier quoted context omitted.

Public keys are a thing in computing, though? Google Maps has one, even. And Stripe.

It's been a while since I've used stripe but don't their keys start with sk_ for secret and pk_ for public? I like that. Easy to tell if you should keep the key a secret or not.

They do, yeah.

(Although `pk` always freaks me out. Public or private?! Oh, right, the other one's "secret".)

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

#220
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 oversight?

Post reply on HN