Live data from Hacker News

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

trufflesecurity.com

291–300 of 326 posts

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

#291
post #256

Earlier quoted context omitted.

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…

They do have a billing check, but that check is looking at "eventually consistent" billing data which could have arbitrary delays or be checked out-of-order compared to how it occurred IRL. This is a strategy that's typically fine when the margin of over-billing is small, maybe 1% or less. I take it from your description that the actual over-billing is more like dozens of dollars, potentially more than single-digit percentages on top of the subscription price. Here's hoping they tighten up metering billing.

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

#292
post #138
post #83

In Google AI Studio, Google documentation encourages to deploy vibecoded apps with an open proxy that allow equivalent AI billing abuse - giving the impression that the API key were secure because it is behind a proxy. Even an app with 0 AI features exposes dollars-per-query video models unless the key is manually scoped. Vulnerable apps (all apps deployed from AI Studio) are easily found by searching Google, Twitter…

[flagged]

> Downvoted for asking an honest question.

If you put in "surely" and people think it's quite wrong then they might downvote. It's not personal.

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

#294
post #151
post #138

Earlier quoted context omitted.

[flagged]

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.

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

#295
post #270
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…

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.

Does JSON have support for protocol versioning?

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

#296

Earlier quoted context omitted.

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

You can already do any of those things in your own code when making the API requests. The issue here is, if you unintentionally try to make a billion expensive requests or allow someone else to do it against your account, do you want them to automatically turn off your stuff or do you want the bill that comes if they don't?

[deleted]

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

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

> or else I wouldn't have been able to use my account.

Would that have been so bad? The world might be a better place if people stopping pouring money into that cesspit.

By continue to use their services, you're encouraging the anti-consumer tactics you're complaining about.

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

#298
post #284
post #271

The headline really undersells the point and reads like clickbait. "Things were fine, then she turned the tables. Watch what happens next." I avoided even opening this article several times out of distaste for the headline. It should be something like "Google leaves your Gemini data vulnerable to non-secret API key exploit."

The headline states a plain fact that is critically important. It's not the writer's fault that the fact is outrageous.

I accused the headline of underselling, not overselling. So unsure why you read me to have blamed the writer for making outrageous claims...

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

#299

Earlier quoted context omitted.

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

They do have a billing check, but that check is looking at "eventually consistent" billing data which could have arbitrary delays or be checked out-of-order compared to how it occurred IRL. This is a strategy that's typically fine when the margin of over-billing is small, maybe 1% or less. I take it from your description that the actual over-billing is more like dozens of dollars, potentially more than single-digit p…

Then the right thing to do from a consumer standpoint is to factor that overbilling into their upfront pricing, rather than surprising people with bills that they were led not to expect.

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

#300
post #271

The headline really undersells the point and reads like clickbait. "Things were fine, then she turned the tables. Watch what happens next." I avoided even opening this article several times out of distaste for the headline. It should be something like "Google leaves your Gemini data vulnerable to non-secret API key exploit."

I like their title better than yours which is a bit long and confusing. I personally would like to see more direct wording stating this is s security incident using words like vulnerability or leak etc but the title really is not that bad just that it does not make me want to click. I only clicked because simonw blogged about it.
Post reply on HN