Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

trufflesecurity.com

Post reply on HN
Print view View original

241–250 of 326 posts

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

#241

Post by Nathanba »

AnthonyMouse wrote: post #237
Nathanba wrote: post #156

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…

it's not an either or, they can easily let me configure any kind of behavior that I want. No cap, a hard cap, a soft cap, a cap that I program with a python script, a cap where I throttle, a cap where I opt in to deleting certain machines to save money. It can all be done. People are complaining because obvious features are not provided. People would not be complaining if they had all the options that we needed to control how to scale resources in response to load, not just technical load but also financial load.

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

#242

Post by [deleted] »

chrisjj wrote: post #187
827a wrote: post #15

Earlier quoted context omitted.

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…

Sheesh. We're in a world where a global Big Tech security team lacks comptetance to run even one high-street locksmith.

[deleted]

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

#243

Post by Ensorceled »

sandrello wrote: post #125

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…

> That would still be a strange use case for what gets called an "API key".

The problem that you, and many people are having in this thread, is that you are typing "API key" but, in your head, you're thinking "private API key". API keys can be secret or public, and many services have matching pairs of secret and public keys (Stripe, Chargify, etc. etc. etc.)

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

#244

Post by Ensorceled »

Dylan16807 wrote: post #129
saagarjha wrote: post #62

Earlier quoted context omitted.

A good writer knows when to use literary techniques.

They work just fine in this post.

Yeah, it's perfectly reasonable device that I often use. I love the circle reasoning being displayed:

  "this sounds like AI"
  "professional writers use this technique"
  "they can't be a professional writer, they're using AI"

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

#245

Post by patmorgan23 »

hluska wrote: post #227
staticman2 wrote: post #206

Earlier quoted context omitted.

Legal fees are not something you are usually legally entitled to. Your attorney can push for whatever illegal thing they can think of, it doesn't mean you will get it.

Under what statute is it illegal to request legal fees?

Requesting and being granted legal fees are two different things.

The default "American rule" is that each party pays their own legal fees, unless there is a relevant fee shifting rule.

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

#246

Post by jetbalsa »

falcor84 wrote: post #200
qudent wrote: post #151

Earlier quoted context omitted.

I think the fact that it is not possible to put hard spending caps on API keys might be ruled illegal by some EU court soon enough, at least when they sell to consumers (given the explosion of vibecoding end-users making some apps). When I use OpenAI, Openrouter etc., I can put 10 $ on my API key, and when the key leaks, someone can use these 10 $ and that's it. With Google, there is no way to do that - there are ext…

> When I use OpenAI, Openrouter etc., I can put 10 $ on my API key, and when the key leaks, someone can use these 10 $ and that's it. On that note, I'll just mention that I had discovered over the last while that when you prepay $10 into your Anthropic account, either directly, or via the newer "Extra usage" in subscription plans, and then use Claude Code, they will repeatedly overbill you, putting you into a negativ…

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.

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

#247

Post by happyopossum »

decimalenough wrote: post #46
warmedcookie wrote: post #4

What's frustrating is that a lot of these keys were generated a long time ago with a small amount of GCP services that they could connect to. (Ex. Firebase remote config, firestore, etc.) When Gemini came around, rather than that service being disabled by default for those keys, Gemini was enabled, allowing exploiters to easily utilize these keys (Ex. a "public" key stored in an APK file)

Gemini API is not enabled by default, a project owner has to go explicitly enable it. The problem described here is that developer X creates an API key intended for Maps or something, developer Y turns on Gemini, and now X's key can access Gemini without either X or Y realizing that this is the case. The solution is to not reuse GCP projects for multiple purposes, especially in prod.

The problem is that developer X did not properly scope the API key when he created it. Yes, separate projects would also stop this, but keys have been capable for ever and creating unrestricted keys is strongly discouraged. Pretty sure you can even set an org policy to prevent someone from doing so…

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

#248

Post by erikerikson »

semiquaver wrote: post #208

This is just embarrassing. It doesn’t even really qualify as a security vulnerability, more like a fatal flaw in the system’s design. I can see why the team pushed back on fixing it, seems like a massive pain. It feels like something that would happen if you outsourced planning to an LLM.

While I completely appreciate the final sentence, the article clearly describes the probable escalation, exposure of confidential information, and other security issues created through the decisions of Google.

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

#249

Post by brookst »

carlmr wrote: post #73
brookst wrote: post #72

Earlier quoted context omitted.

I don’t see it. Imagine for a moment the there is no oversight. Every intern can ship prod code with their own homemade crypto. How do you, in a retail business, agree to accept credentials that anyone can mint for free? I mean obviously it happened. But… this doesn’t even seem like a compliance mistake. It’s a business-level mistake.

If you've never worked in a large corporate environment you don't know how stupid things become. In a perfect bureaucracy nobody thinks.

I work at a Fortune 10.

Things get stupid for sure. But I have never once seen “hey let’s do away with access controls for high-COGS services”.

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

#250

Post by tempest_ »

refulgentis wrote: post #57
decimalenough wrote: post #43

Earlier quoted context omitted.

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

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

I was trying to test the gemini-cli using code assist standard.

To this day I am unable to access the models they say I should be able to.

I still get 2.5 only, despite enabling previews in the google cloud config etc etc.

The access seems to randomly turn on and off and swaps depending on the auth used (Oauth, api-key, etc)

The entire gemini-cli repo looks like it is full of slop with 1000 devs trying to be the first to pump every issue into claude and claim some sort of clout.

It is an absolute shit show and not a good a look.

Post reply on HN