> Beijing is trying to manage a 'controlled glide' in growth while building a new economy based on technology rather than property,"

Sounds like a good idea

It's an article about the Gulf states, and how their desalination plants are vulnerable to Iran.

Exactly, this is Iran, international law applies to them unlike Israel and the US. So they better watch out or we carpet bomb their capital and assassinate their head of state, which isn't violating international law because come on it's US!

Is Litestep still around? You used to be able to sub out the windows shell...

Are there non-Mac laptops that still support real sleep? I'm worried about replacing my beater XPS.

Man, how do you get box seats out of AWS, I'm missing out

Something about being president just makes people want to do it

Grok in unhinged mode piloting an Apache, what could go wrong.

> Retroactive Privilege Expansion. You created a Maps key three years ago and embedded it in your website's source code, exactly as Google instructed. Last month, a developer on your team enabled the Gemini API for an internal prototype. Your public Maps key is now a Gemini credential. Anyone who scrapes it can access your uploaded files, cached content, and rack up your AI bill. Nobody told you.

Malpractice/I can't believe they're just rolling forward

They should limit the new features to new API keys that explicitly opt-in instead of fucking over every user who trusted their previous documentation that these keys are public information.

Isn't it standard practice to harden permissions on API keys? Like, if I were a bootstrapped startup maybe I'd take shortcuts and let an API key have a * permission but not for anything that could rack up thousands of dollars in bills for the customer. But at googles scale that just seems irresponsible.

Maps keys are always public in js on the website (but locked to use on certain domains). That’s how they work.

It is not actually locked to a site is just based off the host header. Which is public information an attacker can use to make the requests.

Sure, but the practical form of this attack is limited.

You can't maliciously embed it in a site you control to either steal map usage or run up their bill because other people's web browsers will send the correct host header.

That means you can use a botnet or similar to request it using a a script. But if you are botnetting Google will detect you very quickly.

> But if you are botnetting Google will detect you very quickly.

They don't do anything against that.

Is there a way to use Google maps apis on the web without exposing the key?

Re host header seems an odd way for Google to do it, surely they would have fixed that by now? I guess not a huge problem as attackers would have to proxy traffic or something to obscure the host headers sent by real clients? Any links on how people exploit this?

What is there to fix? It was designed this way.

Something that can be abused is if the key also has other Maps APIs enabled, like Places API, Routes API or Static APIs especially for scraping because those produce valuable info beyond just embedding a map.

The only suggestions I have are:

- If you want to totally hide the key, proxy all the requests through some server.

- Restrict the key to your website.

- Don't enable any API that you don't use, if you only use the Maps Javascript API to embed a map then don't enable any other Maps API for that key.

It would be helpful if you answer the question about web api usage, most of that is not relevant.

The only suggestion I see there from a quick skim that would avoid the above is for customers to set up a google maps proxy server for every usage with adds security and hides the key. That is completely impractical suggestion for the majority of users of embedded google maps.

It’s been years but I thought I recalled having to use the key but then also setting what sites it’d work on.

If an attacker can figure out what sites it can be used on, they can use the API.

That was brutal, but somehow still not mean enough.

Claude probably