231–240 of 326 posts
I'm a bit surprised by the timeline which seems to say that: - 6 weeks ago Google said they would fix it - 3 weeks ago Google said they were working on it ...but we're publishing the info anyway, so everyone can go nuts with it.
Earlier quoted context omitted.
[flagged]
It’s possibly civil, but I don’t see how this type of negligence would be breaking a law. If it was illegal, a massive number of independent consultants would be serving prison sentences. I’m not sure how that makes anything better though I guess a lot of people think rage is fun.
This seems so… obvious? How can a company of this size, with its talent and expertise, not have standardized tests or specs preventing such a blatant flaw?
Which is what makes this so notable. Did the security review not catch this, or did they choose to launch anyways because it was too hard to fix and speed was of the essence?
Earlier quoted context omitted.
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
> 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!
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…
I hope Google has a database with the creation timestamp for every API key they issued.
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…
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
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.
Unrestricted API keys were always secrets. They are created on a page called "Keys & Credentials". The fact that Google even allows unrestricted keys to be created has been a long standing security problem. The fact their docs encouraged it remains unforgivable.
Public keys are a thing in computing, though? Google Maps has one, even. And Stripe.
The only purpose of the keys Maps/Stripe encourage you to publicly put into your website is to guarantee it is talking to _your_ Google/Stripe account not someone else's. Obviously once you put them in your client they are of zero value in helping Google/Stripe identify you. The fact that Google allows you to use the same type of key they also use elsewhere to identify _you_ not _them_ was always incredibly bad design. Google already have the 'Project ID' which would have been the best thing to use.
Earlier quoted context omitted.
At scale, distributed API routing shouldn't call accounting transactions, that expands the availability risk surface and adds latency to all valid requests for no reason (other than helping the minority of companies/users who want their product to stop working when it is popular). Distributed “shared nothing” API handling should make usage available to accounting, and the API handling orchestrator should have a hook…
That is a nice excuse, do you work at Google? :) I get the idea of not slowing down requests or risking availability, but don’t tell me a company as big as Google can’t design an asynchronous accounting system robust enough to handle this. We’re not talking about penny-perfect precision - blocking at 110% or even 150% of the set cap would be enough. Right now, though, there’s nothing to prevent a $5k, 20k or even hig…
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".)