No, far from.
Not that I have anything against Overture, but it’s something entirely different.
Could you please remove the name, no need to mention. If it were me, I wouldn’t want to read my name everywhere.
Have you already tried a hard reload (e.g. Ctrl + F5, see Browser cache) on openstreetmap.org to bypass and update the caches?
2 Likes
Done. Fair point about the name.
That fix didn’t work for me. Are you saying that this has already been removed but that my map isn’t properly updated? If yes, I’ll keep trying the reload fix. Thanks.
Do you see the problem in an incognito window, or in a different browser, or on a different device?
Yes, the edit itself has long been removed, the issue are old tiles in various caches.
I would like to try and confirm something, could you please copy & paste the response headers x-served-by and x-tilerender of some tile.openstreetmap.org request in the network tab of the browser dev tools (F12). I can explain how to do that if needed.
Maybe the advice on how to check if vandalism is still present or if it’s a tile caching issue should be to use the “query features” action or via the map data overlay. That should completely bypass the tile caches.
11 Likes
I just checked the West Milford, NJ vandalism and it is still visible at 1,000’ and 2,000’ magnifications: West Milford Vandalism.
I did a refresh of my Chrome browser, a hard F5 refresh, then opened up the map in Firefox, then Edge. The objects are visible in all three browsers.
Thanks for your help with this.
Regards,
Bill
You got two thumbs down for this. Maybe it is not the right term.
Bad joke: Spitting on a computer/smartphone is not a cyber attack.
I looked at the second wave on May 16: They follow a pattern - Three different accounts perform an innocuous edit somewhere in Eastern Europe, 22:06, 22:09, 22:13. At 22:34 all three accounts at once start vandal edits spanning the whole globe.
The ingredients for a so-called cyber attack look given. A concerted effort by an abusive party. Why is the term not liked? I confess, I do not like it either.
Maybe there is one ingredient missing – When a disgruntled employee takes down the company network, is that a cyberattack?
When a self-righteous user vandalizes openstreetmap? Would that be different from when a troll factory vandalizes openstreetmap?
I guess you said it even more concise, the missing ingredient, why cyberattack is not the right term:
All that said: The means to defend may be the same after all. The only choice is limiting the front door.
1 Like
We’re lucky to have folks like Andy who care enough about the project to keep it clean of vandalism. But we shouldn’t take them for granted by assuming they’re always going to be able to handle whatever troublemakers decide to throw at them. Even if there isn’t a concerted effort by dedicated vandals, we will see more vandalism as the project grows and our cherished attribution ends up in front of more eyeballs. We can only hope some percentage of new contributors is also named Andy so they can back him up.
As it is, the current spate of vandalism is proving to be a distraction, taking some time from people who would rather spend time mapping or cleaning up after well-meaning newbies instead. I’ve been around this project long enough to remember the good old days when newbies didn’t stream into this forum to complain about vandalism, so to me, something has gotten worse. Hopefully the storm will pass soon; hopefully this won’t become the new normal because we missed some potential way to deal with likely patterns of abuse at a technological level.
15 Likes
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)?
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
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.
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
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:80Cache-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 GMTExpires: 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
Last rendered at Sun May 19 18:32:09 2024- https://odin.openstreetmap.org/17/69634/45953.png/status
edit: JS snippet shortened
3 Likes
(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
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
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
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.
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,
- implement the logic that decides what’s suspicious
- 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”) - implement logic for applying reviewed changes to the database, including conflict resolution when someone has edited/deleted the element in the intervening time
- implement the UI for moderators to be able to do 3 - i.e. look through the review queue, visualise edits, and apply/reject them
- staff up DWG to be able to do all the extra work involved in 4
- 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
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