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

301–310 of 326 posts

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

#301

Post by liveoneggs »

decimalenough wrote: post #43
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…

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 was exploring this today and just clicked on the "maps" Platform or APIs & Services to just explore and it immediately popped up a screen with "This is your API key for maps to start using!" without my input.

It sent me to a url: https://console.cloud.google.com/google/maps-apis/onboard;fl...

which auto-generated an API key for me to paste into things ASAP.

---

Get Started on Google Maps Platform You're all set to develop! Here's the API key you would need for your implementation. API key can be referenced in the Credentials section.

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

#302

Post by liveoneggs »

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…

they auto-create projects and api keys: gen-lang-client-12345

app-scripts creates projects as well but maps just generates api keys in the current project

--- Get Started on Google Maps Platform You're all set to develop! Here's the API key you would need for your implementation. API key can be referenced in the Credentials section.

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

#303

Post by StilesCrisis »

SlightlyLeftPad wrote: post #272
StilesCrisis wrote: post #198

Earlier quoted context omitted.

YouTube and AdSense are both extraordinarily profitable. Google Play and Cloud are great revenue drivers as well. Search Ads are still the king of the hill, but it's definitely not their only profitable project, and many of the "unprofitable" projects funnel traffic to profitable ones--Chrome gives Search uplift, Google Play can't exist without Android, etc.

Definitely, they found another cash printer in Youtube but to be fair, they bought that. My comment wasn’t intended to be definitive. Yes, a lot of their other products are really just funnels to their search ads though. Strategic plays have value too of course.

They bought YouTube well over a decade ago in order to jumpstart their position in streaming, once Google Video failed to take hold, and nowadays the original YouTube would be unrecognizable. It's not like they didn't have the chops to build it, or the business acumen to make it profitable; they just acqui-hired a competitor in the space.

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

#304

Post by umairnadeem123 »

this is what happens when a "public" key type quietly turns into a privileged key type without forcing people to re-scope it, not really a dev mistake IMO, it's a platform design bug and google needs hard separation between publishable and secret keys or this repeats every time they ship a new API. pretty disappointed in google tbh, looked up to them for security for the longest time

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

#305

Post by johanyc »

ceejayoz wrote: post #219
abustamam wrote: post #209

Earlier quoted context omitted.

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

Honestly we should just always call them public and secret key to avoid confusion

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

#306

Post by andrekandre »

blinding-streak wrote: post #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)

  > "[Action Advised] Review Google Cloud credential security best practices"

  > (Although I don't think this even addresses the underlying issue)
sounds like they want to have customers be responsible instead of fixing it themselves ...

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

#307

Post by jordanb »

duxup wrote: post #264
SlightlyLeftPad wrote: post #28

Earlier quoted context omitted.

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

My understanding is Google had this culture of killing products that was fostered by L&S on the idea of "fail fast." Every product had a few year grace period but then the knives were out as PMs all tried to get your product killed so they could add to their "fail fast" portfolio.

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

#308

Post by jorl17 »

carshodev wrote: post #294
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…

I don't know if its still like this but around 1 year ago I set a spending limit for an OpenAI api key but it turns out its not a true limit. I spent 80$ on a 20$ limited key in the matter of minutes due to some bad code I wrote causing a looped loop. I still had to pay it or else I wouldn't have been able to use my account.

It is still the case.

In fact, OpenAI's "billing", "usage tracking" and "billing/spending alerts" UX all have terrible UX. They look like completely independent features.

For example, you can set alert on how much you've spent in a month, but not on how much you have left in your credit bank. So you never really know how much you can still spend unless you go check their slow and confusing UI. You can set it to auto-refill your credits and to limit that to some amount per month (I think?), but again the alerts for this are absolutely atrocious or entirely missing.

Another insane thing I've seen with OpenAI is that, for some reason, your account can be thousands in the red, and some prompts, with some models, or some feature set, still go through. I haven't been able to figure out what heuristic or rule they are using to determine when they let your request through and overbill you, or when they just deny it altogether. Maybe they let all text requests through? Or perhaps it just lets websearch requests through and denies anything else? Maybe it profiles your your most common request and lets those go through? Maybe it had something to do with specific endpoints and APIs? Who knows.

We've moved entire projects off of them in part due to these issues. We got tired of constantly being in the red without a proper notification system (actually: with an insufficient, deceitful system), or of having seemingly random drops in requests only to find out suddenly that combination of parameters got blocked. Please, just completely block me and make me pay. Or give me a better alerts system. We have the money. What we haven't got is the patience to deal with such an obtuse system

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

#309

Post by busko »

edoceo wrote: post #74
rezonant wrote: post #55

Earlier quoted context omitted.

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…

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.

Why would they encourage more resource use, increasing their cost?

Gemini should have had it's own API key separate from their traditionally public facing API IDs (which they call keys) and API keys should default to being tightly scoped to their use case rather than being unrestricted.

Who cares if you have three API keys for three services.

Quite frankly putting any API information in things like url params or client side code just doesn't sit right with me. It breaks the norm in a way that could be, and is now security concern.

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

#310

Post by chii »

chrisjj wrote: post #195
rezonant wrote: post #105

Earlier quoted context omitted.

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…

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

On the other hand, i would not attribute to malice what could be reasonably attributed to stupidity.
Post reply on HN