Live data from Hacker News

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

trufflesecurity.com

251–260 of 326 posts

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

#251

Earlier quoted context omitted.

Tax ids were never meant to be used as a form of global identification. If you go look in a real bank core, you'll find this field does not have any uniqueness constraints.

Why not? Two people with the same tax ID seems like a problem waiting to happen.

These schemas also support non-individuals with the same fields. EINs have a lot more edge cases than SSNs.

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

#252
post #73
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.

> In a perfect bureaucracy nobody thinks.

This resonates so well and I love it. I'm stealing this

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

#253
post #184

Many people wanted to be able to set a spending limit on google cloud account for many years but they were unable to implement anything, always suggesting a workaround by hosting a Cloud Run function which would remove billing from a project via API https://docs.cloud.google.com/billing/docs/how-to/disable-bi...

reminds me: Ever used Gemini API on Google Vertex Cloud API? The usage will show up like 24-48 hours later in the dashboard. So when you use Gemini's API on their Cloud me as Workspace admin cannot even track my own usage in near realtime there. Which makes me think that even Google cannot track it in realtime.

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

#254

Earlier quoted context omitted.

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

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

#255

Earlier quoted context omitted.

Isn't there a limit to the number of projects you can make and then you have to ask support to increase it?

There is, yes. The rumor mill suggests that the default limit is 30. At $DAYJOB, we had a (not very special) special arrangement with GCP, and I never heard of anyone who was unable to create a project in our company's orgs [0]. Given how Google never, ever wants to have a human do customer support, I expect a robot will quickly auto-approve requests for "number of projects" quota increases. I know that's how it work…

Can vouch, I put in a request for 20 projects extra which was approved in hours.

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

#256

Earlier quoted context omitted.

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

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

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

#257

Earlier quoted context omitted.

The new code changes from not existing, to existing. Indeed, the key doesn't change. The new capability comes from the new code . It would not be a re-evaluation of risk, because this is a new project. The evaluation of risk is supposed to come at the moment when the new capability is implemented, and consciously tied to an existing key type, which was previously advertised as non-secret.

You're replying to an LLM.

It did read a bit LLM-ish, but I didn't expect that someone would prompt an LLM to present that particular point of view. Usually it seems like they don't try to argue for anything in particular (except perhaps to imply that the article was well written.)

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

#258
API keys were always secrets. They control billing for heaven's sake. If you had any per-call billed APIs (like some of the voice processing APIs) enabled on the project then they're effectively keys to your pocket book. Otherwise they're a key tool to manage denial-of-service attacks.

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

#259

Earlier quoted context omitted.

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

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).
Post reply on HN