Google Maps API restrictions

[davehowe]

Have been using Google Maps APIs happily for a while. Recent email from Google warning that I should 'Secure unrestricted API keys'. Don't know how to restrict the API so only my iMatch application is using it. See
https://cloud.google.com/docs/authentication/api-keys#securing
What should I restrict it on?
I assume it is either HTTP referrers
OR
IP Addresses

Do I need to put my local IP address in
or is the request coming from an iMatch server

[Mario]

You cannot really secure the API key, except keeping it secret. And change it occasionally.

The request comes from your computer, with the IP address currently assigned to you by your ISP (usually that changes once a day). So IP locks etc. cannot be used. Google Maps uses HTTPS to encrypt everything end-to-end.

[rolandgifford]

There are some restrictions that can be entered to make it marginally more secure (taking your point that the only way really is to keep it secret).

Which APIs does IMatch use. It is possible to restrict the key to specific APIs

Also, does IMatch call as if it is a web site? Google can restrict to Websites, IP addresses, Android apps or iOS apps - only websites being potentially possible. This is from the Google help:

How do I restrict my API key to specific websites?
Use an HTTP referrer to restrict the URLs that can use an API key. Learn more

Here are some examples of URLs that you can allow to set up a referrer:

Any URL in a single domain with no subdomains: https://example.com
Any URL in a single subdomain: https://sub.example.com
Any subdomain in a single domain, using a wildcard asterisk (*): https://*.example.com
A domain and all its subdomains, using a wildcard asterisk (*):
https://example.com
https://*.example.com
A URL with a non-standard port: http://www.example.com:8000
Note: Query parameters and fragments are not currently supported; they will be ignored if you include them in an HTTP referrer.

[Mario]

Securing an API key is important if you use it from an app or similar where bad actors can try to extract it somehow.
When IMatch would route all map requests over one of my server, my API key would be used. And then I would secure it via the static IP address of my server.

Since you use the API key only on your computer, and the browser in the Map Panel is handing it to the Google Maps JavaScript code that does the authentication, somebody has to get access to your PC to steal your API key.

[Stenis]

I did that for myself yesterday and besides the restrictions it also applies an alias but I haven´t understood if it is that alias we shall use in Autotagger or what.

[Mario]

AutoTagger needs an API key. Not sure that kind of "Alias" you have created. Restricting an API key to specific APIs is always advisable and usually automatic. Google requires you to select for what you want to use an API key. Unless you enable the correct API, nothing will work. As documented in Google Maps API Key and for Gemini they activate generativelanguage.googleapis.com, I believe.

Since the API key must be accessible to IMatch, everybody that can access your computer and start IMatch can fetch your API keys. No protection against that.

In "normal" projects the API key is stored on a server, and the server accesses Google services. In this scenario you can secure the API key via the static IP address of the server or server farm.

This cannot work if you use the API key from a desktop application on a computer which gets a dynamic IP address assigned every day or more often. Only few "private" persons have static IP addresses. But when you have one, you can use it to lock the Google API key to your computer.

A bit of overkill, though.

Only you know your API key. You can change it when you want (and update it in IMatch accordingly). Configure Google to send emails to at least two of your email addresses when your budget is exceeded, s a warning in case you somehow "lose" your API key.

Unfortunately Google does not support a hard limit, e.g. if 10$ are used, block API access until next month or until I unlock. This would be the best solution.

[Stenis]

I have cancelled all my Gemini-activities yesterday since I read:

"MSN wrote in Swedish:
Tim trodde det var gratis – fick en räkning på 155 000 kronor från Google
which means "Tim thought it was for free and got a bill on 16 145 US-dollars from Google"

This guy had by "mistake" used a service called "Deep Search"

Yesterday I checked and it is there in the left side menu in Google.

I'm only using the Google map-services specified in the iMatch helpsystem.

I don´t like Google Cloud and the Gemini-system since it is so extremely cluttered and hard to understand so I´m not surprised at all that this actually has happened and I see even here that people are confused så I´m not alone.

From now on I will use as little as possible of Googles really messy services.

What a difference with OpenAI. There I can handle by myself in advance how much I will put in in advance instead of like at Google where they bill you after how many tokens are used. 155 000 for just pressing the wrong button.

[Stenis]

They asked me to add an alias to use instead of the actual key. I have no idea yet how that is supposed to work.

If you look at their interface used to add the alias you will know.

[Stenis]

Here the translated text:

We've all heard the expression "a lesson learned at a high price".

And of course, it's easier to laugh at other people's financial mistakes than to suffer one yourself. If you're one of those who prefers to learn from others' experiences - then you should read on.

A user known only as Tim recently got a real shock when he suddenly received a bill for about 14,000 US dollars - which is equivalent to about 155,000 Swedish kronor.

After sending a request to Google's data storage service BigQuery, specifically linked to historical HTTP Archive data, the bill came down from Google Cloud:

"Last week I ran a script against HTTP Archive data and received a bill for 14,000 USD from Google Cloud - without any warning. And they refuse to remove the fee", he explains.

Tim's very expensive lesson clearly shows how important it is to pay attention to details when moving around in the digital world.

This is reported by the Norwegian technology media Kode24.

A crucial detail
The HTTP Archive project contains enormous amounts of data, stored on Google Cloud BigQuery, and is freely available to all users.

But here comes the important detail that cost Tim big money: Just because something is "openly available" does not automatically mean it is "free to use".

It was precisely this misconception that led to Tim being charged a sky-high bill. He now expresses frustration that the HTTP Archive website does not more clearly warn about the potential costs that may arise when using the dataset through Google.

Following Tim's experience, the HTTP Archive website has now been updated, with a clearer warning that caution should be exercised to avoid unexpected expenses.

The incident has led to a broader discussion about the responsibility of using large datasets – especially when it can involve costs of this magnitude.

[Mario]

When you process one million images with Gemini, Google will bill you. When you pull gigabytes of data from an AWS S3 bucket, Amazon will bill you. When your API key is stolen and some actors use it to make millions of Gemini or reverse geocoding requests, Google will bill you.

I don't know what an alias is. Each API key has a key and a name. You need to API key for AutoTagger, not the name or what else.

[rolandgifford]

Since the API key must be accessible to IMatch, everybody that can access your computer and start IMatch can fetch your API keys. No protection against that.

...

This cannot work if you use the API key from a desktop application on a computer which gets a dynamic IP address assigned every day or more often. Only few "private" persons have static IP addresses. But when you have one, you can use it to lock the Google API key to your computer.

Partly correct. Google offer the alternative to a static IP address restriction to be a restriction of requests from a particular browser origin. Therefore if IMatch always requests from *.phototools.com (or whatever) the key can be restricted to calls from that address. As IMatch is effectively requesting from a browser page, knowing that browser ID would allow us to add this restriction.

Unfortunately Google does not support a hard limit, e.g. if 10$ are used, block API access until next month or until I unlock. This would be the best solution.

They used to provide a hard limit with the old charging method and $200 per month free. There was a daily warning limit that didn't interfere with usage and a monthly limit which blocked requests. I have changed my workflow since the effective reduction in the free usage but will have another look.

[Mario]

Partly correct. Google offer the alternative to a static IP address restriction to be a restriction of requests from a particular browser origin.

As far as I understand this works with the referrer, which is usually the domain name. The browser hosting the map panel uses localhost or 127.0.0.1, so you might be able to restrict your API key to 127.0.0.1? The full referrer is http://127.0.0.1:50519/ (the post number may vary).

Not sure, never tried this. Since every PC out there has this 127.0.0.1 IP address, it does not really protect your API from misuse.
Note that IMatch does not call any Google Map APIs. When the user has enabled Google, the Map Panel loads a script from the Google Maps site, which then does all the communication with the map servers.

[rolandgifford]

Thanks for this additional information.

127.0.0.1 is indeed useless as a restricted origin

I've had a look for hard limits on Google billing and haven't found one yet. The soft email warning limits are still there and it would be sensible for everyone to set those at some sort of minimal value to check for unexpected levels of charge.

Oddly I can't find any record of me doing any geocode lookups this month and I know that I have done some. Perhaps they don't report the free ones which wouldn't be good.

[Stenis]

AutoTagger needs an API key. Not sure that kind of "Alias" you have created. Restricting an API key to specific APIs is always advisable and usually automatic. Google requires you to select for what you want to use an API key. Unless you enable the correct API, nothing will work. As documented in Google Maps API Key and for Gemini they activate generativelanguage.googleapis.com, I believe.

Since the API key must be accessible to IMatch, everybody that can access your computer and start IMatch can fetch your API keys. No protection against that.

In "normal" projects the API key is stored on a server, and the server accesses Google services. In this scenario you can secure the API key via the static IP address of the server o

Since the API key must be accessible to IMatch, everybody that can access your computer and start IMatch can fetch your API keys. No protection against that.

...

This cannot work if you use the API key from a desktop application on a computer which gets a dynamic IP address assigned every day or more often. Only few "private" persons have static IP addresses. But when you have one, you can use it to lock the Google API key to your computer.

Partly correct. Google offer the alternative to a static IP address restriction to be a restriction of requests from a particular browser origin. Therefore if IMatch always requests from *.phototools.com (or whatever) the key can be restricted to calls from that address. As IMatch is effectively requesting from a browser page, knowing that browser ID would allow us to add this restriction.

Unfortunately Google does not support a hard limit, e.g. if 10$ are used, block API access until next month or until I unlock. This would be the best solution.

They used to provide a hard limit with the old charging method and $200 per month free. There was a daily warning limit that didn't interfere with usage and a monthly limit which blocked requests. I have changed my workflow since the effective reduction in the free usage but will have another look.

r server farm.

This cannot work if you use the API key from a desktop application on a computer which gets a dynamic IP address assigned every day or more often. Only few "private" persons have static IP addresses. But when you have one, you can use it to lock the Google API key to your computer.

A bit of overkill, though.

Only you know your API key. You can change it when you want (and update it in IMatch accordingly). Configure Google to send emails to at least two of your email addresses when your budget is exceeded, s a warning in case you somehow "lose" your API key.

Unfortunately Google does not support a hard limit, e.g. if 10$ are used, block API access until next month or until I unlock. This would be the best solution.

Wouldn't it be difficult to spend 200 USD with Autotagger and GEMINI API?

I prefer the OpenAI solution with paying in advance upfront. Then this that happened with Deep Search on Google just can't happen. Of this reason I have ditched Google because that is an example of greed.

I have another from Greece where some has complained over a restaurant overcharging people heavily for a meal (around 400 Euro) without giving them a choice.

Hidden surprises are not nice but turning tricks like this just works once. I will just continue to use Google Map services. I woun't need Google Gemini because OpenAI  works better for me since Gemini seems to miss to update my ARW-rawfiles from time to time anyway. Bye Bye Gemini.