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
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
Please do not post screenshots showing the slurs or directly cite/reproduce them
3 Likes
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.
Sry i wasn’t awake to remove it before it already got removed by the mod team.
2 Likes
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
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
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.
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
Someone suggested making a small edit nearby, I guess that should help.
Yes, seems to be the only way.
We have learned of some vandalism on the openstreetmaps at the following location:
OpenStreetMap
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!
7 Likes
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.
3 Likes
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.)
4 Likes
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?