Cyber attacks in the OSM space

While “throw out” is rather vague; if you mean “revert”, we’ve already got one of those. The challenge tends to be that people using individual changeset-based revert tools that inadvertently cause more problems than “doing it properly” in the first place. If we think that a community-based revert has been more successful than it actually has (as was the case with the vandalism in the eastern Mediterranean last year) then subsequent reverts are more difficult.

If you mean “redact”, I think we have a good solution there too - I found it easy to script “redact all changes by users X, Y and Z” the last few times I’ve had to do it.

For the benefit of those that are lucky enough not to have been involved in OSM in 2012, this is the “redaction bot”. It was used for removing all changes made by certain users from the database and all dependent changes. Technical changes would be needed to make that Oauth2 complient (this is something that’s already been flagged up within the DWG). However, iIf you catch vandalism early, there tend not to be many dependent changes, and “reverting to the status quo ante” prior to a redaction is already supported by the existing tools.

However:

  • I’d probably have expected to see an initial approach to find out what we as an organisation already had before doing that?
  • It sounds like you are proposing to do option 4 as described here. Is that something that the board have decided upon and do they intend to put in place all the other requirements for that beyond the merely technical (support etc.)?

How that will (or even could) work really needs discussion in its own thread…

Edit: s/west/east above.

9 Likes