Please see my response to your pasted comment in another thread: for many APIs that you can enable on a GCP project, you are intended to use the same GCP project across the whole application for quota tracking. Google even makes you assert that you are only using one GCP project (or at least list out all GCP projects, which APIs are enabled on them and what their purpose is and why you have more than one) when seeking approval for public facing OAuth.

You are wrong that increasing projects have no cost; many services have project based costs (Cloud Armour rules cannot be used cross project at the base tier), many services (mostly observeability) degrade significantly cross project, the Google Cloud Console _sucks_ cross project.

You are also wrong in saying there are no projects that could reasonably have a safe api key made unsafe by this exploit.

One example, a service that has firebase auth must publish the key (Google's docs recommend). Later, you add gen ai to that service, managing access using IAM/service accounts (the proper way). You've now elevated the Firebase Auth Key to be a Gemini key. Really undeniably poor from Google.

The problem is Google explicitly stating that those API keys are not secret and should be public, which indeed was true until Gemini came around.

The problem is that developer X did not properly scope the API key when he created it. Yes, separate projects would also stop this, but keys have been capable for ever and creating unrestricted keys is strongly discouraged. Pretty sure you can even set an org policy to prevent someone from doing so…

It's not enabled by default on projects but it's enabled by default on keys.

It shouldn't be enabled by default on either one.

Or usecase: developer X stopped using Maps/etc N years ago, and is long gone, and then developer Y stumbles into the company's google api console.

Of course, Google is full of smart anti-fraud experts, they just handle 80% of this shit on the back-end, so they don't care about the front-end pain.