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 extremely complicated "billing alerts" https://firebase.google.com/docs/projects/billing/advanced-b... , but these are time-delayed e-mails and there is no out of the box way to do the straightforward thing, which is to actually turn off the tap automatically once a budget is spent. The only native way to set a limit enforced immediately is by rate limiting - but I didn't see params which made it safe while usable in my case.

(a legal angle might be the Unfair Contract Terms Directive in the EU, though plenty of individual countries have their own laws that may apply to my understanding. A quite equivalent situation were the "bill shock" situations for mobile phone users, where people went on vacation and arrived home to an outrageously high roaming bill that they didn't understand they incurred. This is also limited today in the EU; by law, the service must be stopped after a certain charge is incurred)

Sure, after 6 years in court you may get a settlement, 95% of which will go towards paying your legal fees.

Not illegal enough to worry about. nothing a peace board donation can’t fix.

How dare you question a corporation's ability to make unlimited money?

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.

Please see my response to your pasted comment in another thread: for many APIs that you can enable on a GCP project, you are intended to use the same GCP project across the whole application for quota tracking. Google even makes you assert that you are only using one GCP project (or at least list out all GCP projects, which APIs are enabled on them and what their purpose is and why you have more than one) when seeking approval for public facing OAuth.

You are wrong that increasing projects have no cost; many services have project based costs (Cloud Armour rules cannot be used cross project at the base tier), many services (mostly observeability) degrade significantly cross project, the Google Cloud Console _sucks_ cross project.

You are also wrong in saying there are no projects that could reasonably have a safe api key made unsafe by this exploit.

One example, a service that has firebase auth must publish the key (Google's docs recommend). Later, you add gen ai to that service, managing access using IAM/service accounts (the proper way). You've now elevated the Firebase Auth Key to be a Gemini key. Really undeniably poor from Google.

The problem is Google explicitly stating that those API keys are not secret and should be public, which indeed was true until Gemini came around.

It's not enabled by default on projects but it's enabled by default on keys.

It shouldn't be enabled by default on either one.

Or usecase: developer X stopped using Maps/etc N years ago, and is long gone, and then developer Y stumbles into the company's google api console.

Of course, Google is full of smart anti-fraud experts, they just handle 80% of this shit on the back-end, so they don't care about the front-end pain.

You know things are bad when Microsoft is the most stable...

About 10 years ago I got $100 for free to use on AdSense. I used it for fun not realizing it keeps going and then billed me. Since then I basically don't use any Google paid products. Hope that $250 was worth it.

https://www.reddit.com/r/googlecloud/comments/1reqtvi/82000_...

It’s pretty much a daily occurrence in all three of the big cloud subs that people still learning get wiped out because the clouds refuse to provide appropriate safeguards

Another takeaway: if Google can become a shell of what it once was (in terms of institutional competence, I assume you mean; Alphabet market cap seems to be doing just fine), so can your organization. As such: making something that isn't supposed to be part of your security strategy, look like it could be, is actually a long-term security risk. Sooner or later a new team will not read your own documentation, and jump to wrong conclusions. Also, it probably trains a bad security posture into your users. How many inexperienced devs saw that it was safe and expected (and apparently even required) to leave these keys out in the open, and concluded that the same logic might apply to someone else's API keys?

I think this was much less likely to happen without the needless obfuscation. If the only purpose is to identify what project the data is for, and you're trusting the client to report that value, and counseling the client to use that value in a way that trivially exposes it to everyone... what is the point of making it look like cryptic garbage? Just use the account signup name or something, and don't call it a "key" in your query parameters. Keys are supposed to unlock stuff. A name tag is not a key.

Seems like they ought to be dedicated security teams monitoring for exactly this: does a key to X give users access to not-X. Even more bizarre is their VDP team not immediately understanding the severity of the issue.

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.

I feel it in a smaller but forced growing organization as the combination of atomised responsibilities and confused/overloaded coordination. For - a certian kind of - efficiency people are isolated into their responsibility area that they are able to oversee/comprehend - with accountability - that a manegement layer is supposed to coordinate. If the mangemenet layer is now overloaded or poorly executed - confused in case of evolution and growth and any kind of restructuring - but the atomic responsibility areas are having basically no (other than anecdotic employee chatter) oversight then troubles, even obvious ones, go undetected.

> First of all, Google is a shell of the company it used to be.

Isn't that squarely at odds with Google's supposed AI prowess? Is the rot really so severe that their advances in AI (including things they've yet to make public) are insufficient to overcome it? Or are the capabilities of Gemini and AI systems in general being oversold?

To boldly allow to go where many have gone before (but shouldn't have been able to)...

"This seems fine"

I think you're using the word "key" differently than OP. You're talking about identifiers, and they're talking about security.

SSNs were a good potential identifier, until the people that needed security cheaped out and started using SSNs as a bad implementation of security. Now they're bad at both purposes!

Yes, designing and implementing a new common identifier almost all US citizens have would have been less cheap and fast.

I was thinking more maliciously targeting the developer and running up a huge bill than reusing their key for your use

with llms maybe you can reuse their api for your own benefit instead of just showing some maps, so the issue is even worse that only cost.

Maps keys are always public in js on the website (but locked to use on certain domains). That’s how they work.

It’s been years but I thought I recalled having to use the key but then also setting what sites it’d work on.

I save $20/mo on my internet by having cable that I don’t watch. Why? So my telecom company can boast higher tv subscriber counts to shareholders and ad-networks.

It is entirely believable to me that a company like Google would do the same with AI use numbers. I suspect that all these AI use factors in corporate performance reviews are about the same thing.

This could be a standard oversight too, I find Google’s documentation on this stuff to be Byzantine.

I had the same thought. I guess a lot of those keys may belong to dormant/deleted accounts and only a % of people who have enabled Gemini (presumably it required user action)

It feels generated to me too. It’s this:

    When you enable the Gemini API (Generative Language API) on a Google Cloud project, existing API keys in that project (including the ones sitting in public JavaScript on your website) can silently gain access to sensitive Gemini endpoints. No warning. No confirmation dialog. No email notification.

If you scroll through tiktok or instagram you can see the same exact pattern in a lot of LLM generated descriptions.

It's too well structured and the message is too clear. HN (and the whole internet) is allergic to proper writing. We praise human sloppiness now.

No, I'm not being sarcastic. People have given up em-dash, which is an official punctuation you use in proper writing. And it's all a downhill from there.

It's far longer than it needs to be because the writing process was too cheap.

> The Core Problem

> What You Should Do Right Now

> Bonus: Scan with TruffleHog.

> TruffleHog will verify whether discovered keys are live and have Gemini access, so you'll know exactly which keys are exposed and active, not just which ones match a regular expression.

I don't know exactly, but I'm sure. The cadence, the clarity, the bolding, the italics, it's all just crisp and clean structured and actionable in a way that a meandering human would not distill it down to.

It's too structured and consistent. Imo. Has that AI smell to it, but I guess humans will eventually also start writing more like the AIs they learn from.

The fact that according to this reply section most of HN can't tell means that predictably, all hope is lost and there's no point in writing anything by hand any more if you're in it for money/engagement.

While writing this I suddenly realized that marketers and writers probably do a better job at recognizing it than developers and engineers, so maybe all hope isn't.

For those who want to know the tells: overall cadence and frequency of patterns - especially infrequency of patterns - are the biggest ones. And that means that we can't actually give you the best tells, because they're more about what is absent than what is present. What's absent is a single sentence pattern that falls completely out of the LLM go-toes. Anything human written has at most a good mix of both. LLM-written text just entirely lacks it. Humans do use the LLM-preferred patterns, but not for every single sentence. But anyway, here we go.

> Transparently, the initial triage was frustrating; the report was dismissed as "Intended Behavior”. But after providing concrete evidence from Google's own infrastructure, the GCP VDP team took the issue seriously.

^ Fun fact - The ";" would've originally been an em-dash but was either rewritten or a rule was included for this.

> Then Gemini arrived.

^ Dramatic short sentences, a pattern with magnitudes higher LLM-frequency than human frequency, but hasn't reached the public conscious yet a la "not just X but Y".

> No warning. No confirmation dialog. No email notification.

^ Another such pattern. Not just because it's three of them, but also because of the content and repetition. Humans rarely write like that because it again sounds overly dramatic. It's something you see in fiction rather than a technical writeup. In a thriller.

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

This style of scenario writing is another one.

> Nobody told you.

Absolute drama queen.

>The UI shows a warning about "unauthorized use," but the architectural default is wide open.

Again.

> The attacker never touches your infrastructure. They just scrape a key from a public webpage.

Again.

> These aren't just hobbyist side projects. The victims included major financial institutions, security companies, global recruiting firms, and, notably, Google itself.

..

> A key that was deployed years ago for a completely benign purpose had silently gained full access to a sensitive API without any developer intervention.

Surprised it hasn't gained consciousness by now. Maybe that's a future plot point.

Here's a great example to train your skills on, because it's rare in that the ratio of "human : straight from LLM" increased gradually as the article goes on: https://www.wallstreetraider.com/story.html

It started at heavy human editing (or just human-written), but less and less towards the end.

The author confirmed this upon pointing it out, FWIW [0].

[0] https://news.ycombinator.com/item?id=47013150

They don't. Many of these claims are due to illiteracy.

Someone is complaining that

> it's all just crisp and clean structured and actionable in a way that a meandering human would not distill it down to.

but this is a security report ... people intentionally write such things carefully and crisply with multiple edits and reviews.

They're obviously talking about on the client's end, not Google