Request for temporary exemption — app blocked by User-Agent policy, users on older versions affected

Foundation
, , ,
1

Hello,
I develop a mobile app that uses OpenStreetMap tiles to display locations on a map. Our requests to tile.openstreetmap.org have started returning 403 after the update of the Tile Usage Policy.
Our situation:
The app was originally created with the identifier com.example.***** — this is the project’s original structure (Android namespace, Kotlin package, manifest), not a temporary placeholder. We were not aware that OSMF blocks the com.example.* prefix until the new policy came into effect.
The fix is clear: forward HTTP headers in our tile provider and switch to the actual application ID. The changes are prepared and will be included in the next release.
Many users are still on older versions. Until they update, maps will remain broken, and we cannot force everyone to update immediately.
Request:
If OSMF considers temporary exceptions, I would appreciate being contacted to discuss a possible short-term exemption for our application, so users have time to update while we roll out the fix.
Thank you for your work and for considering this request.

1 Like
2

I am pretty sure that Tile Usage Policy was not changed at all, the only thing that changed was that some rule-violating requests are no longer allowed to succeed.

I am not one of sysadmins or being official representative, but general policy is that no such exceptions are granted. Given shoestring budget and general lack of resources there is no capacity for manual special exceptions.

I would encourage to review Tile Usage Policy to confirm that all, including currently not enforced, restrictions are followed to avoid such surprises in future. The same for other usage policies.

1 Like
3

You should use your app store’s expedited review process to push the update immediately.

Sending invalid requests to OSM is as much a bug as a null pointer exception in your code would be. The Tile Usage Policy has said “Using a library’s default User-Agent is NOT recommended as they may be blocked if another user of the library is misusing it” since at least 2024.

9 Likes
4

A more general observation: if you are asking for an exception to a policy you should address your request to the arbiters of said policy in private, in this case the OWG/Operations group and not publish it on a public forum for comment by everybody. Besides not reaching the people you intended to, you additionally make the response a matter of how policy enforcement is viewed publicly which is likely not a good idea if you want a positive answer.

7 Likes
5

though I would not encourage them (or others) to actually contact OWG/Operations group via other channels asking for permission to break usage policy

1 Like
6

Well the thing is besides not achieving the goal it just provides fodder for the unfriendly OSMers trope.

7

We haven’t changed the usage policy. We have had a requirement to include a user-agent identifying your app since time immemorial and have specifically mentioned library defaults for a long time. This being said, I doubt that it’s that part of the policy you’re violating.

The only blocks that contain “com.example” are blocks of flutter_map using the “com.example.app” ID.[1] These were added on 2025-08-18[2], long before this post, so it’s doubtful that’s it. Unfortunately you’ve not provided enough information to say what’s going on. What are the exact values of the user-agent and referer header you are sending?

We’ve been in the process of cleaning up our configuration as we onboard Nominatim to Fastly and improve our logging. It’s possible that one of these cleanups caught something that your app was doing wrong.

Delaying blocks is done on a case-by-case basis and depends on what other traffic the block is catching. We have always attempted to contact users before blocking them but if you are sending a generic user-agent that is impossible.

We specifically recommend to “Avoid hard-coding the tile URL to allow switching without needing a software update.” Your case is an example of why.

As a more general aside, we have only one user which we blocked under the “usage degrades the service” in the past five years. We emailed their app contact email on the app store page[3] and proponed the block by the amount of time they asked for when they contacted us[4]. Our usage policy allows us to block without notice but we’re developers who understand surprises suck. We’ve delayed applying generic user-agent blocks when a public interest app is impacted. In practice we’re “nicer” than many commercial providers.

If someone is contacting us about a block I like to see

  • acknowledgement of an error and why they made the error,
  • their exact user-agent and/or referer headers so we know who they are,
  • the actions they have taken and will take to resolve the issue, and
  • the grace period they are requesting.

  1. Nominatim contains additional logic handling bogus contact information ↩︎

  2. Private repo: https://github.com/openstreetmap/opentofu-fastly/commit/f05acfe014a96dbeab6330a941a675e1cc333921 ↩︎

  3. The email bounced and we tried to contact them on their social media page but didn’t get a reply. ↩︎

  4. During this time their usage increased about 40% before we resumed the block ↩︎

8 Likes
8

Do you think this information should be linked somewhere in the documentation?