The "OSM Standard tile layer" looks wrong (white lines, abusive comments etc.)

General talk
184

Urging consumers to not free-ride osmf supplied tiles might lessen impact and therefore incentive and might count a technological measure? @SimonPoole suggested GDPR compliant update feeds for consumers that want to follow minutely while having the possibility to delay/stall them in such highly global cases (no link ready)?

185

That was 3d ago. I still see vandalized tiles in JOSM, eg. here https://tile.openstreetmap.org/17/69634/45953.png – From wireshark I see it coming from 199.232.17.91

No force reload helps. There were a number of vandalized tiles on the homepage today, there ctrl-f5 helped.

1 Like
186

Apparently this explains odd white streaks, with some political or abusive texts, I recently saw a couple of times at some zoom-levels.

I really wondered what was going on.

187

Hey all, I just started using open maps and love all the amazing features it provides as open source. That being said, it seems the “Andy Townsend” nonsense is back again. I’ve taken down a local HOA site I built because I got a little too involved in integrating the map into some core functions and families that access the site for information may end up seeing the graphic language. This is just a “Heads up, it’s back” message.

Thank you guys for all you do!

3 Likes
188

By connecting through your Fastly CDN cache IP I can actually see what you are seeing:

  • chromium --host-resolver-rules="MAP tile.openstreetmap.org 199.232.17.91" https://www.openstreetmap.org/#map=17/47.27649/11.25691

  • curl -sI tile.openstreetmap.org/17/69634/45953.png -x 199.232.17.91:80

    Cache-Control: max-age=604800, stale-while-revalidate=604800, stale-if-error=604800
Expires: Fri, 24 May 2024 15:36:19 GMT
X-TileRender: odin.openstreetmap.org
Date: Sun, 19 May 2024 21:04:50 GMT
Age: 192512
X-Served-By: cache-vie6371-VIE
X-Cache: HIT
X-Cache-Hits: 1
...

  • tile added to CDN cache at Fri, 17 May 2024 15:36:19 GMT

    • Expires: Fri, 24 May 2024 15:36:19 GMT - Cache-Control: max-age=604800
    • paste in Browser console:
      new Date((new Date('Fri, 24 May 2024 15:36:19 GMT').getTime() - 604800 * 1000)).toGMTString()

  • odin was overloaded at that time, so it returned the dirty tile, which then got newly added to the cache

  • external tile service users get a fixed cache duration of 7 days
    (Cache-Control: max-age=604800)

  • hard reload (Ctrl + F5) only works on openstreetmap.org, not for single tile URLs nor external sites

  • the tile was just rendered today on odin

edit: JS snippet shortened

3 Likes
189

(if you’re wondering why your message ended up in this thread it’s because I suggested that the Ukrainian moderators move it here, which is where most of the discussion is).

To summarise:

  • What happened is described here.
  • I believe that the data has been fixed. You can follow the steps here to make sure.
  • The rendering servers are working with clean data (how this works is a bit complicated, but see here and here, and other posts above, for more information).
  • There’s a technical change in progress to minimise the effect that this sort of vandalism will have in the future.

However, some people are still seeing problems in the map tiles in their browser.

  • Mostly this is due to their own browser cache. Try an incognito or private window, or a different browser, to test this.
  • Sometimes old data is getting served from cache - this is one report, and the DWG are still getting others. See especially the post immediately above.

It probably isn’t possible to completely prevent this sort of thing happening in the future to OSM’s “standard layer” - it’s designed for mapper QA. However, if you’re creating a website, you absolutely do not have to use this layer. For a small local site, I’d probably just prerender down to whatever zoom level you’re interested in, and host statically.

I’ve reposted this as a bit of a summary as it’s clear from a few of the posts above that not everyone is reading previous posts in the thread before jumping in with “I’ve seen a problem”. This is entirely understandable - there are 190 posts in it!

13 Likes
190

The white lines and text have disappeared from the West Milford NJ map at the 1,000’ level, and they are thinning out at the 2,000’ level.

Thank you, Andy!

Moderators like yourself help give integrity to this very useful and helpful mapping tool.

4 Likes
191

I was looking around the OSM map for Cumberland county, Kentucky and found this way with the name [deleted by moderation] crossing over KY 90 near the Metcalfe county border… I think this is the right place to report things that have been spotted like this from this vandal

192

I apologise if this has already been discussed in this long thread, but is it really not technically possible to prevent some of this vandalism using a review system for certain unusual changes (for example detecting when worldwide roads are created or names of cities are changed)? Seems like such (non-vandalism) changes should only happen extremely rarely and should therefore be automatically flagged for review before publication.

193

Of course it’s technically possible, it’s just a very large amount of work and there’s a lot of design decisions to be made along the way - rather more than a two-sentence “is it really not possible?” might imply. Off the top of my head,

  1. implement the logic that decides what’s suspicious
  2. put elements deemed suspicious into a review queue, rather than immediately applying the element changes
    (bonus points for working out what you do with an edit which is partly suspicious and partly isn’t, e.g. a new route relation created with one member node called “Asshole Central”)
  3. implement logic for applying reviewed changes to the database, including conflict resolution when someone has edited/deleted the element in the intervening time
  4. implement the UI for moderators to be able to do 3 - i.e. look through the review queue, visualise edits, and apply/reject them
  5. staff up DWG to be able to do all the extra work involved in 4
  6. work out how you deal with the endless whack-a-mole as vandals evolve to get past the current implementation of 1

Something like this may end up being inevitable and I can’t pretend I’ve given it remotely the amount of thought it merits. But it really isn’t trivial. We should probably have a workshop to discuss it… maybe in Scunthorpe or Penistone.

15 Likes
194

Thank you for your thoughts. I now understand that implementing such a system involves a significant amount of work and numerous design decisions. Admittedly, I don’t have the technical insight to fully grasp all the intricacies involved. My main concern is that OSM seems vulnerable to this kind of vandalism that also requires extra work to correct, especially if there were a larger concerted effort to distort it.

2 Likes
195

Hi,
I’m also able to see abusive messages on location 51.94599,7.7041138
[map image deleted by moderation]
It’s still visible on 151429883 release set (the Changeset: 151429883 | OpenStreetMap)
Here’s the link to the location:
OpenStreetMap

196

Please do not post screenshots showing the slurs or directly cite/reproduce them

3 Likes
197

Hi fbmdf1821 and welcome to the forum. Please remove the quote from your post as repetition of this slur is not appreciated here in the forum.

198

Sry i wasn’t awake to remove it before it already got removed by the mod team.

2 Likes
199

I think you’ve hit the nail on the head in that “there’s some list of controls that ought to be implemented” and “it’s hard” and “even coming up with the right list is hard.”

I don’t think the question is whether or not we do something like this, the question is how severe the attacks and vandalism need to get before we prioritize it seriously, and whether or not we will end up doing so as a series of preventative measures or under duress while an attack is actively happening.

I’m pretty sure this topic is more important than (checks list) vector tiles and most of the items in the Strategic Plan beyond the ones about keping the core services reliable and available. Yet most of that is about making sure we have enough staff and equipment to keep the lights on and surving the odd blown power supply in the servers rather than any strategic work towards malicious edit prevention.

I do think we need more paid technical staff work on the problem of malicious edit prevention but I doubt we’ll prioritize it until the problem is at a fever pitch.

11 Likes
202

It seems like it is currently quick and easy for an attacker to move nodes across the entire world or just create new world spanning ways. This puts huge swaths of tiles into the render queue which then takes a long time to catch up. During this time the vandalism can remain visible on the standard layer long after the damage has been reverted. Would limiting the distance a node is allowed to be moved, and/or limiting the allowed bounding box of a single way help mitigate the effects of this sort of attack? Something like each way must have a bounding box no bigger than 0.5 degrees latitude/longitude? Or possibly even smaller since it’s generally good practice to avoid creating massive ways that can be difficult for other mappers to modify later.

I recognized that this might impose and undue burden on the editing API servers as a bounding box would need to be calculated for each way uploaded before accepting or rejecting the changeset. But maybe there is an efficient way to calculate this or something similar. Or maybe this wouldn’t slow attackers down enough to make a difference? They could still cross the whole map with vandalism, it would just take more changsets and more changes to do it. Anyway, just an idea for consideration.

6 Likes
205

Thank you for your reply! I will be sure to review your suggestions when I get a moment. It is entirely unfortunate such a noble effort like this is often met with abusers. I’ll keep an eye on this thread for any updates, in the meantime I’ll review the guidance in your post.

206

I can see those too, coming from culebre. A hard reload doesn’t help. Tile status is clean:

Last rendered at Fri May 17 00:00:57 2024
https://culebre.openstreetmap.org/18/136684/86651.png/status

While that rendering timestamp is after the revert changeset, it is well within the replication lag.

I suspect that some tiles of the revert did not get expired, perhaps caused by some hickup due to the huge number of tiles to expire.

1 Like
207

Someone suggested making a small edit nearby, I guess that should help.