Live data from Hacker News

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

trufflesecurity.com

321–326 of 326 posts

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

#321

Earlier quoted context omitted.

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 seem to not comprehend the concept of informed choice . Upstream in the comments someone said they expect the EU might soon rule this type of billing illegal. That doesn't mean it becomes illegal, it just means yet another reaffirmation or reminder that - yes - this is indeed illegal. You said that no fixed response -whether that is allow unexpected billing to increase without limit upon a surge vs serving error…

> You said that no fixed response -whether that is allow unexpected billing to increase without limit upon a surge vs serving error pages- will be accepted by the clientele, because some want it one way and others want it the other way.

No, it's because people dislike both of those things and don't want either one of them, and frequently fail to realize ahead of time that choosing between them is even necessary and then get upset by whichever one actually happens.

> Why would you force a single shoe size onto a population?

Here's my original post:

> The main thing Google is screwing up here is not giving you the choice between them.

> And it doesn't have to be just those 2 options

We're talking about an API used by programmers. You don't need them to give you any of that, all you need is for the API to tell you what your current usage is -- and even that is only necessary if something other than your own code is racking up usage. When you're the one making queries and the price of each one is known ahead of time or available via the API, you can already implement any of that logic yourself.

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

#322
post #240

Earlier quoted context omitted.

They do, yeah. (Although `pk` always freaks me out. Public or private?! Oh, right, the other one's "secret".)

Or is `sk` shared key and `pk` private key...

OK now I'm rethinking my life

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

#323
post #270

Earlier quoted context omitted.

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?

Yep: JSON schema Alternatively, with typescript you can write:

export type FooRpcV1 : { version: 1, ... } export type FooRpcV2 : { version: 2, ... }

in zod syntax, and it'll do the right thing statically and at runtime (ask an LLM for help with the syntax).

With protobufs (specifically protoc), you get some type like:

export type FooRpc : { version : 1 | 2, v1fieldA? : string, v1fieldB? : int, v2fieldB? : string, v2fieldB? string };

which is 2^5 message types, even if all fields of both versions were mandatory. Then application logic needs to validate it.

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

#324
post #286

Earlier quoted context omitted.

It wasn't a subscription. My expectation was that it would simply stop once it hit $0. Not really here to argue about it. The tldr is I don't trust Google with this stuff anymore.

I wonder what you thought putting your credit card on file was for.

The credit card on file was for other stuff in Google.

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

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

[dead]
Post reply on HN