Ideas for combating vandalism

[CorruptComputer]

Problem

Vandals have been on the rise recently and I have a few ideas for how we can limit the damage they do. I would love to hear others ideas as well for how we could reduce the damage they can do.

Description

I have 2 proposals, one I believe is a 'hot take' and may have contention, but I hope that the second one is more agreeable.

1. Limit access to edit using JOSM and other 'power tools' that can do large scale damage to the map for new and dormant accounts.
   a. While iD can still do quite a lot of damage to the map, it is harder to do global damage to the map with iD than it is with JOSM.
   b. JOSM is an extremely powerful tool and it should be an earned privilege to use it.
2. Treat accounts that have been dormant for years as 'new' accounts for the purposes of rate limiting.
   a. As an example, account chessiegp9 (https://www.openstreetmap.org/user/chessiegp9/history) was recently used as part of a vandalism campaign. This account had not edited on OSM for 3 years prior to the vandalism starting, it is unclear as to if the original account creator made these changes or if the account was taken over by a bad actor, however I believe this would have mitigated some of the damage done.

Screenshots

No response

[aredridel]

Segregate suspicious edits for review, or commit on a delay. Specifically "large bounding box from newish account" and "golf-related from a new account" seem to be pretty obviousmarkers.

[tomhughes]

None of this is something that is best discussed here - discuss it with DWG and come back when you have concrete requests.

Note that "chessiegp9" was a relatively minor even and didn't actually make a significant number of edits so it's unlikely rate limits would have much effect there.

[mmd-osm]

The editing app can be easily faked, as it has happened before. You could pretend to be iD and still do large scale changes.

The dormant accounts idea might work from a technical pov, probably needs a bit more thought.

Sorry, we don’t have review queues or anything like that. It would be a huge change to the architecture and overall mapping process.

[tomhughes]

Also see https://community.openstreetmap.org/t/the-osm-standard-tile-layer-looks-wrong-white-lines-abusive-comments-etc/111583/193 for why a "review queue" is a nice idea but a huge task with significant problems.

[CorruptComputer]

The editing app can be easily faked, as it has happened before. You could pretend to be iD and still do large scale changes.

The changeset tags for the app maybe, but wouldn't the 'Client ID' for the app be harder? That would require changing and building from source wouldn't it? It would still be possible to fake this, but it would add an additional barrier that they would need to cross for it.

[SomeoneElseOSM]

discuss it with DWG and come back when you have concrete requests.

Actually, we'd probably just say "discuss it with the community first so that people are happy about the way that contributing to OSM has changed". There was significant pushback against rate limiting from organisations that rely on putting lots of newbies in front of computers and doing some remote editing; we'd need to ensure that if we're going to change the way that people can contribute that people are (a) aware and (b) happy about that change.

[CorruptComputer]

discuss it with DWG and come back when you have concrete requests.

[...] "discuss it with the community first so that people are happy about the way that contributing to OSM has changed". [...]

Yeah, I opened this issue so a discussion could take place here. Its obvious that something needs to be done, but nothing will get better if we just shut down the conversation and kick the problem down the road to different groups.

[tomhughes]

Yes but community.openstreetmap.org is a better place to discuss with the community - here you're only going to find a small number of developers who are just going to get annoyed by a never-ending thread with no actionable conclusions.

I also largely disagree with the idea that something more needs to be done, or rather I think I have already identified a way to prevent the type of action used in the recent attacks from causing significant disruption and have taken steps to action that by opening osm2pgsql-dev/osm2pgsql#2185.

[HolgerJeromin]

The editing app can be easily faked, as it has happened before. You could pretend to be iD and still do large scale changes.

The changeset tags for the app maybe, but wouldn't the 'Client ID' for the app be harder? That would require changing and building from source wouldn't it?

No. Even in the browser editor iD this is a mouse click away and freely changeable:

[bhousel]

No. Even in the browser editor iD this is a mouse click away and freely changeable:

Not quite - users can type here, but it won't actually accept their change. Those fields are locked to their original values.

(The original point is correct though that it's trivially easy to fork iD, or any other OSM editor, and have it call itself something else, making the idea of combating vandalism by looking at the created_by tag a non-starter.)

[CorruptComputer]

The editing app can be easily faked, as it has happened before. You could pretend to be iD and still do large scale changes.

The changeset tags for the app maybe, but wouldn't the 'Client ID' for the app be harder? That would require changing and building from source wouldn't it?

No. Even in the browser editor iD this is a mouse click away and freely changeable:

Thats not at all what I am talking about though, I'm talking about the Client ID that the editor uses to identify itself to the OSM API. While this is still something that can be changed, it would require rebuilding the application from source which is adding a higher barrier to entry for these vandals. Sure it won't stop a persistent vandal, but it would make them need to work a bit harder for it and I'd imagine some would probably just give up if its too much work to be worth it for them.

https://github.com/openstreetmap/iD/blob/develop/config/id.js#L14