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

We have learned of some vandalism on the openstreetmaps at the following location:

Several roads with inappropriate names that do not exist have been added in this area and should be removed. Thank you!

Can you have a look at the summary above and see if the data in your area has already been fixed?

(I’m moved your post here because that’s where most of the discussion is currently happening)

We should probably have a workshop to discuss it… maybe in Scunthorpe or Penistone .

You joke but, as someone who lives near Penistone and tests software for a living, let me tell you all about false positives… Actually, Tom Scott does it better. The point is any list of banned words, however exhaustive, can be trivially subverted even by children. And English isn’t the only language on a world map. Good luck!


I really hope we can find a solution to this. At the very least city and country names should be locked. This sort of vandalism can deeply damage OSM’s standing with the public.


No luck here. Made a change that would affect several vandalized tiles two hours ago. When trying “Load all tiles” in JOSM, sometimes I even see more of the junk.

I still do not get it: The junk has been in data for less than one hour and caches replicate it for several days.

PS: Actually, I am used to the Editor tiles lagging. My own little change from 22 hours ago also did not make it live there yet (and also when directly calling the tile.)


On the subject of prevention of propagation, my son came up with an idea. We were talking about moderation (approval of edits before they can be used for open distribution), which I immediately dismissed, because we would need a team of moderators. Then he said, why not require approval of one experienced mapper, before applying the edits to the database, or (my preference) before clearing the edited objects for open distribution.

I think a built-in approval mechanism is a requirement for prevention of the kind of vandalism we see. I can’t say how this should work technically, but conceptually it is either an intermediate edit/changeset approval system working before the edits are applied to the database, or flagging edited objects in the database as awaiting approval.

The flagging option enables the dual system I mentioned earlier: direct unapproved access/distribution for mappers (which also serves to detect vandalism and to double check the approvals by the complete mapping community), and approved access/distribution for other usages.
The difference is, earlier I thought of delaying the entire propagation on the tile server level, whereas now the delay would be on the object level.

The pitfall is censorship. So the approval should only target attacks, not user errors, and the approving should answer only one question: is this a deliberate attack?

Basic question: would this be technically possible?

Of course. The more difficult social issue is the burden on people to perform the moderation and potential to slow down edits and whether we feel either is acceptable/desirable.

1 Like

Problems that come to mind:

  • approval before putting stuff in the database won’t work because then
    various conflicting edits could wait for approval

  • approval after putting stuff in the database, but before stuff is
    released for public distribution, would avoid that particular problem
    but funny conflicts would still be possible if, for example, someone
    deletes and re-draws something and for some reason one of the two edits
    is released and the other still waiting

  • what if something is not approved but other stuff has been done on top
    of that in the mean time?

  • new mappers would have to wait longer for their contributions to
    appear which could be a bad user experience for them

I have wondered about the same sort of concept, & thought about the theory of designating the moderators of the various Communities here as “approvers” of new edits by new mappers in each of their regions?

If the new mappers are not mapping big sweeping changes that are visible across the entire globe, I don’t see it as necessary to wait for their changes to be approved.

Sure we may get a few vandalised names here and there but that obviously isn’t of as much concern as painting over the entire map.


Suppose that all experienced users can opt to help with approval and given the current situation of prolonged attack, would you switch such a system on? It doesn’t need to be on at all times.

The idea is that mappers can still map and see their edits in mapper tools, but propagation for real world user applications is done only with approved objects.

Wouldn’t mappers understand the need for approval, once they have seen the damage caused by this kind of intentional vandalism?

The idea is to delegate approval to the mapper community as a whole. So not as a specific function, but just another mapper’s task. E.g. mappers with a certain amount of edits and/or say two years experience, are asked to opt in as approvers. Maybe only during an attack, and just to say I think this is not vandalism.

How the approval workflow would work is an issue, but I’m sure clever OSM people can solve that.

1 Like

Wikipedia has been experimenting with various “approval” mechanisms, and for the most part they were a failure (see Pending changes), mostly for reasons pointed out by Fredrick. Experienced editors feel reviewing of changes as a burden, and as result pending changes sit in a queue for extended periods of time, at which point they are more prone to cause edit conflicts and complicate workflow for those wishing to tackle them (who then give up).

What was a success at Wikipedia was the Cluebot (who used relatively simple rule set to revert obvious childish vandalism), and after that various measures to limit editing capabilities of new users (banning creation of new articles for unregistered users; blocking non-500/30 editors from many controversial pages, and similar).

Plus, there was always an efficient revert mechanism readily available for all registered users, who could revert vandalism on spot.

Obviously, our environments differ quite a lot, but we have some lessons to learn.


Now it is worldwide fake ways with abusive names, and we cannot stop it, because all preventive measures can be easily bypassed. Detection of this particular issue is pretty fast but still the damage is not entirely repaired, and the next attack will do the same damage.

Once the word gets around how to do this, and how easy it is to hit the sitting duck, risk is that it becomes a sport.


If the ease of creating new sock-puppet accounts with which to continue vandalism is part of the “time/cost imbalance” between vandalism and cleanup, then maybe the addition of a tutorial/sandbox restriction could help add time/cost to account signup in a way that is useful and maybe even helpful for new non-vandal users.

This could serve as a combination of CAPTCHA and training space and would hopefully take about the same time to complete as vandalism takes to revert (~30 minutes? ~1 hour?).

Here’s one way such a thing might work:

  1. New account is registered, starts blocked from the main API and only able to communicate with a sandbox API.
  2. The new user is presented with some number of standard mapping tasks that they must perform against the sandbox.
  3. Automated checking would examine their change-sets to confirm that they completed successfully and that these changes match heuristics of a person (e.g. not completed too fast or to precisely the same coordinates as a previous submission).
    1. The submission doesn’t pass. The user is presented with a button to request manual review and appeal.
    2. The submission passes. The account is now authorized to edit the main database.

As with other mechanisms proposed, this one would also involve significant development work, particularly in the choosing and analyzing of the results. One advantage it has is that it could be inserted into the signup workflow rather than changing the editing API. It would also give benevolent new users the opportunity to practice mapping and learn some techniques before they make their first edit to the main database.

All this said, if the number of sock-puppets is actually small, then maybe this increased friction wouldn’t be worth the development effort. :person_shrugging:

1 Like

Wow, the fact that we now need to discuss restrictions that would result in enormous additional work gives these vandals immense power. If these idiotic waves of vandalism cause OpenStreetMap to be less free and open than it has been, then these jerks have already won. OSM will forever bear their mark, which is exactly the stage they shouldn’t get.

Such proposals that large-scale edits need to be moderated in some form inevitably lead to further problems. For example, the fact that data is no longer updated live can immediately lead to conflicts between individual edits. The larger the area, the more likely this is. And with additional entry barriers, we are likely to lose significantly more good new contributors than it would actually deter those intending to vandalize.

Let’s show our respect to the volunteers (!) of the DWG for the fact that it only took a few minutes each time until the reverts were done. This shows that the team is doing everything right.

Of course, it’s very annoying that traces of this vandalism are still visible days later, but I think if we want to discuss measures, we should focus on how we can quickly and unobtrusively remove the traces of vandalism. This way, we don’t give these people a stage anymore, and hopefully, they will eventually give up.


We already know that we don’t have anywhere near the manpower (neither volunteered nor paid) to moderate newbie edits, I don’t think flogging very dead horses is going to help a lot with the issue.

PS: naturally there is the whole social aspect of having some mappers being more equal than others, but we don’t need to venture there as it is a non-starter in any case.


We don’t know for certain the motivation of each of these high-profile vandals, but there’s a good chance that none of them woke up this morning thinking, “I want OSM to be less free and open.” It would be useful to game out what typical vandals’ motivations might be as a starting point for brainstorming common-sense countermeasures.


My (son’s) idea works from live updated data! The edits do not wait for approval, the distribution does. If I used OSM data for a serious end user application, given the choice, I would always opt for extra security if the delay only omits changes to very recently edited objects. Assuming I would receive the latest approved version, of course.

PS I’m still trying to grasp if this leads to extra conflicts between edits. Have to make a diagram, I’m afraid.
Eg if the approval mechanism is turned off, and mapper A edits and uploads an object while mapper B edits the same object, you have a conflict when B uploads the edit; there is no locking mechanism on that level. Now turn on the approval mechanism, then A’s edit is uploaded and applied to the object, but it is not made available for end user apps or data user services apart from mapper tools. B’s edit gets the same conflict as without the approval.

Other case: A edits and uploads the object; B downloads this object and, using a mapper’s tool, gets the unapproved version, which she can edit and upload. You could argue that A’s version no longer needs approval, because B’s work serves as a correction.You could also say there are two unapproved versions of the object, so end user distribution will be two version behind.

Deletions probably are more complicated, but I’m sure this could be worked out for all cases, once the basic mechanism is in place. Still brainstorming, of course. Important: the OSM database still holds all the edits without any extra delay; the approval does not prevent edits.

Note that my (son’s) idea gives all mappers the same opportunities, not requiring nomination nor assigning a position, just a basic qualification.