Mixing
How to avoid abuse of server side calls to Google Geocoding API [closed]
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
In a project, the users generate a lot of calls to the Google Maps Geocoding API that go beyond the free quota limits.
In order to reduce costs I recently changed the code so the user makes server side calls to the Google Maps Geocoding API through my server, which then in return are cached to avoid further API calls of the same queries.
I found however that this setup is being abused by another party which basically routes API calls through my endpoint. This way I end up paying, while somebody else enjoys free API calls.
The web app needs to be publicly accesible, hence a private key or password cannot be shared between the user and my server.
Unfortunately I didn't find anyone talking about this issue on the web and how to stop the exploit. But I have one idea:
- Limit the service calls per user to something like 10/20 calls per minute (something reasonable). That should curb the violent abuse by a certain party (this could work unless they use multiple clients)
I wonder if there are (other) best practices regarding this topic.
The technology used should not matter as this is rather a general/theoretical discussion of what could be done.
google-maps caching geocoding rate-limiting
asked Jan 3 at 12:59
Eric LehmannEric Lehmann
93
closed as primarily opinion-based by geocodezip, TylerH, david, Mitch Wheat, xomena Jan 7 at 15:29
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
In a project, the users generate a lot of calls to the Google Maps Geocoding API that go beyond the free quota limits.
In order to reduce costs I recently changed the code so the user makes server side calls to the Google Maps Geocoding API through my server, which then in return are cached to avoid further API calls of the same queries.
I found however that this setup is being abused by another party which basically routes API calls through my endpoint. This way I end up paying, while somebody else enjoys free API calls.
The web app needs to be publicly accesible, hence a private key or password cannot be shared between the user and my server.
Unfortunately I didn't find anyone talking about this issue on the web and how to stop the exploit. But I have one idea:
- Limit the service calls per user to something like 10/20 calls per minute (something reasonable). That should curb the violent abuse by a certain party (this could work unless they use multiple clients)
I wonder if there are (other) best practices regarding this topic.
The technology used should not matter as this is rather a general/theoretical discussion of what could be done.
google-maps caching geocoding rate-limiting
asked Jan 3 at 12:59
Eric LehmannEric Lehmann
93
closed as primarily opinion-based by geocodezip, TylerH, david, Mitch Wheat, xomena Jan 7 at 15:29
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
Can you perhaps introduce a secret that the client needs to supply in the request to your server?
– wvteijlingen
Jan 3 at 13:03
A secret or a temporary user specific/temporary token won't work because the application needs to be publicly accesible.
– Eric Lehmann
Jan 3 at 13:29
Check if caching/storing results of Google Map API calls violates their licensing agreement. I think it does.
– Michael Diomin
Jan 3 at 16:53
Thanks for the note concerning the licensing agreement. But Geocoding API results may be cached up to 30 consecutive days. See: cloud.google.com/maps-platform/terms/maps-service-terms
– Eric Lehmann
Jan 3 at 16:58
add a comment |
In a project, the users generate a lot of calls to the Google Maps Geocoding API that go beyond the free quota limits.
In order to reduce costs I recently changed the code so the user makes server side calls to the Google Maps Geocoding API through my server, which then in return are cached to avoid further API calls of the same queries.
I found however that this setup is being abused by another party which basically routes API calls through my endpoint. This way I end up paying, while somebody else enjoys free API calls.
The web app needs to be publicly accesible, hence a private key or password cannot be shared between the user and my server.
Unfortunately I didn't find anyone talking about this issue on the web and how to stop the exploit. But I have one idea:
- Limit the service calls per user to something like 10/20 calls per minute (something reasonable). That should curb the violent abuse by a certain party (this could work unless they use multiple clients)
I wonder if there are (other) best practices regarding this topic.
The technology used should not matter as this is rather a general/theoretical discussion of what could be done.
google-maps caching geocoding rate-limiting
asked Jan 3 at 12:59
Eric LehmannEric Lehmann
93
In a project, the users generate a lot of calls to the Google Maps Geocoding API that go beyond the free quota limits.
In order to reduce costs I recently changed the code so the user makes server side calls to the Google Maps Geocoding API through my server, which then in return are cached to avoid further API calls of the same queries.
I found however that this setup is being abused by another party which basically routes API calls through my endpoint. This way I end up paying, while somebody else enjoys free API calls.
The web app needs to be publicly accesible, hence a private key or password cannot be shared between the user and my server.
Unfortunately I didn't find anyone talking about this issue on the web and how to stop the exploit. But I have one idea:
- Limit the service calls per user to something like 10/20 calls per minute (something reasonable). That should curb the violent abuse by a certain party (this could work unless they use multiple clients)
I wonder if there are (other) best practices regarding this topic.
The technology used should not matter as this is rather a general/theoretical discussion of what could be done.
google-maps caching geocoding rate-limiting
google-maps caching geocoding rate-limiting
asked Jan 3 at 12:59
Eric LehmannEric Lehmann
93
asked Jan 3 at 12:59
Eric LehmannEric Lehmann
93
edited Jan 7 at 16:17
Eric Lehmann
asked Jan 3 at 12:59
Eric LehmannEric Lehmann
93
asked Jan 3 at 12:59
Eric LehmannEric Lehmann
93
asked Jan 3 at 12:59
Eric LehmannEric Lehmann
93
93
closed as primarily opinion-based by geocodezip, TylerH, david, Mitch Wheat, xomena Jan 7 at 15:29
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as primarily opinion-based by geocodezip, TylerH, david, Mitch Wheat, xomena Jan 7 at 15:29
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
Can you perhaps introduce a secret that the client needs to supply in the request to your server?
– wvteijlingen
Jan 3 at 13:03
A secret or a temporary user specific/temporary token won't work because the application needs to be publicly accesible.
– Eric Lehmann
Jan 3 at 13:29
Check if caching/storing results of Google Map API calls violates their licensing agreement. I think it does.
– Michael Diomin
Jan 3 at 16:53
Thanks for the note concerning the licensing agreement. But Geocoding API results may be cached up to 30 consecutive days. See: cloud.google.com/maps-platform/terms/maps-service-terms
– Eric Lehmann
Jan 3 at 16:58
add a comment |
Can you perhaps introduce a secret that the client needs to supply in the request to your server?
– wvteijlingen
Jan 3 at 13:03
A secret or a temporary user specific/temporary token won't work because the application needs to be publicly accesible.
– Eric Lehmann
Jan 3 at 13:29
Check if caching/storing results of Google Map API calls violates their licensing agreement. I think it does.
– Michael Diomin
Jan 3 at 16:53
Thanks for the note concerning the licensing agreement. But Geocoding API results may be cached up to 30 consecutive days. See: cloud.google.com/maps-platform/terms/maps-service-terms
– Eric Lehmann
Jan 3 at 16:58
Can you perhaps introduce a secret that the client needs to supply in the request to your server?
– wvteijlingen
Jan 3 at 13:03
Can you perhaps introduce a secret that the client needs to supply in the request to your server?
– wvteijlingen
Jan 3 at 13:03
A secret or a temporary user specific/temporary token won't work because the application needs to be publicly accesible.
– Eric Lehmann
Jan 3 at 13:29
A secret or a temporary user specific/temporary token won't work because the application needs to be publicly accesible.
– Eric Lehmann
Jan 3 at 13:29
Check if caching/storing results of Google Map API calls violates their licensing agreement. I think it does.
– Michael Diomin
Jan 3 at 16:53
Check if caching/storing results of Google Map API calls violates their licensing agreement. I think it does.
– Michael Diomin
Jan 3 at 16:53
Thanks for the note concerning the licensing agreement. But Geocoding API results may be cached up to 30 consecutive days. See: cloud.google.com/maps-platform/terms/maps-service-terms
– Eric Lehmann
Jan 3 at 16:58
Thanks for the note concerning the licensing agreement. But Geocoding API results may be cached up to 30 consecutive days. See: cloud.google.com/maps-platform/terms/maps-service-terms
– Eric Lehmann
Jan 3 at 16:58
add a comment |
3 Answers
3
active
oldest
votes
A solution could be to use a secret that is shared between the client and the server. Unfortunately this doesn't work if the client source code is publicly accessible (e.g. a web app).
Limiting the calls per user would work but you probably need to protect against the abusing party creating users automatically. Perhaps adding a daily limit of geolocation calls per IP, or limit of user creation calls per IP would work.
Lastly you might need to use some kind of abuse detection mechanism on your server. Something that monitors the amount of calls per IP, per user, recognises patterns etc.
answered Jan 4 at 11:00
wvteijlingenwvteijlingen
8,96312545
add a comment |
I would suggest having a look at best practices documentation for Google Maps Web Services:
https://developers.google.com/maps/api-key-best-practices
The most important thing is protect your API key. In case of web services you should protect the API key with IP address of your backend server. In this case nobody else will be able to use your API key and abuse your quota.
You should secure the API keys in your application for all Maps Platform products that your application uses. You can secure API keys by designating restrictions and by implementing best practices that are appropriate for the Google Maps Platform APIs in your application. Publicly exposing unsecured credentials can result in unintended use, which could lead to unexpected charges on your account.
I hope this helps!
answered Jan 4 at 19:09
xomenaxomena
18.9k44275
Although, it's a good idea to read through the api key best practices. It does not answer the question because the API key is not exposed in my scenario.
– Eric Lehmann
Jan 7 at 11:41
If API key is not exposed, so you have to protect your own server side calls. Isn't it?
– xomena
Jan 7 at 14:19
Exactly, that's the question. How to protect my own server side calls. :)
– Eric Lehmann
Jan 7 at 15:22
You should reformulate your question. It is not directly about protection on the Google Maps API side, its about protection on your server side code. However, you didn't specify even technology used on your server side. Java, PHP, Python, NodeJs...???
– xomena
Jan 7 at 15:29
I edited the question. I hope it's clearer now. The technology used should not matter as it's more about applying principles, not specific code.
– Eric Lehmann
Jan 7 at 16:18
add a comment |
I found that rate limiting calls per user is not really a solution because a limit of 5 requests / minute still leads to 200,000 calls per month implying the calls are evenly across the day, hence a daily limit should be applied as well.
This however only applies to only one user/IP and the server side calls can still be exploited by a network of multiple clients.
Another solution could be to implement a CAPTCHA for the user to solve before a request can be made. In order to not disturb the user experience an invisible CAPTCHA could be applied.
It is important to analyse how those requests are structured. Is it only one IP that exploits the server side calls or is it coming from multiple directions?
The difficulty is to distinguish between legit and malicious requests and you want to block the bad ones but let the good ones through.
answered Jan 7 at 15:28
Eric LehmannEric Lehmann
93
add a comment |
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
A solution could be to use a secret that is shared between the client and the server. Unfortunately this doesn't work if the client source code is publicly accessible (e.g. a web app).
Limiting the calls per user would work but you probably need to protect against the abusing party creating users automatically. Perhaps adding a daily limit of geolocation calls per IP, or limit of user creation calls per IP would work.
Lastly you might need to use some kind of abuse detection mechanism on your server. Something that monitors the amount of calls per IP, per user, recognises patterns etc.
answered Jan 4 at 11:00
wvteijlingenwvteijlingen
8,96312545
add a comment |
A solution could be to use a secret that is shared between the client and the server. Unfortunately this doesn't work if the client source code is publicly accessible (e.g. a web app).
Limiting the calls per user would work but you probably need to protect against the abusing party creating users automatically. Perhaps adding a daily limit of geolocation calls per IP, or limit of user creation calls per IP would work.
Lastly you might need to use some kind of abuse detection mechanism on your server. Something that monitors the amount of calls per IP, per user, recognises patterns etc.
answered Jan 4 at 11:00
wvteijlingenwvteijlingen
8,96312545
add a comment |
A solution could be to use a secret that is shared between the client and the server. Unfortunately this doesn't work if the client source code is publicly accessible (e.g. a web app).
Limiting the calls per user would work but you probably need to protect against the abusing party creating users automatically. Perhaps adding a daily limit of geolocation calls per IP, or limit of user creation calls per IP would work.
Lastly you might need to use some kind of abuse detection mechanism on your server. Something that monitors the amount of calls per IP, per user, recognises patterns etc.
answered Jan 4 at 11:00
wvteijlingenwvteijlingen
8,96312545
A solution could be to use a secret that is shared between the client and the server. Unfortunately this doesn't work if the client source code is publicly accessible (e.g. a web app).
Limiting the calls per user would work but you probably need to protect against the abusing party creating users automatically. Perhaps adding a daily limit of geolocation calls per IP, or limit of user creation calls per IP would work.
Lastly you might need to use some kind of abuse detection mechanism on your server. Something that monitors the amount of calls per IP, per user, recognises patterns etc.
answered Jan 4 at 11:00
wvteijlingenwvteijlingen
8,96312545
answered Jan 4 at 11:00
wvteijlingenwvteijlingen
8,96312545
answered Jan 4 at 11:00
wvteijlingenwvteijlingen
8,96312545
answered Jan 4 at 11:00
wvteijlingenwvteijlingen
8,96312545
8,96312545
add a comment |
add a comment |
I would suggest having a look at best practices documentation for Google Maps Web Services:
https://developers.google.com/maps/api-key-best-practices
The most important thing is protect your API key. In case of web services you should protect the API key with IP address of your backend server. In this case nobody else will be able to use your API key and abuse your quota.
You should secure the API keys in your application for all Maps Platform products that your application uses. You can secure API keys by designating restrictions and by implementing best practices that are appropriate for the Google Maps Platform APIs in your application. Publicly exposing unsecured credentials can result in unintended use, which could lead to unexpected charges on your account.
I hope this helps!
answered Jan 4 at 19:09
xomenaxomena
18.9k44275
Although, it's a good idea to read through the api key best practices. It does not answer the question because the API key is not exposed in my scenario.
– Eric Lehmann
Jan 7 at 11:41
If API key is not exposed, so you have to protect your own server side calls. Isn't it?
– xomena
Jan 7 at 14:19
Exactly, that's the question. How to protect my own server side calls. :)
– Eric Lehmann
Jan 7 at 15:22
You should reformulate your question. It is not directly about protection on the Google Maps API side, its about protection on your server side code. However, you didn't specify even technology used on your server side. Java, PHP, Python, NodeJs...???
– xomena
Jan 7 at 15:29
I edited the question. I hope it's clearer now. The technology used should not matter as it's more about applying principles, not specific code.
– Eric Lehmann
Jan 7 at 16:18
add a comment |
I would suggest having a look at best practices documentation for Google Maps Web Services:
https://developers.google.com/maps/api-key-best-practices
The most important thing is protect your API key. In case of web services you should protect the API key with IP address of your backend server. In this case nobody else will be able to use your API key and abuse your quota.
You should secure the API keys in your application for all Maps Platform products that your application uses. You can secure API keys by designating restrictions and by implementing best practices that are appropriate for the Google Maps Platform APIs in your application. Publicly exposing unsecured credentials can result in unintended use, which could lead to unexpected charges on your account.
I hope this helps!
answered Jan 4 at 19:09
xomenaxomena
18.9k44275
Although, it's a good idea to read through the api key best practices. It does not answer the question because the API key is not exposed in my scenario.
– Eric Lehmann
Jan 7 at 11:41
If API key is not exposed, so you have to protect your own server side calls. Isn't it?
– xomena
Jan 7 at 14:19
Exactly, that's the question. How to protect my own server side calls. :)
– Eric Lehmann
Jan 7 at 15:22
You should reformulate your question. It is not directly about protection on the Google Maps API side, its about protection on your server side code. However, you didn't specify even technology used on your server side. Java, PHP, Python, NodeJs...???
– xomena
Jan 7 at 15:29
I edited the question. I hope it's clearer now. The technology used should not matter as it's more about applying principles, not specific code.
– Eric Lehmann
Jan 7 at 16:18
add a comment |
I would suggest having a look at best practices documentation for Google Maps Web Services:
https://developers.google.com/maps/api-key-best-practices
The most important thing is protect your API key. In case of web services you should protect the API key with IP address of your backend server. In this case nobody else will be able to use your API key and abuse your quota.
You should secure the API keys in your application for all Maps Platform products that your application uses. You can secure API keys by designating restrictions and by implementing best practices that are appropriate for the Google Maps Platform APIs in your application. Publicly exposing unsecured credentials can result in unintended use, which could lead to unexpected charges on your account.
I hope this helps!
answered Jan 4 at 19:09
xomenaxomena
18.9k44275
I would suggest having a look at best practices documentation for Google Maps Web Services:
https://developers.google.com/maps/api-key-best-practices
The most important thing is protect your API key. In case of web services you should protect the API key with IP address of your backend server. In this case nobody else will be able to use your API key and abuse your quota.
You should secure the API keys in your application for all Maps Platform products that your application uses. You can secure API keys by designating restrictions and by implementing best practices that are appropriate for the Google Maps Platform APIs in your application. Publicly exposing unsecured credentials can result in unintended use, which could lead to unexpected charges on your account.
I hope this helps!
answered Jan 4 at 19:09
xomenaxomena
18.9k44275
answered Jan 4 at 19:09
xomenaxomena
18.9k44275
answered Jan 4 at 19:09
xomenaxomena
18.9k44275
answered Jan 4 at 19:09
xomenaxomena
18.9k44275
18.9k44275
Although, it's a good idea to read through the api key best practices. It does not answer the question because the API key is not exposed in my scenario.
– Eric Lehmann
Jan 7 at 11:41
If API key is not exposed, so you have to protect your own server side calls. Isn't it?
– xomena
Jan 7 at 14:19
Exactly, that's the question. How to protect my own server side calls. :)
– Eric Lehmann
Jan 7 at 15:22
You should reformulate your question. It is not directly about protection on the Google Maps API side, its about protection on your server side code. However, you didn't specify even technology used on your server side. Java, PHP, Python, NodeJs...???
– xomena
Jan 7 at 15:29
I edited the question. I hope it's clearer now. The technology used should not matter as it's more about applying principles, not specific code.
– Eric Lehmann
Jan 7 at 16:18
add a comment |
Although, it's a good idea to read through the api key best practices. It does not answer the question because the API key is not exposed in my scenario.
– Eric Lehmann
Jan 7 at 11:41
If API key is not exposed, so you have to protect your own server side calls. Isn't it?
– xomena
Jan 7 at 14:19
Exactly, that's the question. How to protect my own server side calls. :)
– Eric Lehmann
Jan 7 at 15:22
You should reformulate your question. It is not directly about protection on the Google Maps API side, its about protection on your server side code. However, you didn't specify even technology used on your server side. Java, PHP, Python, NodeJs...???
– xomena
Jan 7 at 15:29
I edited the question. I hope it's clearer now. The technology used should not matter as it's more about applying principles, not specific code.
– Eric Lehmann
Jan 7 at 16:18
Although, it's a good idea to read through the api key best practices. It does not answer the question because the API key is not exposed in my scenario.
– Eric Lehmann
Jan 7 at 11:41
Although, it's a good idea to read through the api key best practices. It does not answer the question because the API key is not exposed in my scenario.
– Eric Lehmann
Jan 7 at 11:41
If API key is not exposed, so you have to protect your own server side calls. Isn't it?
– xomena
Jan 7 at 14:19
If API key is not exposed, so you have to protect your own server side calls. Isn't it?
– xomena
Jan 7 at 14:19
Exactly, that's the question. How to protect my own server side calls. :)
– Eric Lehmann
Jan 7 at 15:22
Exactly, that's the question. How to protect my own server side calls. :)
– Eric Lehmann
Jan 7 at 15:22
You should reformulate your question. It is not directly about protection on the Google Maps API side, its about protection on your server side code. However, you didn't specify even technology used on your server side. Java, PHP, Python, NodeJs...???
– xomena
Jan 7 at 15:29
You should reformulate your question. It is not directly about protection on the Google Maps API side, its about protection on your server side code. However, you didn't specify even technology used on your server side. Java, PHP, Python, NodeJs...???
– xomena
Jan 7 at 15:29
I edited the question. I hope it's clearer now. The technology used should not matter as it's more about applying principles, not specific code.
– Eric Lehmann
Jan 7 at 16:18
I edited the question. I hope it's clearer now. The technology used should not matter as it's more about applying principles, not specific code.
– Eric Lehmann
Jan 7 at 16:18
add a comment |
I found that rate limiting calls per user is not really a solution because a limit of 5 requests / minute still leads to 200,000 calls per month implying the calls are evenly across the day, hence a daily limit should be applied as well.
This however only applies to only one user/IP and the server side calls can still be exploited by a network of multiple clients.
Another solution could be to implement a CAPTCHA for the user to solve before a request can be made. In order to not disturb the user experience an invisible CAPTCHA could be applied.
It is important to analyse how those requests are structured. Is it only one IP that exploits the server side calls or is it coming from multiple directions?
The difficulty is to distinguish between legit and malicious requests and you want to block the bad ones but let the good ones through.
answered Jan 7 at 15:28
Eric LehmannEric Lehmann
93
add a comment |
I found that rate limiting calls per user is not really a solution because a limit of 5 requests / minute still leads to 200,000 calls per month implying the calls are evenly across the day, hence a daily limit should be applied as well.
This however only applies to only one user/IP and the server side calls can still be exploited by a network of multiple clients.
Another solution could be to implement a CAPTCHA for the user to solve before a request can be made. In order to not disturb the user experience an invisible CAPTCHA could be applied.
It is important to analyse how those requests are structured. Is it only one IP that exploits the server side calls or is it coming from multiple directions?
The difficulty is to distinguish between legit and malicious requests and you want to block the bad ones but let the good ones through.
answered Jan 7 at 15:28
Eric LehmannEric Lehmann
93
add a comment |
I found that rate limiting calls per user is not really a solution because a limit of 5 requests / minute still leads to 200,000 calls per month implying the calls are evenly across the day, hence a daily limit should be applied as well.
This however only applies to only one user/IP and the server side calls can still be exploited by a network of multiple clients.
Another solution could be to implement a CAPTCHA for the user to solve before a request can be made. In order to not disturb the user experience an invisible CAPTCHA could be applied.
It is important to analyse how those requests are structured. Is it only one IP that exploits the server side calls or is it coming from multiple directions?
The difficulty is to distinguish between legit and malicious requests and you want to block the bad ones but let the good ones through.
answered Jan 7 at 15:28
Eric LehmannEric Lehmann
93
I found that rate limiting calls per user is not really a solution because a limit of 5 requests / minute still leads to 200,000 calls per month implying the calls are evenly across the day, hence a daily limit should be applied as well.
This however only applies to only one user/IP and the server side calls can still be exploited by a network of multiple clients.
Another solution could be to implement a CAPTCHA for the user to solve before a request can be made. In order to not disturb the user experience an invisible CAPTCHA could be applied.
It is important to analyse how those requests are structured. Is it only one IP that exploits the server side calls or is it coming from multiple directions?
The difficulty is to distinguish between legit and malicious requests and you want to block the bad ones but let the good ones through.
answered Jan 7 at 15:28
Eric LehmannEric Lehmann
93
answered Jan 7 at 15:28
Eric LehmannEric Lehmann
93
answered Jan 7 at 15:28
Eric LehmannEric Lehmann
93
answered Jan 7 at 15:28
Eric LehmannEric Lehmann
93
93
add a comment |
add a comment |
Can you perhaps introduce a secret that the client needs to supply in the request to your server?
– wvteijlingen
Jan 3 at 13:03
A secret or a temporary user specific/temporary token won't work because the application needs to be publicly accesible.
– Eric Lehmann
Jan 3 at 13:29
Check if caching/storing results of Google Map API calls violates their licensing agreement. I think it does.
– Michael Diomin
Jan 3 at 16:53
Thanks for the note concerning the licensing agreement. But Geocoding API results may be cached up to 30 consecutive days. See: cloud.google.com/maps-platform/terms/maps-service-terms
– Eric Lehmann
Jan 3 at 16:58