I have included OSM as a basemap reference. And it’s only used as that. It was working perfectly until yesterday until today where a user reported these anomalies.
We dont use it for any other purposes other than as reference basemap. Thank you.
And for use as a basemap the OSMF tileservers/cdn is the wrong choice as this is build for minutely updates and by that by design will show vandalism (which is actually good as mapping feedback as with this vandalism is also caught really fast by OSM community members and the DWG).
Again, for a basemap there a lot of other choices, one e.g. mentioned above, where you won’t get the vandalism shown.
And yes: as you have found out, trying to clear the browser cache or using a different browser won’t help most of the time as the cdn and the tilerenderers of the OSMF are overloaded with those vandalism cleanings.
6 Likes
Well, in cases like these, the reverter plug-in first must compile list of accounts that were used for the vandalism. Then it must compile a list of the changesets that these accounts /contributed/ and sort that in chronological order and revert them one after the other, starting from the latest one.
And by the way, it must include well-meant reverts by bystanders that happened over the vandalism and did not get the scope of it.
Hats off for @woodpeck for being so quick and from what it looks like so precise.
I learned that from reverting /contributions/ by a local mapper that happened to use several accounts to touch the same stuff over and over.
3 Likes
A viable approach for dealing with complex and interwoven vandalism like
this, which may or may not have been reverted or affected by a
well-meaning but incomplete revert, is “return all these objects to the
state they were in before $TIMESTAMP no matter how many edits they have”.
14 Likes
i see that too , why would some one want to do this , this world if full of shit peoples … hope it fixes
i dont see any exploded line yet . maybe it fixed 
1 Like
FYI they’re at it again, noticed a large amount of new accounts all with the same changeset comments (Voocnts Snstruct Sred | OpenStreetMap for one of them).
2 Likes
In this moment there is a large attack
2 Likes
start time roughly 4:05 PM CDT (21:05 UTC)
I think the earliest I saw was 20:57 UTC, reverted by 22:53 UTC. If anyone sees any remaining problems in the data please do email data@openstreetmap.org with the object ID that’s still incorrect.
5 Likes
Would it be possible to invoke this for the time range 20240614T2057 to 20240614T2253 ? The DWG is getting reports of “vandalism, and I’ve cleared my browser cache and it is still there”.
1 Like
Firefishy put this time range in last night in the VSL in Fastly. I’m still not 100% positive if a force refresh (e.g. Ctl+F5, etc.) would help on “non www.osm.org” sites as the (general) VSL code is not known (which is understandable so it cannot be gamed easily).
Also this one here: Dirty tiles cached for 7 days · Issue #441 · openstreetmap/mod_tile · GitHub would help a lot.
1 Like
when i report this user , it will make all his edits remove when he banned from osm ?
If you see a problem, can you run through the steps described above to see if the vandalism in the data has already been dealt with?
If it has, you don’t need to do anything. If you see problem data, please email data@openstreetmap.org with the URL of the problem data that you got back from pressing “?”.
In general I still think that the OWG should think about presenting an andon cord (described here: Andon Cord for example) to the DWG with three (traffic light) states for the DWG to decide on:
green: everything is good, deliver out the tiles at tile.osm.org like crazy (tiles reaching millions)
yellow: big vandalism wave, restrict tile access to logged in osm contributors (as those mostly do understand the situation) at www.osm.org and e.g. third party editors like JOSM etc (tiles reaching several ten thousands).
red: big crazy vandalism with potential legal problems (hate speech against individuals, etc.): access restricted to a whitelist like DWG, OWG etc (tiles reaching a few dozen people that deal with the situation). (*)
It is better not to serve a tile than to serve a tile with blatant vandalism that will diminish the reputation of OSM in general.
Tiles like these:
won’t help OSMs reputation and should be a yellow or red state (I have deliberately choosen a zoom level that does not show street names to not repeat the vandalisms content). (This also shows how all the fun is draining out for people doing great work with OSM data downstream at local chapters or other community projects etc).
(*) the red state may also restrict editing for any but the DWG/OWG as well-intentioned reverts/edits or edits in general by the large osm community may complicate reverts further. At least this state should have a banner informing in editors that the DWG is working on a large scale revert asking mappers to try to not to interfere. I’m not sure if the blocking of edits is really feasible or a good idea, but a warning about the situation would probably help in easing the revert work for the DWG.
Ad Addendum: Fake parks or beaches from Pokemon would still be a green state imho. I mean, we all agree that the world needs more parks and beaches and less parking spaces 
14 Likes
Already applied this cache rule from around 1am.
5 Likes
But it is still showing up in third party websites using tiles from tile.osm.org cdn e.g. at zoom level 15 or 13 in several areas, so this is not just a technical problem (as the technical level alone won’t solve this) but a problem of responsibility and how to deal with that. On the technical level the osm stack will improve but still won’t be able to get into an “we can always deliver clean tiles” state (for technical improvements: please look into Dirty tiles cached for 7 days · Issue #441 · openstreetmap/mod_tile · GitHub if your cdn does rely on cache-headers from the renderers).
“cleared my browser cache” is ambiguous, it can mean:
- using the settings menu to delete all locally cached files
→ won’t help, as tiles will still be in the CDN cache - a hard reload with Ctrl + F5 to bypass and update the caches (only works on openstreetmap.org)
→ also sendsno-cacheheaders to the CDN to bypass and update cached tiles there, which is what is needed
Do you have some example URLs?
1 Like
It is exactly this.
E.g.
Doing a hard reload won’t help. This is a third party website, tile headers for one of the sea tiles:
{
“Response headers (695 B)”: {
“headers”: [
{
“name”: “accept-ranges”,
“value”: “bytes”
},
{
“name”: “access-control-allow-origin”,
“value”: “*”
},
{
“name”: “age”,
“value”: “163951”
},
{
“name”: “alt-svc”,
“value”: “h3=":443";ma=86400,h3-29=":443";ma=86400,h3-27=":443";ma=86400”
},
{
“name”: “cache-control”,
“value”: “max-age=604800, stale-while-revalidate=604800, stale-if-error=604800”
},
{
“name”: “content-length”,
“value”: “8543”
},
{
“name”: “content-type”,
“value”: “image/png”
},
{
“name”: “date”,
“value”: “Sat, 15 Jun 2024 12:47:57 GMT”
},
{
“name”: “etag”,
“value”: “"ad7410ff1308cf596d6236fcbd30bb84"”
},
{
“name”: “expires”,
“value”: “Thu, 20 Jun 2024 15:15:26 GMT”
},
{
“name”: “server”,
“value”: “Apache/2.4.54 (Ubuntu)”
},
{
“name”: “strict-transport-security”,
“value”: “max-age=31536000; includeSubDomains; preload”
},
{
“name”: “via”,
“value”: “1.1 varnish”
},
{
“name”: “x-cache”,
“value”: “HIT”
},
{
“name”: “x-cache-hits”,
“value”: “1”
},
{
“name”: “X-Firefox-Spdy”,
“value”: “h2”
},
{
“name”: “x-served-by”,
“value”: “cache-fra-eddf8230066-FRA”
},
{
“name”: “x-tilerender”,
“value”: “odin.openstreetmap.org”
},
{
“name”: “x-timer”,
“value”: “S1718455677.467937,VS0,VE2”
}
]
}
}
These are the response headers for a hard reload.
I don’t know how the Fastly CDN works, but what helped me in a few examples is:
- go to openstreetmap.org in the same area and zoom, do a hard reload with Ctrl +F5
- then go back to the external site/app and also do a hard relaod there.
2 Likes