Google API keys weren't secrets, but then Gemini changed the rules
trufflesecurity.com1190 points by hiisthisthingon a day ago
1190 points by hiisthisthingon a day ago
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 or Hacker News. https://github.com/qudent/qudent.github.io/blob/master/_post...
[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 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)
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.
> 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 negative balance. I actually complained and they told me that they allow the "final query" to complete rather than cutting it off mid-process, which is of course silly, because Claude Code is typically used for long sessions, where the benefit of being cut off 52% into the task rather than 51% into it is essentially meaningless.
I ended up paying for these so far, but would hope that someone with more free time sues them on it.
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.
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 charging me more than that (or I would have prepaid more). It's up to them to figure this out and/or absorb the costs.
> they obviously do have some billing check that prevents me from making additional requests after that "final query"
No they don't actually! They try to get close, but it's not guaranteed (for example, make that "final query" to two different regions concurrently).
Now, they could stand up a separate system with a guaranteed fixed cost, but few people want that and the cost would be higher, so it wouldn't make the money back.
You can do it on your end though: run every request sequentially through a service and track your own usage, stopping when reaching your limit.
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.
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.
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 large bill. People hate both of those things and will complain regardless of which one actually happens.
The main thing Google is screwing up here is not giving you the choice between them.
Imagine the outrage here, when a company credit card expires and the cloud provider terminates all their instances, deletes all your storage and blob backups?
That does happen, it's just usually not when the card expires, but when the follow up billing emails get ignored for some period.
This is one of the reasons people have suggested using a different provider for backups.
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.
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?
You're oversimplifying the problem in the other direction. Fine-grained scriptability of hard limits would bump up against all of the thorny distributed systems problems. But I do agree that fixing the simple cases is straightforward - maximum spend rates per instant and per unit of time (eg per minute, hour, day, month). Providers would shoulder the small costs from the slightly-leaky assumptions they have to make to implement those limits, and users can then operate within that framework to optimize what they want on a best-effort basis (eg a script that responds within a minute to explicitly scale resources, or a human-in-the-loop notification cycle over the course of hours so that you have the possibility to say "actually this is popularity traffic that I really do want to pay for, etc).
The main thing Google is screwing up is that if my API key somehow leaks and I end up with extremely out of line billing at Microsoft, I will be on the phone with a customer representative as soon as we or they notice something weird happening and a solution will be found.
Google will probably have me go through five bots and if, by some kind of miracle, I manage to have a human on the phone, they will probably explain to me that I should have read the third paragraph of the fourth page of the self service doc and it's obviously my 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!
This is just the utility model. It's nothing particularly nefarious. Consider what your electric utility, your water utility, etc. do. If you use more, you pay more. If someone comes around and hooks up a garden hose to your outside faucet and steals your water, or plugs an extension cord into your outside outlet and steals your electricity, you still pay. Unless you can catch the thief and make him pay.
Funny enough, the utility business broadly wants to move away from this model to more of a cap-based prepaid model. Where I live, to get on the standard payment system may require a quite hefty deposit up front, but the prepaid payment option does not. I get the impression that, if not for customer sentiment and inertia, this would be the default option.
Why should I care about the companies POV? The company always wants to rat fuck everyone to make money. The company should be legally compelled to care about the customer because that's the only way these things change.
I think the term you are looking for is "negligence".
But not in the causal sense of the word but in the legal "the company didn't folly the legal required base line of acting with due diligence".
In general companies are required to act with diligence, this is also e.g. where punitive damages come in to produce a insensitive to companies to act with diligence or they might need to pay far above the actual damages done.
This is also why in some countries for negligence the executives related to the negligent decisions up to the CEO can be hold _personally_ liable. (Through mostly wrt. cases of negligence where people got physically harmed/died; And mostly as an alternative approach to keeping companies diligent, i.e. instead of punitive damages.).
The main problem is that in many cases companies do wriggle their way out of it with a mixture of "make pretend" diligence, lawyer nonsense dragging thing out and early settlements.
> 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.
Sure, after 6 years in court you may get a settlement, 95% of which will go towards paying your legal fees.
> 95% of which will go towards paying your legal fees
laughs in European
I laughed. No in europe when you win a case like this the judge usually forces the losing party to pay the legal expenses of the winner. Especially if the losing party is a big corporation.
It's the same in the US
It is not. Legal fees are rarely awarded in the U.S.
I should have said if you recover it in your damages, which every competent attorney will push for.
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.